Add a basic metadata attribute tied to marker address

[iramiller]

Summary

Add support for a json document linked directly against an address using an attribute.

Problem Definition

One of the common requests from users is the ability to attach some basic context information against an address to provide additional background. This data could include information that would generally be associated with basic digital assets (such as links to off chain data) or Opensea specifications (https://docs.opensea.io/docs/metadata-standards).

While the metadata module provides the ability to represent programmable digital assets that involve off-chain processes and multiple parties, often a single self contained digital asset is sufficient for modeling.

Proposal

Using a new protocol owned name from the name module, create a standardized attribute that can be written by the protocol against any address. As the attribute can only be written by the owner of the name the protocol will need to offer methods for reading and writing this particular attribute.

Using this standard metadata attribute add methods for writing this same data against scope and marker addresses.

Data being recorded should be in JSON format in order to promote the most accessible and interoperable standard for its use.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[SpicyLemon]

Just getting started on this.

I'm not exactly sure what to call it. I feel like "metadata" is a poor name choice due to both the x/metadata module and denom metadata. But the only thing I can think of right now is "Account Metadata."

That being said, here's what I'm thinking.

1. Create a new root name owned by the attribute module (or maybe the name module?). Probably account.metadata, but maybe just metadata.
2. Add an endpoint to the attribute module for normal accounts to set their metadata, e.g. SetAccountMetadata. It'd take in the address (signer) and the value.
3. Add an endpoint to the marker module for an admin(?) to set a marker's account metadata. I'm not sure what to call this, though since "metadata" might be easily confused with "denom metadata". But maybe SetMarkerAccountMetadata. It'd take in the denom, signer, and the value. I'm not sure what permission the signer would need though (admin? deposit? mint?).
4. Add an endpoint to the metadata module for setting a scope's, erm... account metadata. Possibly SetScopeAccountMetadata. It'd take in the scope id, signer(s) and the value. I'm guessing the signer(s) would be validated against only the value owner, but I'm not sure if that's correct.

---

So here's some outstanding questions:

1. What should I name the attribute? account.metadata, metadata or something else?
2. Who/what should own that name? x/attribute module account, x/name module account, or some other account?
3. What marker permission should the signer need to update the info? admin, deposit or something else?
4. Who, in the scope, should be able to update the info? value owner, scope owners, or some subset/combo of those?

[iramiller]

I also noticed the metadata overlap… what about simply ‘AccountData’? I feel like this name would be owned by the name module-module account.

I’m open to suggestions on which grant has the ability to set this field on the marker… obviously the manager would… but I guess after that likely the admin is the only existing choice.

On the scope I would say the owners proper. This is based on the idea that ethereum nfts are largely maintained by the contract owner and not the account owner. You can’t rewrite your bored app attributes for example.