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
Background
Lately, in my work on ForgeFed, I noticed I’m using ActivityPub for 2 things:
- Social, i.e. actors can follow other actors and get notified about their activities, and actors can comment on stuff that other actors publish
- 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.
Proposal
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.
Questions
Ask anything, say anything 
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.
Thoughts?