- Lots of situations where an engine will want to store things keyed to a compound key (eg, engine data scoped to an account). Want to:
- Ensure decent DX around this for engine authors
- Ensure max usability for downstream UIs (subgraph, shell UI)
More thoughts:
- Types of data associated with entities:
- Data associated with the token
- readTokenString(location, tokenId, key)
- Data associated with the collection
- readForkString(location, forkId, key)
- Data associated with a (token, address) - doesnt exist
- readTokenAccountString(location, tokenId, address, key)
- Data associated with a (collection, address) - doesnt exist
- readForkAccountString(location, forkId, address, key)
- Data associated with a (collection, token) - doesnt exist
- ^^ method spam the right approach??
Could expand IShellFramework to add the last two. atm the only way to store data like this is to keccak the keys , which is hella ugly