Post · bonfire.cafe

Post

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

Jupiter Rowland

@jupiter_rowland@hub.netzgemeinde.eu · 9 hours ago

@ 洪民憙 (Hong Minhee) :nonbinary: Two people you may consider consulting in this case:

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

That said, is your goal only to use FEP-ef61 for identities that are tied to their accounts and their servers? Or is your goal fully-fledged nomadic identity on the same level as on Forte?

# Long # LongPost # CWLong # CWLongPost # FediMeta # FediverseMeta # CWFediMeta # CWFediverseMeta # Hubzilla # Streams # (streams) # Forte # Mitra # NomadicIdentity # FEP_ef61

洪民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · 8 hours ago

@jupiter_rowland Full nomadic identity—the kind Forte and (Streams) have—is something I'd like to support in Fedify eventually. But for now, I'm focusing on the more modest goal: server-independent object identifiers that survive a server disappearing. The multi-server synchronization side of things feels premature to build out seriously until the relevant specs (FEP-ef61 itself is still DRAFT, after all) stabilize a bit more. Once the standardization catches up, I'd like to revisit.

Thanks for the context on @mikedev and the history here—I wasn't fully aware of how deep the roots of nomadic identity go.

@silverpill

silverpill

@silverpill@mitra.social · 10 hours ago

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

Codeberg.org

feps/fc48/fep-fc48.md at main

feps - My FEPs

Codeberg.org

minimitra

洪民憙 (Hong Minhee) :nonbinary:

@hongminhee@hollo.social · 9 hours ago

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