Since our last update, we have completed another technical revision and greatly simplified the design of the system. It now allows us to rely less on validation rules enshrined in off-chain documentation, and makes it easier to have all intentions live on-chain. We also finished the first draft of our ENSIP, which we will iterate on together with contributors from the community.
Both of these can be found on our Notion page, with a quick overview below:
Technical design revision (v3):
We introduce two new global text record key names: “class” and “schema”.
By setting a “class” text record on a node, one can declare the organizational role of that node and that of the address it points to. This is mostly for the benefit of humans who are trying to understand the purpose of each subname, however these values can also be used by machines to classify or seek out specific types of nodes. The ENSIP includes a list of common class values (like “wallet” and “contract”) together with a description of each. Although any value can be used, sticking to one of the predefined values will increase compatibility across the ecosystem.
We’ve also introduced a “schema” record, which contains a URI pointing to a JSON schema definition which explains what attributes can be added to the node as additional text records, including the key name, type, and description of each.
If a “schema” record is populated, automated systems can ingest it and find out which key names they should query to retrieve the rest of the metadata. Additionally, standardized schemas can be published, allowing everyone who uses them to have their metadata properly formatted and presented by dashboards and other systems.
Once populated, this combination of records can be used to visualize ENS names in various ways:
Above: A hierarchical view of an entire ENS name can be displayed, highlighting the class value of each node, allowing for a human-friendly overview of the organizational structure.
Above: A node can be examined in detail showing its declared class and/or schema-specified attributes.
Above: All nodes can be autonomously indexed, with each node’s full ENS name as an identifier showing how it fits into the overall structure. When turned into a database (or spreadsheet), it is now easy to identify all of the key components of the organization or sort the data in different ways.
Additional details:
The draft ENSIP and technical overview on our Notion page include more detailed information, such as complex record types and how certain use cases could be achieved.
Next steps:
Now that we have collected community input, done research, designed a system, and drafted a proposed ENSIP, we are now ready to continue with community outreach and invite feedback and suggestions from contributors (phases 3 and 4 on our roadmap).
If you have any comments or feedback to share, please feel free to reach out! (details on the Notion page)