Should one be able to publish a portable object that is repudiable? IIUC, FEP-ef61 portable objects (identified by ‘ap’ URIs) require FEP-8b32 integrity proofs, so they are non-repudiable. On the other hand, FEP-c390 identity proofs establishes links between DIDs and HTTP(S) actors, but they don’t make objects portable. So that seems to be not possible with current proposals.
I’m curious because there are cases where one doesn’t want non-repudiation. For example, you don’t want your private message to be disclosed by the recipient in a publicly verifiable way. But that does not necessarily mean that you don’t want the object to be portable.
this could work but only if the rotation was a “blind rotation”, i.e. without a verifiable log of the old key being associated with the identity. if there is a log of the key rotation, then no.
more pressingly, if the key is your identity, then it cannot be rotated without also fundamentally changing your identity. so key rotation with repudiation requires a non-key identity – in other words, a name (and authoritative name server) or description (and a way of asserting trusted claims that match the description).
from what i understood of the paper, it seems this is just delegating signatures to some authority who can sign things on your behalf. you can then claim the authority forged signatures on your behalf. it’s basically like how fedi uses custodial keys in most cases.
The core idea is replacing HTTP(S) URIs with server-independent identifiers: ap:// URIs that use a Decentralized Identifier (DID) as the authority component, rather than a domain name. An object identified as ap://did:key:z6Mk…/actor can live on multiple servers simultaneously and survives any single server disappearing.
I’m new to this proposal and trying to wrap my head around some of the design choices.
I’m part of a project where we’re planning to implement proper DID-based identities, so this discussion is very relevant for us. There are a few things I’m not quite understanding yet:
1. Why split a user’s activities across several servers?
From an implementation perspective this seems to add quite a bit of complexity. What’s the practical benefit of distributing objects across multiple gateways instead of just having a single hosting server?
2. Which server is authoritative?
If multiple servers can host or serve the same actor or objects, how do other servers know which version is the canonical one if something differs?
3. Why not just point the DID to the user’s current server?
If the goal is portability, it seems like the DID document could simply reference the current hosting server, and when the user migrates the DID document updates to the new one. What problem does the multi-gateway model solve that this simpler approach doesn’t?
Would appreciate any clarification from folks who’ve worked through the tradeoffs here.
This is for redundancy. If one server suddenly goes offline, you can continue posting from another server. Having accounts on multiple servers is not a requirement, though.
The final authority is a client that holds signing keys (which may be integrated into a server).
Among the servers where actor is cloned, the primary gateway is a bit more important than the others. It is the first item in actor’s gateways array.
Not all DID documents can contain arbitrary data. did:key documents can’t.
The ability to use multiple gateways seems to be orthogonal to that, though. You can use a single server and add a reference to it to the DID document (in addition to actor’s gateways), that would still be a compliant implementation.
I’m currently working on a new DID method based on IPFS/IPNS. It doesn’t rely on blockchains or centralized infrastructure like DNS or PLC, and the DID document itself is stored in IPFS.
Reading your answers made me wonder if the architecture in this FEP is partly driven by the fact that it uses did:key.
In other words, if you had a DID method where the DID document can contain arbitrary data (for example service endpoints or the current hosting server), would you still go with the same multi-gateway architecture?
Or would the design look different if the DID document itself could point to the actor’s current server?
The proposed design is indeed significantly influenced by did:key compatibility requirements, but not the multi-gateway part.
Multi-homing was a feature of FEP-ef61 predecessors, Zot and Nomad protocols. My goal was to replicate the strengths of those protocols in ActivityPub.
did:key identities are long-living, so I think FEP-ef61 should offer an option compatible with post-quantum signatures, in addition to Ed25519 which is currently recommended.