subconsciousnetwork
Support for addressing/linking across spheres
Currently, we only deal with links that pertain to a single sphere with a known identity. However, for Noosphere to be fully realized, we need to enable linking from one sphere to a completely different sphere.
We can support these kinds of links separately from implementing DHT and other network-related capabilities by implementing the peer name resolution scheme in data structure terms. So, if I have a link @cdata/foo, I should have an address book in my sphere where I can look up cdata and resolve to DID. From the DID, I should be able to discover an associated sphere revision. The last known revision of any petnamed peer's sphere should be linked locally from your sphere, so it should be possible to resolve such links based on local data without reaching out to the network.
The DID itself won't be able to have a revision unless you in turn have some sort of "well known" place where the revision is kept based on DID.
It may be useful to look at Webfinger for ideas around this, and expand it / specialize it for DID and content addressing use cases.
There may also be some ideas from Mastodon from the shape of their network topology and naming. And yep, I remembered correctly, they use Webfinger https://docs.joinmastodon.org/spec/webfinger/
DIDs have universal resolvers which I am not a fan of because it requires network resources.
+1 for having this as "locally" resolvable as possible.
Thanks for calling out WebFinger :pray: we will definitely keep our minds open to other mechanisms for resolving the sphere CID of a user. Ideally, all mechanisms are on the table, and WebFinger is a tried and true one with known properties. I would be interested to hear more about how you think about applying a mechanism like WebFinger to scenarios like ours.
The challenge presented by our architecture is: there is no specific server that can be relied on to hold sole responsibility for resolving a resource from a URL. To put it another way, our architecture expects that servers are fungible, so may appear one day and disappear the next; the user's content remains addressable and update-able at all times.
I glossed over a few steps in the original issue because I consider the basic notion of addressing another sphere to be decoupled from the notion of e.g., using a DHT to resolve the latest revision of the sphere. In the big picture, there are some additional steps (tying in to #12) that are critical to our approach: resolve DID to public key, then resolve public key to DHT value (which for our purposes will be a CID). All of these steps call for network infrastructure. But, once these resolutions have been performed, all the state is permanently cached and future network action only needs to happen when the user tries to pick up updates. This means that the core capability of resolving a sphere from an entry in your address book should be able to be done locally on cached data. By designing with the cached data case as our first-class case, we ride the fine line of being local-first without running a "full node" on the client. How the resolutions are performed and the data comes to be cached locally is another (hopefully separable) question (and there is room for many different answers to be implemented in time).
We will not support all DID methods, and for the first stage of this we may only support DID Key because it's the most straight forward with regards to resolving the public key (and everything can be done locally). I'm not sure that we will be able to avoid some amount of indirection (and hence network resolution) for DIDs in the end, but it would be cool if we could.