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

@hongminhee

Exciting! And hopeful. Thank you!

@hongminhee sounds spooky, but very worth the effort! best of luck!

@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.

• @Mike Macgirvin ?️. He invented nomadic identity in 2011. He was the first to implement it in Red (which became Hubzilla in 2015) in 2012.
  His streams repository, a fork of a fork of three forks of a fork (of a fork?) of Hubzilla, is the place where he laid the foundations of FEP-ef61 out of necessity because he was working on nomadic identity via ActivityPub (Hubzilla and (streams) use their own protocols for that), and it was the first nomadic server software that had it implemented.
  Also, his Forte, itself a fork of the streams repository, is the only Fediverse server software that uses nothing but ActivityPub to establish nomadic identity and relies on FEP-ef61 to do that. Basically, it's (streams) with no Nomad and Zot6 support, and syncing between clones is triggered by a cronjob because, unlike Zot6 and Nomad, ActivityPub doesn't provide any ways to trigger immediate, near-real-time syncs.
  Mike hasn't been caught online for quite a while, though, although he's still working on both (streams) and Forte.
• @silverpill is gradually turning Mitra from a typical non-nomadic, account/login-equals-identity, one-identity-per-account Fediverse software into something that's every bit as nomadic as Hubzilla, (streams) and Forte while casting everything necessary for this process into FEPs.
  I'm not sure whether this will include containerising identities like the channels on Hubzilla, (streams) and Forte and allowing multiple fully independent identities on the same account, just like the same identity (channel) would be able to exist on independent accounts on different servers.

@hongminhee love to see this. and the backwards compatability is nice too

@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.