FediForumTM

Event Listing

Project Map

@fediforum@mastodon.social
@fediforum.org
FediForum October 2025:

Alternative Architectures for ActivityPub

/2025-10/session/6-a/

Topics:

Convener: Emelia Smith (@thisismissem@hachyderm.io, @thisismissem.social)

Participants who chose to record their names here:

Website none, maybe a blog post or video in the future.

Notes

There will at some point be a video talk of the introductory piece that explained all the framing, and I’ll figure out how to publish a blog post for this too.

  • Problems today:
    • Community server apps translates the Activity Streams object to its native domain model and bolts on federation after.
    • Accounts and handles aren’t portable on social web today, so people have to sign up on multiple services and have multiple handles.
  • What if we decouple parts?
    • Account has a handle (how you’re addressed), an identifier (machine usage), and some credentials for authenticating.
      • Instead of Mastodon, Pixelfed, Ghost, et al have all these parts, your handle resolves to account+identifier+credentials. Thought explored in previous session by Bumblefudge.
      • Splitting handle is straightforward, but splitting other parts is harder.
      • Credentials are username/password + OTP and cryptographic keys for verifying requests (HTTP Message Signatures, Object Signatures, etc)
    • Data : inbox & outbox (also collections)
  • ActivityPub spec never says you have to have a server, only an actor with an inbox and possibly an outbox.
    • Account and data can be in different places. An app like Mastodon could just read the data from where your account and data are located. It’d just use your same data. Use OAuth for authorizing apps to access data on your data server. Federation then happens between your data server. Your account and data are federating, not the Mastodon/Pixelfed/app user experience.
    • The OAuth should be a standardised profile that is safe for sending tokens from a trusted server to an untrusted server, should protect against common attacks.
  • Additional views could be introduced that could be more useful to the specific apps accessing the data server.
    • Moderation challenge: User could follow a moderation actor. and then apply its data to a particular view.
  • Mobile app could talk directly to account & data server or to a particular view or to multiple views of data.
  • Comments in chat:
  • Similarities to AT Protocol setup. Currently each component in architecture is own service, but another is turning into them all into one deployable thing.
  • Discussion: History of people prototyping concepts in Ruby on Rails, but maturity is now a time for refactoring and coming up with an architecture that scales and serves the known uses better.
    • It was essentially what was easiest to developers who had experience building traditional webapps.
    • Solid struggled with adoption partly because the learning curve was way too steep: wait, I need to learn json-ld and client-side application development, and and and.
  • We’re already also seeing alternative architectures being explored by the ATmosphere (AT Protocol community)
  • ActivityPods: https://activitypods.org/
  • Bluesky taking efforts to IETF: https://docs.bsky.app/blog/taking-at-to-ietf
    • There’ll probably be some interesting changes based on what can be standardised when and how.
  • GNAP, successor to OAuth 2: https://www.rfc-editor.org/rfc/rfc9635
    • Emelia: This was absolutely going to be mentioned, though so far I’ve not seen wide-spread adoption, and it’s also why I’m against the endpoints.oauthAuthorizationEndpoint and endpoints.oauthTokenEndpoint properties in Actors, because it locks us into OAuth, when alternative authentication protocols exist and can be used, so I really want to see these endpoints deprecated in favor of having an authentication object that can be one or multiple mechanisms. Additionally just those two OAuth endpoints do not allow interoperability, you need OAuth Authorization Server Metadata for that!
  • https://Slices.network
    • This is SaaS to build AppViews that aggregate data and provide custom “lexicons” (activities and objects) for new applications.
    • Also automatically generates an SDK for your “AppView” for you to use in your client.
  • NextGraph: peer-to-peer but with offline server assist: https://docs.nextgraph.org/en/introduction/
    • Also being adopted by ActivityPods.
    • Strongly RDF based, has a learning curve.
  • Jeremiah: Curious why the pull-based model of RSS isn’t more popular architecture? Caching static content is well known. Pulling in content on client devices puts compute on the client. I know there is still a need for a server for the 2-way interactions, but if we’re splitting responsibilities, could this be part of that split?
    • We could do pull based, we could also do push from the “PDS” (data + account) to the views of that data. Many different ways to approach this; In pull-based, you’d still need server software to accept inbound activities (like Follow and reply with Accept(Follow).
  • This is what I’m currently experimenting with: https://github.com/ThisIsMissEm/activitypds/
    • Node.js, TypeScript, uses Fedify & @atproto/oauth-provider, sqlite but as a key/value store
    • It is highly experimental and not for deployment.
      • Many shortcuts taken to get an MVP together to prove the ideas.