Reified Edges?

[the-frey]

Open question: is there utility in a primitive that shows the relationship between things? Would probably have to be a (mostly) open meta struct, but at the moment needs a bit more thought.

EDIT: more thought below. too much, if anything.

[the-frey]

Summary

Reified edges might in face be the general case of some of the additional tree and graph-based problems we have discussed elsewhere.

There are many use-cases where simple addressability is the concern and the question is mapping together two arbitrary things in the graph.

The first version of this nameservice focussed on a simple owner -> name mapping, but many more use-cases require a graph walk from a name to something that is not the owner.

We already have two use cases at present: subdomains, and addressing contracts.[0]

Subdomains

This solves the subdomains question, as outlined in #29 - allowing for recursive traversal in arbitrary graph walks, in the most flexible way possible. I suppose it opens up the question of "what is a subdomain anyway?" other than the OBJECT, where the SUBJECT is a name in the nameservice and the name is linked to

Addressing contracts

This solves (to some extent) the issue of addressing a contract, where the OBJECT of the edge would be another address - something simply not allowed for in the current scheme. #45

Discussion points

The remaining questions here are:

1. are edges their own primitive (some dynamic type T)[1] or are they themselves a named edge and simply a nameservice NFT with subject and object fields?
2. should this be in the same contract? (seems tied closely to the 'are these a nameservice NFT?' question)

[0] could be wrong, but feel like atm a DAO is covered by the standard owner -> name relationship just as a multisig is [1] at present we know of two edge types, Subdomain and Contract. Both expect a name as their SUBJECT, but have different types as their OBJECT (i.e. name and contract address respectively)

[the-frey]

Approach 2: (which is not incompatible with this, necessarily)

Contract can call the nameservice, where a receive msg will create an NFT with the caller (i.e. the contract) as owner and the name as a standard nameservice NFT.

This is potentially better as it simplifies the lookup in that case.

However, still think subdomains might be better expressed as a bi-directional edge.

[the-frey]

Current thinking on first pass here:

We have a type that is a TokenId | Addr, Entity, and an EdgeMetadata type.

pub const EDGES: Map<(Entity, Entity), EdgeMetadata> = Map::new("edges");

This, if we return to pseudocode, is effectively:

pub const EDGES: Map<(subject, object), predicate> = Map::new("edges");

Which fulfils our need to arbitrarily map the s - p - o relationship.

EdgeMetadata would presumably be a struct of type and description where type was an enum of:

(to cover the cases where the object is an Addr)

• Contract
• Wallet

(to cover the cases where the object is a TokenId)

• ?

An edge should be createable by the wallet or owner of the token that is in subject position.

In this example you would need a multiindex over type, and meta would need to contain a pathName, and then indexes over both subject and object to allow for querying, I guess.

[the-frey]

I think this means you'd set it up as an IndexedMap with a multiindex on the Type https://github.com/CosmWasm/cw-plus/tree/main/packages/storage-plus#indexedmap

[the-frey]

[the-frey]

So tl;dr the only thing we're really concerned about here is covering off the address case, and there's only a couple:

• wallet
• validator
• contract

and validator is probably already covered by the meta field, which means only contract|wallet

[the-frey]

Some additional scribbes from my brain dump

• subdomains are not NFTs(?) (re: uniqueness problem)
• subdomain paths need to be unique as a complete path
• subdomain paths may not be globally unique in of themselves
• subdomains (or edges) should be nameable like an NFT
• should subdomains be typed?
• how do you refer to a complete path or relation