ENSIP-27: Node Classification And Metadata#64
Conversation
jmacwhyte
force-pushed
the
metadata-ensip
branch
from
0a17714 to
f05f7f4
Compare
| Nodes can specify a text record with the key name of `schema`, the value of which points to a JSON schema which declares which metadata attributes can be added to the node as text or data records, in addition to the global text records already specified in existing ENSIPs. The value of `schema` MUST start with one of the following prefixes, followed by the appropriate value: | ||
|
|
||
| * `ipfs://` - followed by the ipfs URI pointing to the JSON payload | ||
| * `https://` - followed by the http(s) URI pointing to the JSON payload |
There was a problem hiding this comment.
I suggest to generally encourage people to not use http prefixes if not completely disallow it. It just creates a bunch of problems downstream (file not available anymore, changed, etc).
Better would be ipfs (although also problematic as files on IPFS can disappear too), CBOR or data.
There was a problem hiding this comment.
I agree that in practice, IPFS and/or CBOR would be the preferred option to ensure data resilience. However, in the interest of flexibility, I wouldn't want to disallow http, because there could be some interesting, valid use cases. For example, if someone is maintaining a schema that is used by many nodes, they may want the ability to add more attributes to the schema by simply changing the file hosted via HTTP instead of needing to re-write every schema record across all nodes.
Writers and readers should understand the trade-offs when using http vs IPFS. I will make a note to update the ENSIP to say that IPFS and CBOR are the preferred options, even if others are allowed.
There was a problem hiding this comment.
@schmidsi I have expanded on this in the latest commit, please let me know your thoughts.
|
|
||
| * `ipfs://` - followed by the ipfs URI pointing to the JSON payload | ||
| * `https://` - followed by the http(s) URI pointing to the JSON payload | ||
| * `cbor:` - followed by the schema encoded in CBOR format |
There was a problem hiding this comment.
If multiple nodes use the same schema, then we might want to add an option to say: "same schema as wallet.ens.eth", or even a pointer like "person.schemas.ens.eth"
There was a problem hiding this comment.
That could be a useful feature, related to what I said above about http! I'll give some thought to how this could be achieved.
jmacwhyte
force-pushed
the
metadata-ensip
branch
from
d665491 to
79e9f6f
Compare
jmacwhyte
changed the title
|
We have labeled this as ENSIP-64, in anticipation of using PR number to identify draft ENSIPs. Happy to change if needed! |
|
Why not 27, 28? |
It has provisionally been named after the number of the pull request, to guarantee it won't conflict with anyone else. We are just waiting for someone from Labs to issue us a number from the new system. |
|
/assign-ensip |
|
All set — this proposal is now ENSIP-27. The number is reserved. Could you make these changes to your PR so it's ready to merge?
Thanks! |
|
@jmacwhyte I assigned an ENSIP number for you. In addition to the comment above, could you please add to the front matter of your file too (you can look at ENSIP-26 for an example). Thank you! |
jmacwhyte
changed the title
|
@wentelteefje All done, thanks! |
4 participants
This proposed ENSIP is the result of work that was sponsored by the ENS Metagov Working Group. It is currently a work in progress, and we are soliciting feedback and contributions from across multiple ecosystems.
This initiative aims to settle on a standard way of attaching metadata to ENS names/subnames (nodes), which can convey the organizational role of the node and include details that are important to surface on-chain (e.g. delegate and conflict-of-interest statements, the location of official wallets and contracts, agent metadata, etc). All of these details can then be found by simply querying the relevant ENS name/subname.
ENS Forum posts: Temp check, Kickoff
Project overview: Notion
For a TL;DR: of the latest design, see Technical design v3 on the Notion page.