Discuss Orbit Discovery and Management

[wyc]

Metadata

What data define an orbit? Here are some ideas:

• Patricia Merkle trie root hash of most current content updated by administrator
• Patricia Merkle trie root hash of most current authorization policy log updated by administrator
• List of IPv4/IPv6/etc. hosts that are in the orbit
• What else?

Discovery

How do you find an orbit? Here are some ideas:

Public Orbits - meant to be discovered and and accessed by anyone

• Smart contracts on public blockchains
• DHTs that are publicly accessible a la bittorrent

Private Orbits - meant to be selectively disclosed

• Smart contracts on private blockchains
• Smart contracts on public blockchains with encrypted contents
• Permissioned DHTs or distributed databases, possibility implemented using an Orbit
• FTP server

Management

How are orbits administered? TBD

cc @chunningham

[chunningham]

Re: Discovery, I've been thinking something like the following:

• All Kepler instances share a public DHT using a public shared key to isolate traffic from the public IPFS network
• In IPFS, the DHT describes providers of content addresses. In the Kepler orbit discovery DHT, nodes can query for providers of an orbit. this query returns one or more http endpoints (or a more generic address type)
• on HTTP GET/POST requests, if the Kepler node does not host that orbit, it can query for a provider address and Redirect the request (redirect is preferable to returning the data via the nodes to prevent the non-host from seeing the content, and also because the non-host may not be able to verify the request authorization)
• if the orbit is administered via smartcontract, the contract state can be queried instead of/in addition to the public DHT
• this implies that to be discoverable, the orbit config must be public (or at least the set of host addresses must be verifiable against the orbit address)

does any of this make sense?

[chunningham]

Re: metadata, the auth policy log commitment and admin/host lists are essential to include. A tree hash of contents would allow for explicitly checking consistency between hosts (something IPFS already does but that other storage backends may not (e.g. multiple separate S3 buckets operated by non-cooperative hosts)) so might be a good option, but it would require a much more regular state transition to make that check timely (basically introducing block/confirmation time). given a deletion capability tho it might be essential. A human-readable name might also be useful in the metadata.

[wyc]

@chunningham recording our conversation here for future design sessions.

Potential short-term orbit ID strategy: hash the client PKH concat w/"orbit secret" that the client picks. This could be static for something like tzProfiles, provided by the tzProfile frontend.

Orbit resolution architecture--kind of similar to DIDs. Here's one example of how it could work:

1. Every change to the Orbit State (latest merkleroot hash, hosts policies (who are the replicators?), content access policy, etc.) is a signed patch/CRDT/delta/etc. The patches can hold some kind of evidence of existence at a point in time, such as a blockhash from Bitcoin, Tezos, Ethereum, etc.
2. For our orbit type, it starts with a default state that the patches continue upon.
3. Patch state build with correct patches (signing was authorized correctly and data layer consistent) and the most recent evidence of existence wins.
4. We can access the list of patches from a KV query with the Orbit ID as the key. This could be public or permissioned depending on use case.

[wyc]

From our discussion, here are the roles for orbits:

• Orbit Commander: Can do anything
• Read Delegator: Can delegate or revoke scoped capabilities across all Read operations.
• Write Delegator: Can delegate or revoke scoped capabilities across all Write operations.
• Writer: Can perform all Write operations.
• Reader: Can perform all Read operations.

Here are rough metadata structures:

• HostMap :: Map PublicKeyHash [IPAddress]
• ContentMerkleRoot :: [u8]

Signed object capabilities can contain cryptoscript/ioscript as an unlocking mechanism, not dissimilar from bitcoin's Script. E.g., cryptoscript to allow a download of a JPG for an NFT owner:

FA2Asset -> AssetId -> VPSigner -> Bool
getOwner  -- consumes FA2Asset and AssetId, pushes TezosAddress to stack iff successful
asTezosAddress. -- consumes VPSigner, pushes TezosAddress to stack iff successful
assertEqual  -- consumers TezosAddress and TezosAddress, throws nothing iff successful

This could be embedded in something like a ZCap and the "VPSigner" could be equivalence checked to the NFT asset's owner.

[wyc]

Discovery about orbit discovery:
Here is the orbit string:

tz:${INDEX}:did:...
tz:KT1...

The DID included MUST resolve to a DID document with an authentication method using an Ed25519 public key, secp256k1 public key, or P-256 public key. A BLAKE2B (digest-size = 20) hash of that public key is also acceptable. Examples of conforming DID methods include did-tz and did-pkh(:tz). The orbit config lives at the ${INDEX}th smart contract
deployed which conforms to the Kepler Orbit TZIP (TBD). If this orbit config does not exist, then there is a default Orbit Config TBD.

If KT1 approach is taken, then the smart contract at that address MUST implement the Kepler Orbit TZIP (TBD).

Open questions

• What if the DID's authn method is rotated and it's a new key?