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.
-
@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
gatewaysarray, 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.
@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'sgatewaysarray, proof verification can be skipped; otherwise it's required. -
@洪 民憙 (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 - @Mike Macgirvin ?️. He invented nomadic identity in 2011. He was the first to implement it in Red (which became Hubzilla in 2015) in 2012.
-
@洪 民憙 (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@jupiter_rowland@hub.netzgemeinde.eu 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@fediversity.site and the history here—I wasn't fully aware of how deep the roots of nomadic identity go.
- @Mike Macgirvin ?️. He invented nomadic identity in 2011. He was the first to implement it in Red (which became Hubzilla in 2015) in 2012.
-
> more modest goal: server-independent object identifiers that survive a server disappearing
does fedify support binding a base uri or fqdn to each individual actor? the most basic path to this starts with identifiers that outlive their servers, so instead of using the service's dns name, you can let actors bring their their own dns name.
you can imagine me not as mastodon.social/@trwnh but as mastodon.trwnh.com or trwnh.com/mastodon/ instead.
-
> more modest goal: server-independent object identifiers that survive a server disappearing
does fedify support binding a base uri or fqdn to each individual actor? the most basic path to this starts with identifiers that outlive their servers, so instead of using the service's dns name, you can let actors bring their their own dns name.
you can imagine me not as mastodon.social/@trwnh but as mastodon.trwnh.com or trwnh.com/mastodon/ instead.
@trwnh@mastodon.social Fedify currently doesn't support binding a custom domain to individual actors—all actors share the server's domain. Honestly, I'm not sure how that would work in practice either; it would need some kind of indirection or delegation mechanism at the HTTP level, and I'm not aware of an established spec for it. Do you have something specific in mind, or perhaps an approach you've been thinking about?
-
@hongminhee you can use HTTP 3xx redirects but that's not strictly necessary because you can use DNS A/AAAA/CNAME as well (and have the HTTP server respond to those names in conjunction with TLS SNI)
the idea is that multiple server names can be responded to by the same Fedify software instance. in nginx it's doable with the http.server.server_name directive. https://nginx.org/en/docs/http/server_names.html
SNI: https://datatracker.ietf.org/doc/html/rfc6066#section-3
does fedify expect to run behind a reverse proxy? if so, it can route requests.
-
@hongminhee you can use HTTP 3xx redirects but that's not strictly necessary because you can use DNS A/AAAA/CNAME as well (and have the HTTP server respond to those names in conjunction with TLS SNI)
the idea is that multiple server names can be responded to by the same Fedify software instance. in nginx it's doable with the http.server.server_name directive. https://nginx.org/en/docs/http/server_names.html
SNI: https://datatracker.ietf.org/doc/html/rfc6066#section-3
does fedify expect to run behind a reverse proxy? if so, it can route requests.
@trwnh@mastodon.social Fedify does run well behind a reverse proxy, and it doesn't actually require a fixed base URL—it can derive the base URL from the incoming request. Ghost takes advantage of exactly this to implement virtual hosting on top of Fedify, so in principle the kind of per-actor custom domain you're describing should already be achievable without changes to Fedify itself.
-
@hongminhee i think the only support from fedify needed is basically like an environment variable or property for wherever identifiers are assigned or dereferenced
so for example if the service is mastodon.social it would assign identifiers using trwnh.com/mastodon/ as a base uri
it only needs to know which uris are already used, so it doesn't assign an id that's already in use.
-
@hongminhee i think the only support from fedify needed is basically like an environment variable or property for wherever identifiers are assigned or dereferenced
so for example if the service is mastodon.social it would assign identifiers using trwnh.com/mastodon/ as a base uri
it only needs to know which uris are already used, so it doesn't assign an id that's already in use.
@trwnh@mastodon.social Actually, Fedify already supports this quite well. The actor dispatcher gives you full control over the actor's
id—you can set it to any URL, including one on a custom domain. And since Fedify 1.4.0, there's amapAlias()method that lets you handle WebFinger lookups for those custom URLs too. So running Fedify behind a reverse proxy that routes multiple hostnames, and assigning per-actor custom domain identifiers, should be achievable without any changes to Fedify itself. -
@hongminhee so are object ids handled outside of fedify? the application written around fedify would have to keep track of which ids are already used/assigned?
-
@hongminhee so are object ids handled outside of fedify? the application written around fedify would have to keep track of which ids are already used/assigned?
@trwnh@mastodon.social Yes—Fedify is database-agnostic, so tracking which IDs are already in use is the application's responsibility. Fedify handles the federation layer, but the data model and storage are entirely up to the application built on top of it.
