Update EIP-1: Introduce implementation-status & implementation-status-url

[lucemans]

Note

This proposal is intended for demonstration purposes only.
and this message is self-referential.. in a weird way

Motivation

To date, nearly 6000 commits have been made to the ethereum/EIPs (and ethereum/ERCs) repositories.
Covering a wide range of content from ethos and technical standards, to procedures and processes, these repositories lay the foundation for the protocol and ecosystem we know today.

However not all specs are created equal. Some are abandoned, others superseded, and some are never implemented to begin with.
When taking a peek at MDN's playbook, we can see a similar situation play out with regards to browser implementations of web specifications.

Mozilla's solution for this was a widget, at the top of the page, highlighting the current status and imporant context the reader might need to be able to be informed.
In addition to this the widget is color coded to give the reader a seamless "at-a-glance" experience.

So what if we applied this to ERCs? Take ERC-20, wouldn't it be awesome if the average developer who lands on this page could easily see thats its a widely adopted standard?
A possible rendering of such section could look like this:

The above aims to render an example for the ERC-20 standard, however you could imagine a similar use case for the URL standards, which also involve successive standards, and many more.
In other cases, where implementation of a spec might differ between wallets (think WalletConnect or ENS support), or clients (think protocol level changes) documents could link out to resources to showcase what clients implement what.

This would allow beginning developers, teams, and organizations a better first glance at the collective works that represents ethereum.

Isn't maintaining this going to be an absolute pain?

Oh absolutely, but as with anything it is dependent on the granularity withwhich it is kept up-to-date.
As mentioned in the proposed changes, this field is ment to be used sparingly.

Isn't this a registry?

As outlined in EIP-5069: EIP Editor Handbook "What we Don't"-section:

Track Registries: We want all proposals to eventually become immutable, but a registry will never get there if anyone can keep adding items. To be clear, exhaustive and/or static lists are fine.

So here is my response; there are a few conditions which must be met for this to be tolerable:

• It must be used sparingly, no overuse, no verbosity, keep it simple
• Only cover general status, not track specific implementations, or point fingers
• Linkout to at-most three (or one) resource(s), that compare the state of available options (think L2Beat)

Should this be merged?

Maybe. I think writing this was a fun experience, but although an implementation-status header could be a very nice tool in some places, the ability for its abuse, and its use of external linking could cause for additional spam or undesirable extra flare.

[eip-review-bot]

File ERCS/eip-1.md

Requires 2 more reviewers from @g11tech, @lightclient, @SamWilsn, @xinbenlv