The benefit of well-known path is that you can use any server as a resolver without knowing its resolver endpoint in advance. It is now less important because hosts was replaced with aliases, but might be useful nevertheless. For example clients can try to resolve DID URLs on any big fedi instance if everything else fails.
If we learn from implementation experience that “following your nose” is enough, then path requirement can be relaxed.
Also, I’ll probably change “resolver” to “gateway” because I think it should accept POST requests as well. This will remove the step where client extracts URL from a Link header in order to POST to inbox.
Resolvers are now gateways and may accept POST requests.
Apart from that, I’m seriously considering switching to ap:// URL scheme as @bumblefudge suggested, to simplify the DID parser. The downside of a custom URL scheme is that most URL libraries will not work with such URLs. For example the Rust library I’m using thinks that multibase-encoded key is a port number and refuses to accept it.
Another idea: switch back from aliases to hosts (or gateways).
Can you provide design justifications for the “why” of the changes (so that the rationale—and the reason for why those choices were made—are more documented), each time changes are made?
Wouldn’t there be risk involved in using very vague property names (aliases, hosts, gateways) that could collide with other possible FEPs, for plain JSON (non-JSON-LD) implementations, instead of doing prefixed property names like “didHosts”, “didGateways”, etc?
Is there a use-case where multiple actors under one DID is justified, including potentially adding more complications (what if some actors, under the same DID, point to differing gateways/hosts/etc?)? I just had a system devised for storing actors and their respective objects with compacted identifiers, and that kind of nukes that idea, and creates more challenges to solve.
Whereas I had the concept of: the authority-part of the DID URL having 1:1 relationship with an actor in the database, and then being able to shorten any non-actor objects identified by DID, to the corresponding actor with the authority-part of the DID; therefore if did:ap:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2 corresponds with actor_id of 123, then an object authored by that actor under the DID URL of did:ap:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/posts/first-post could be compacted to a short-form of say $123/posts/first-post internally, for the database. But if the relationship is DID --(1:n)--> actor, then I can’t do that, and there’d have to be a separate resolver table between DIDs and actors next, if I were to achieve the same.
Additionally, if it’s multiple actors under the same DID, then any actor with the key has the capacity to impersonate other actors under the same DID.
The resolver → gateway change was discussed here earlier. This is needed to simplify inbox/outbox deliveries.
The identity → actor many to many relationship is not really a change, but a clarification. Identity (DID) is not tied to any particular object, it “owns” objects:
I updated description of the pull request with short explanations of the reasoning behind the breaking changes.
I think aliases property could be useful in other contexts (see FEP-d2a). I agree that hosts is too generic, a more specific name would be better.
Yes. Otherwise users will be forced to use a different key for each actor, even in cases where actors can’t exist separately from each other. Examples:
A group actor that is managed by a person.
A followable conversation context (a collection AND an actor at the same time) that is attributedTo another actor
1:1 relationship was never implied. Even in my prior work on nomadic identity, FEP-c390, there was many-to-many relationship between DIDs and actors. In FEP-ef61 it is limited to 1-to-N.
Yes, but is it really an impersonation if I own the private key that signs activities of both actors?
Am I missing something obvious here? The separation between identity and data is fundamental to this proposal, if we remove it everything falls apart.
This is an important change. The question of a canonical ID format should be settled as soon as possible, because several projects are already working on FEP-ef61 implementations, and the format can’t be changed once the code is deployed.