Ideas for How ActivityPub Might Solve this Problem that BlueSky Points Out?: https://www.timothychambers.net/2024/03/29/ideas-for-how.html

Tim Chambers

Maho Pacheco 🦝🍻

@tchambers when coding activitypub for my site I learned that the actor (webfinger+actor+pub/priv keys) can be in a different domain than the inbox endpoint.

Portability of actor is as today technically posible then, you need to own a domain and be completely disconnected to where the inbox (which handles follows, replies, etc.) is hosted, in theory decentralized. The posts already live federated.

Sebastian "spaetz" Spaeth

@mapache @tchambers yeah, seconded. Cryptographic portable identities make the whole system much more complicated and fragile. Webfinger can connect any id to any server account right now and can be a simple static file if needed. Disconnecting your user domain from the server your account runs on is a easy first step.

Plan B, just as an MX DNS entry points to the mail server that handles your domain, you could also use a SRV entry to point to a Activitypub server.

Maho Pacheco 🦝🍻

@spaetz @tchambers we are not far away from that in the tech/code/implementation side.

The backend (inbox + cache + relay) which is now the instances could easily scale and be distributed. You could theoretically have a instances-market.

And yes, the mail DNS example is on point.

Erlend Sogge Heggen

@tchambers it requires #NomadicIdentity for the account portability, and some form of #POSSE so that you always have a personal copy of your data in case the server you’ve deferred to goes abrubtly defunct without notice.

POSSE doesn’t need to entail a completely separate app/feed that you self-manage though, it could be as simple as your fedi client keeping a local copy of your content, and maybe backing it up on a cloud drive.

For nomadic identity, @arcanicanis is apparently close to a PoC.

arcanicanis

I am actually pretty close to a working concept, just "hemming and hawing" over the deep implementation specifics, as I'm trying to implement Portable Object support entirely as a plugin for my ActivityPub server project. I should be able to achieve demonstrable results by next weekend.

Invariably, it should be very possible to have a portable profile, while still being understood by existing implementations, it's just going to end up with URLs getting a bit longer. Within the proposed extension, there is simple remark for compatibility with existing implementations: https://codeberg.org/fediverse/fep/src/branch/main/fep/ef61/fep-ef61.md#compatibility

Essentially what this could look like, is where instead of purely DID-based identifiers, that the DID is appended to the "DID resolver endpoint" of their main server. Portable Object-aware servers could then strip the URL down to the plain DID, and store it in DID representation (with the original URL as an alias to it). Meanwhile, conventional servers could still be able use the resolver-based URL just like any other typical ActivityPub server.

For practical example, of a DID into a resolver-based URL, the transformation would be from a portable identifier of:

did:ap:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/posts/2024-03-30/123

into https://example.social/did/did:ap:key:z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/posts/2024-03-30/123

It's ugly, but it works, but it can also pressure vendors to add support, and thus be able to make use of more compact representations in the database too, as another benefit.

Meanwhile, in regards of Bluesky, my big concern is that users don't even control their identity. Whereas in my current understanding: users don't have access to the private keys associated with updating their did:plc identifier, which controls what PDS a user is even on. And even if Bluesky gave you control to change your PDS in the future, they would still ultimately hold control over your identity, if they hold exclusive control of those private keys.

Erlend Sogge Heggen

@arcanicanis marvelous!

Is it possible to condense that explanation into ELI5 terms? Quite that basic isn’t possible I guess, since certain technical details are unavoidable at this level.

But we will need a way to explain these things to internet users who have a decent grasp of concepts like servers and public/private keys (essentially passwords, I.e. secrets), but lose the thread when DIDs and Portable Objects enter the chat. (I’m one of those people).

Erlend Sogge Heggen

@arcanicanis

> Meanwhile, in regards of Bluesky, my big concern is that users don't even control their identity.

As of today that is also the case for AP users. We must consider both standards as continuously evolving and subject to change.

> (…) they would still ultimately hold control over your identity, if they hold exclusive control of those private keys.

Maybe @bnewbold can speak to that IF of exclusive control. My understanding is they’re working towards non-exclusive control.