Here is a quick recap of some topics we have been investigating, and the decisions they led to:
JSON
Many related proposals (e.g. EIP-4824) have suggested pointing to JSON payloads to convey structured data. The first iteration of our plan also included using JSON to describe organizational structure.
We’ve since decided that this spec should prioritize on-chain access and ease of use, and so JSON should be avoided. Metadata attributes should be included as standalone records, allowing them to be queried and updated individually. This also makes it possible for users to manually query and manipulate individual records if needed, which greatly improves ease of use.
If a particular attribute needs to contain a complex value (like an array of entries), CBOR can be used to encode the value of the attribute, but multiple attributes should not be combined into one record.
Naming conventions
We looked into schema.org and various ontological organizations to see if there is an existing standard for naming data which could be applicable for our metadata attributes. None of the options we looked at included enough values specific to our use case, so they didn’t seem appropriate to implement and we are confident that defining our own attribute names will be acceptable.
Schema.org is focused on websites and SEO, however in the future it might be nice to have our attributes added into schema.org so that the same attribute names could be used when on-chain data is displayed on web pages. In anticipation of this, we will attempt to draw from schema.org’s existing naming conventions where applicable (e.g. attributes describing people), but we will prioritize choosing names that are most appropriate for the situation and not go out of our way to follow conventions which were designed for a different technology.
Next steps
We have begun drafting an ENSIP and creating mockups of what a UI implementation would look like, which will allow us to have more concrete technical discussions.