Namespacing/Addressing thoughts

[MikeFair]

I was wondering about using/supporting this for a key addressing scheme.

Consider these references for a key:

dbname/tld/domain/ipld/somekey/childkey
domain.tld/dbname/ipld/somekey/childkey
ipld.domain.tld/dbname/somekey/childkey
somekey.ipld.domain.tld/dbname/childkey
childkey.somekey.ipld.domain.tld/dbname/

Everything but the first one could have http:// thrown in front of it and work.

Users wanting DNS compatible databases should put a {"tld" : {"domain": {"ipld": {link}}}} key link at the top of their db that links to the rest of their database. This takes care of potential data value requests for those parts o the keyspace hierarchy that were created primarily for making the DNS query work....
....

From there "dbaddress" is some top level ultimate database starting point in the IPLD infrastructure.

While this database might be linked to by some other database (possibly multiple even), the way it was referenced makes it impractical to try and "go up" from here.

....

Everything coming before the first / is treated as the root context for database operations. The :portid that can optionally be after the domain name is an "allowed but ignored" part of the root context.
Everything after dbaddress is treated as the application's referenced keyname at that db root context.

Extended query response objects could be something like:

for childkey.somekey.ipld.domain.tld/dbname

{
  "database": "dbaddress"
  "root": "/tld/domain/ipld/somekey/childkey/",  
  "relid": "", 
  "key": "/tld/domain/ipld/somekey/childkey"
  "value": { "key": "datavalue" }
}

for ipld.domain.tld/dbname/somekey/childkey

{
  "database": "dbaddress"
  "root": "/tld/domain/ipld/",  
  "relid": "somekey/childkey", 
  "key": "/tld/domain/ipld/somekey/childkey"
  "value": { "key": "datavalue" }
}

for dbname/tld/domain/ipld/somekey/childkey

{
  "database": "dbaddress"
  "root": "/",  
  "relid": "tld/domain/ipld/somekey/childkey", 
  "key": "/tld/domain/ipld/somekey/childkey"
  "value": { "key": "datavalue" }
}

This approach treats every key in the database as a potential database root for a query, and it mimics, and is compatible with, the familiar http namespaces.

---

Because this naming convention enables any key in the hierarchy to be referenced as a root; that might be leveraged to create access control points for authorization. Just because any key could be made a root, doesn't mean the system has to accept that any particular root is valid for this database.