Thank you @SamWilsn for this effort.
I just to want to bring to the context of readers of this EIP that a few other Editors also provided their voices and proposed their solutions which are also worth considering Pros and Cons for Allowing External Links in EIP. - HackMD
@xinbenlv posted some excellent comments on the pull request that I think are better suited to this discussion thread:
I’m perfectly fine not allowing links to these sources.
Sure! I’m all for continuing to ban external links. I just think most other people want to allow some external links.
The difference between having to pay to access GitHub and having to pay to access an External Source is that once you’ve paid once to download the EIPs repository, you’re free to query it locally and to share it freely. Any final EIPs will continue to be available to you and anyone you choose eternally. That isn’t necessarily true of external resources.
The EIP repository has vastly different goals than Wikipedia. I think we’re free to choose our own path.
No argument here. I’m sure there are tons of useful things that this policy excludes.
That’s all very true and applies to everything, so it’s somewhat meaningless. Obviously the EIP isn’t saying that you can’t link to a source because you burn calories while reading it.
EIP-5757 specifically says “MUST NOT charge a fee for accessing resources”. It specifically doesn’t prohibit charging fees for, say, photocopying a book at a library.
Thank you for forwarding my comment on the PR.
I invite more readers comment on their views on the link policy.
Thank you for the effort, here is some feedback before moving from Last Call to Final
- 3(or 6)month test run, default to lose effect unless
- relax the restriction of distribution and free sources.
- Allow new origins to be added by PR in addition to a fast-track EIP
- Create a list of initial accepted origin
- [optional] represents the origin in the format of regex.
Thank you!
Here’s an initial list of origins.
Author of EIP-5757 @SamWilsn , and editors, before finalizing EIP-5757, I’d love to bring this suggested edit to your attention: Update EIP-721: broken and mislinked openzeppelin links by konojunya · Pull Request #5903 · ethereum/EIPs · GitHub
and hear your thoughts on how will this PR be reviewed under the EIP-5757, assuming the whole EIP-721 is created after EIP-5757.
Under the 5757 rules, the authors could have tried to get their external origins approved. Most of those links wouldn’t qualify. JSON-Schema is BSD, so you could include it in assets. None of the OZ links are immutable, so they probably wouldn’t qualify.
Got it. Glad it’s clear under such rule. Kudos for EIP-5757
This comment and its answers should not be considered as blocking merging EIP-5757 into Final
I like to kindly use this case to test the EIP-5757 against the core purpose of EIP in general. Do we see EIP as a place to only publish a recognized standardize, or do we see EIP as a place for proposal and such proposal might need backing evidence that can live outside of a proposal?
In a more specific case, would EIP-721 be in a better proposal if had the author and editor back then trim all links and references. A large portion of the EIP-721 draft was articulating
- the prior art
- the existing implementations of this particular draft
- the solidity language implements that were made to enable what EIP-721 needs to be safe and gas efficiency
Some of those links I believe can be trimmed, but a lot of them plays an important roles in arguing for this EIP.
For example, back then there were other several EIPs competing with each other aiming to be adopt as canonical. It would be hard to imagine a winning EIP could make a more competing case by pointing out adoptions and implementations, as well as upstream tool chains made to enable this EIP. This applies EIP-1155.
Adding authors of these EIP to see if they have an insight / opinion to share
@fulldecent, @coinfork
This comment and its answers should not be considered as blocking merging EIP-5757 into Final
List of other arguments being made to be placed under scrutiny of new EIP-5757 rule
Case 1
mentions specific company and product in an attack as a historical background for motivation. Shall such mentioning / reference be removed from spec under new EIP-5757? My understanding is it will be. But from a EIP general purpose standpoint, does it help make a proposal more convincing or less convincing? I think it’s more convincing to be put into concrete context. In such case, citing a specific security instance is a good way to argue with real case.
Case 2
I left a technical comment to the fact Solidity does something (doing payable) shows this EIP’s motivation is a material concern and Elsewhere attempts were made to mitigate that. I feel citing the exact line of code to demonstrate Solidity’s behavior helps make the argument. Under EIP-5757 it’s hard to provide fact. But in a general case, I feel links like this help articulation and make a proposal more convincing.
@SamWilsn @Pandapip1 thoughts on this?
By the way, IIRC on the last EIPIP meeting, the understanding is EIP-5757 will be in effect for 3 or 6 months after in effect, and lose effect by default after expiration unless a permanent adoption agree upon by EIP editors again, right?
@SamWilsn
An interface (typically in Solidity, with full NatSpac) is necessary for articulating an ERC.
The reference implementation is a quality signal that shows the author actually took the time to read the thing they themselves wrote. I support such a quality signal and I think it is or should be a requirement for publishing an ERC. Otherwise, people are publishing bad ideas that they themselves did not even think through and it becomes my responsibility to point out their flaws… lest EIPs be polluted with low quality content.
It will be nice to link to immutable resources, I can support that push. This can include publishing an application, incorporating the reusable reference implementation on-chain. Ideally this should be on Mainnet, spending real money to deploy. Spending real money is also a trust signal.
EIPs must remain free.
Using Ethereum isn’t free. And using Ethereum is a reasonable requirement for telling other people how to improve Ethereum.
Regardless of whether you have to pay to use Ethereum or not (plus receiving ether is free AFAIK), you should be able to verify Ethereum at no cost beyond internet and hardware.
While implementers are free to use whatever signals they want when deciding which EIPs to implement, I don’t think the EIPs repository should impose too many requirements on authors and certainly not any requirements that are non-free. Ideally we’ll try to encourage authors to seek out sufficient review before Last Call, but finding reviewers is a big job.
We certainly appreciate all the technical feedback you provide!
Counterexample: For various legal reasons, I don’t actually own any non-testnet Ethereum. I nonetheless hope that my EIPs and editing are helpful. At the very least, nobody has recently told me anything that suggests otherwise.
I’m actually more concerned about paid resources from a privacy perspective. You have to dox yourself to Paypal, a bank, the publisher, or perhaps even all of them to gain access to paid articles. I think we should not require mandatory self-doxxing to implement EIPs.
