Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedify—server-independent #ActivityPub identities backed by #DIDs, ...

submitted by

Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedify—server-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It’s going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it’s worth doing right.

https://github.com/fedify-dev/fedify/issues/288#issuecomment-3971459585

#fedidev #fediverse #PortableObjects

3
3

Log in to comment

Hot Top New Old

@hongminhee@hollo.social nice! though I’d encourage using a root identity that’s an actual DID document (not just did:key), and points to the service(s) through which it works. Whether that’s did:web/vh or did:plc or some other did method, the properties of a full DID document are very useful.

 reply
2

@thisismissem @hongminhee imo the value of a did document is overstated -- did can be a useful framework for how to interact with identities that *can* be operated on and *can* have keys and *can* link out to other services, but none of those things are actually required and a lot depends on the actual did method to fill in that framework. in the case of did:key, the "key" method is just a thin wrapper around a key (for when that key is the identity). this makes the key valid for *any* purpose.

 reply
1

@hongminhee It is a good plan!

FEP-ef61 is still DRAFT and includes a warning that the URI scheme may change to ap+ef61.

Right, all of this is very unstable and may change in the future. In order to be more confident with the spec, I want to build:

- A fully featured FEP-ae97 client (WIP: https://codeberg.org/silverpill/minimitra)
- A generic FEP-ae97 server (this is only an idea: https://codeberg.org/silverpill/feps/src/branch/main/fc48/fep-fc48.md).

Gateway forwarding trust. When forwarding inbox/outbox activities to other gateways, which servers should be trusted and how should that trust be established? FEP-ef61 says unsecured collections may only be accepted from servers in the actor's gateways array, but the details of how a gateway authenticates itself to another gateway are not fully specified.

Could you clarify what you mean by authenticating itself to another gateway?

When an application (client or server) fetches a portable collection from a server that is listed in actor's gateways array, it may skip proof verification. This applies to collections like inbox or outbox.

If a portable collection is fetched from some other server, the proof is required.

 reply
1
OP

@silverpill@mitra.social Thanks for the clarification! I think I was overcomplicating it—I was imagining a scenario where gateway A forwards a received activity to gateway B, and wondering how B could trust that A hadn’t tampered with it. But of course, since portable activities must carry FEP-8b32 integrity proofs, the authenticity of the activity itself can always be verified regardless of which server forwarded it. No separate gateway-to-gateway authentication mechanism is needed.

And the gateways-based trust makes sense now as a mechanism specifically for unauthenticated collections—if a collection comes from a server listed in the actor’s gateways array, proof verification can be skipped; otherwise it’s required.

 reply
1
Insert image