ActivityPub and RPC: Climbing to the Next Level

tl;dr I’m proposing to switch from using plain AP to distributed-actor-programming with an AP layer just for the social/follow/comment/notification aspect


Lately, in my work on ForgeFed, I noticed I’m using ActivityPub for 2 things:

  1. Social, i.e. actors can follow other actors and get notified about their activities, and actors can comment on stuff that other actors publish
  2. RPC, i.e. actors can request other actors to perform actions, also known as invoking methods/behaviors of actors, allowing to edit/manipulate shared resources in simple and complex ways

While implementing ForgeFed’s custom OCAP system and some forge features based on it, I began to realize that ActivityPub really isn’t suited for RPC, and probably was never meant to serve as an RPC system. I’ve been using it like that because I didn’t realize what I was doing… but recently, while programming, I can see the friction and challenge in using AP for something it’s not suited for.

I don’t know if anyone else is feeling this friction. I imagine that if you’re working on an application in the social network domain (sharing pictures, videos, blog posts, etc.), you probably don’t need much custom message passing between actors. But if you’re working on an application involving collaborative editing of shared resources (in ForgeFed’s case, stuff like issues, PRs, repos, wikis, translations, kanbans, etc. etc.), you’ll probably notice the friction, even after you figure out an OCAP system.

But there’s probably one aspect of AP where I imagine most of you do feel friction: Choosing vocabulary for your custom/new features, and trying to get the rest of the Fediverse to agree together on the vocabulary. I’m not proposing to stop using AP; but if we decide to use it only for notifications/following, then all we need to agree on is the vocabulary of notifications, i.e. activities that already happened. Because requests for action will use an evolving API mechanism with clear exact typed arguments and return values.


Using an actor model based message passing system, with all the important essentials built-in, seems like a much, much saner path to me, than to continue to abuse AP as a distributed RPC mechanism for forge federation.

We already have the perfect system for this purpose, and I hope you’ve all heard of it: Spritely Goblins (website). It has OCAPs built in, and distributed garbage collection and promise pipelining etc. etc., allowing to program distributed federated apps in the same ease you write any other app.

BUT Spritely is very WIP. They’re still in the process of standardizing their network protocol. And the Goblins library is available only in the Guile and Racket programming languages.

So, in the meantime, I’d like to explore this new Activity+RPC idea by using another, very similar but slightly more mature RPC/actor system: Cap’n’Proto (website). It’s implemented in a few more programming languages, in particular including Go and Haskell, which should be enough for implementing it in Gitea and in the reference forge Vervis. It’s also possible that these two RPC/actor systems will interoperate at some point. But if not, we can switch to Spritely when the time comes.


Ask anything, say anything :slight_smile:

Including counter-arguments to this proposal. Including suggestions for other ways to do RPC. Including arguments in favor of using AP for RPC. Including requests to clarify what I mean by RPC. Including expressions of surprise that I ever tried using AP for RPC and didn’t realize it was never the point.

I want feedback very much ^ _ ^

Spritely has been around for some time now, bringing the next level of the Fediverse from dream to reality step by step. So I’m not really proposing anything new. I just want to start experimenting, and bringing practical forge federation as soon as I can. And any other federated domain/application with a similar situation.

For now I’m making progress with ForgeFed using purely ActivityPub, with ForgeFed’s custom OCAP system and with AP activities for invoking actor methods / requesting action. But I’m seeing it more and more as a temporary setup on the path to using a real distributed actor model system like Spritely.



I should ask… what is Spritely? I have heard of it, though I’m not really familiar with it at all. I feel like I should be.

It’s… the future RPC distributed programming aspect of the Fediverse :slight_smile:

I just read through that… sounds pretty awesome, though who knows if AP is going to stay the dominant protocol…

I think it is important to look beyond protocols, as they are implementation details. Look towards what opportunities they bring and what can be created with them.

True… but when deciding what to implement for a project, how do you take that advice into practice… if we have to look beyond protocols… then how do we know what to support?

I guess by first taking the jump on where you feel comfortable enough. And then monitor technology trends until you are ready to take further leaps into things. The AP landscape has mature, production-ready implementations. Lotsa challenges, but those are opportunities at the same time too.

So… maybe I should put my knowledge of programming somewhere else and not worry about inventing the wheel again with AP in DotNet.