-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Call for Input: Allow Links to CAIP #320
Comments
i am of the opinion that we allow as much links as possible to the sources which we deem to be safe to refer (immutability and reputation wise) |
^ I would be glad to open a PR that consolidates the allowlist into a simple two-column table with domains (reputation) and regexs (CI-able immutability-check), since each source has a different URL/URN scheme for its immutable docs (and non-immutable docs we presumably don't want to allow links to). In the case of CAIPs, it might be easier to do allow rendered CAIPs (domain |
I wanted to avoid commenting on this one since I wrote EIP-5757, but since no one has discussed whether CAIPs meet the requirements there, I guess I probably should: Versioned: Yes; git hashes. My two concerns are:
Since we have a reasonable workaround (copying to assets), and the only availability benchmark we have hasn't been met, I am going to oppose this CFI. |
There's also the question of legitimacy, which I neglected to bring up earlier. While it isn't an official requirement, do we want to recognize CAIPs as a "legitimate" standards body? If we do, we should link to them. If not, put them in |
In strong favor to allow link to CAIP |
The general consensus is to affirm this CFI. |
Call for Input
Do we merge ethereum/EIPs#8247 ?
Links to CAIP proposals are allowed.
Background
See ethereum/ERCs#99
The text was updated successfully, but these errors were encountered: