Refactor Subject (resource identifiers / urls / dids / ids)

[joepio]

I want to very severely change how AtomicServer uses URLS / IDs / Subjects. Right now, Resources are identified by HTTP strings. This has some issues:

• Setup is hard. We often need to set ATOMIC_SERVER_URL. I really want to get rid of this as much as I can. I encountered this while I wanted to work on AtomicServer as homeassistant add-on #1138
• Moving domains is hard. When we change the domain, we break the IDs, even if we migrate the local data. See Dynamic server URL in subjects - make moving servers between domains easier #590
• Server dependence. Local-first data is cool, because things can work offline (Local-first resources - don't require a server when creating a resource #998). I want to move towards this paradigm. That means we need to have a different way of identifying resources. We'll probably need a did scheme at some point. Maybe we'll use did:ng, see Merging with NextGraph #1012. Maybe we can even make it work over a mesh Atomic over mesh #1137

When migrating to a different Subject type, I think we should also have these considerations in mind:

• We have to get rid of a lot of Db:get_server_url, which we used to construct Subjects for endpoints. We should use
• A single AtomicServer instance can have multiple subdomains (Wildcard subdomains #502), for different drives. The subject type should work with subdomains.
• I think it should probably be some new type of struct / enum. It should probably be domain agnostic, but it should be aware of a potential subdomain if added. Could internally use Url
• It should probably be able to handle multiple types of URL schemas, like did:ng or did:ad. I don't know exactly how these should work. When resolving these resources, the logic will be different.
• Maybe a URL type suffices. Maybe we transform request to the current instace to some this-server domain or something.
• Resources internally should not have the current domain hardcoded in their strings, including their references to other internal resources. These should maybe all use this-server as domain.
• We'll need a migration script to update existing Subjects
• Existing HTTP URLs should continue to work, of course
• A single AtomicServer can be available on multiple URLS. For example, with multiple subdomains. Or on an IP. All of these should work. They should just emit other Subjects, depending on who requests it. So they are dynamic, need to be set when serializing the data. This has impact on Commits! I think this is where we really need the new "first commit signature" identifier that I describe in In search of the perfect identifier: about subjects, URLs, CIDs and more #1114

Related to:

• Change subject / string type arguments #561
• Local-first resources - don't require a server when creating a resource #998

[joepio]

Currently working on an approach where we have a new Subject enum (either external, internal, or did). Also trying to get rid of all the server_url calls and ENV, since servers can have multiple, and we want this to be request / origin dependent.

Biggest thing that I kind of forgot about, was that this also means that subject in Commits can move. And that's a problem, because Commits are immutable. The solution here, IMO, is to use did:ad where we don't use the domain of the server but we use the signature. I think we should include at least a hint of where the server (or servers!) is available, though. Maybe an array of hosts as a property in the Resource? Maybe also later add a pretty-url or slug that has a space within that host!

[joepio]

I'm thinking about did:ad resources and hierarchies. Since did:ad things can be created basically anywhere, we may have to consider how they work in a hierarchy. If it's an HTTP parent, how do we deal with rights? Typically, we fetch the parent and check their rights. But what if that parent is offline? We don't want to prevent the user from making commits of course. We could allow that to happen regardless, a server can still reject commits if they don't comply. But that could lead to inconsistencies. We could also let a creator of a resource always edit it. Or maybe explicitly add a write attribute with the creator.

[joepio]

We're getting closer to being compatible with did, but we're gonna encounter a problem.

The W3C did spec requires the did resource to resolve to a JSON-LD file with an @context, an id and a verificationMethod. The rest is optional. Would require a custom serializer though, because JSON-LD properties are typically not valid atomic data (although the inverse IS true!)