Convener: Bumblefudge.com

Participants who chose to record their names here:

• Ryan Barrett (@snarfed.org@snarfed.org)
• nigini (@nigini@social.coop)
• Lisa Dusseault (@lisarue@mastodon.geekery.org)
• Erin Kissane (@kissane@mas.to)
• Darius Kazemi (@darius@friend.camp)
• Damon (@damon@social.wedistribute.org)
• Bob Wyman (@bobwyman@mastodon.social)

Tags / links to resources / technology discussed, related to this session:

• Migration user stories: https://codeberg.org/fediverse/fep/src/branch/main/fep/73cd/fep-73cd.md
• Move Actor (retro-spec generalizing Mastodon’s move mechanism): https://codeberg.org/fediverse/fep/src/branch/main/fep/7628/fep-7628.md
• Extension thereof + test cases + test vectors: https://codeberg.org/fediverse/fep/src/branch/main/fep/e965/fep-e965.md
• LOLA draft, discussed previously in this FediForum: https://swicg.github.io/activitypub-data-portability/lola.html
• Actor-Relative URLs (i.e. DID URL syntax for AP): https://codeberg.org/fediverse/fep/src/branch/main/fep/e3e9/fep-e3e9.md

Notes

15-minute rant:

• Although not a DID, ActivityPub identity systems are similar.
• You could “integrate” them, but it doesn’t make “business” sense to do it.

Q&A

• Ryan: Inbox delivery and object fetching are both so 100% HTTP, thus a non-DNS-based AP is hard to even imagine now (AP2.0 could do it, but that would still be a huge leap!)
  • AP Objects are orders of magnitude more numerous than actors.
  • Are DIDs a naming service? Suitable for actor scale or object scale? (AT Protocol uses them only at actor scale.)
• As an example, AT Protocol (Bluesky) uses DIDs for actors/users, IPLD CIDs for records (objects), which are immutable. Mutability is handled separately, in “repos.”
• What makes accounts more portable, OR, what makes servers more interchangeable?
• We explored a bit whether there was a backwards compatible way to introduce a wider variety of DIDs into ActivityPub in a version 2 - if non-https DIDs are an option, does that allow implementors who do support these DIDs to gain or add value even if the whole ecosystem does yet? We think so.
• Bumblefudge had a great point that there’s a whole other philosophy to give individuals greater agency in the Fediverse, besides just moving from one server (with its set of features) to another server with a better set of features, which is still putting the user at the mercy of their admin - the alternative is client maximalism with more features driven by clients and servers are less required to implement features that users want.
• (This individual agency philosophy is much more central in other networks, eg Nostr, Bluesky, Farcaster, and the fediverse is generally much more collectivist at the instance/server level, but it’s nice to see at least some of the individual-agency tooling coming together.)