Fediverse and Object Capabilities (Ocap)

(Note: I copied this from another forum, because I think the topic is very important for the future of Fedi, and in hopes it saves someone the work of collecting the info)

IMHO one of the most exciting developments regarding the Fediverse is the work that is done by Christopher Lemmer Webber, the primary author of the ActivityPub specification. This work centers around Spritely and Goblins, 2 projects of Chris (see: https://gitlab.com/spritely).

(Spritely concept art someone created using Krita. See this toot)

The ideas Chris is working on are inspired by multi-player online games and centered around the idea of Object Capabilities. Object capabilities are an alternative to Access Control Lists (ACL’s) for authorization and can be compared to a valet key for a car (the object). The valet key gives anyone you give it to some capabilities (to park the car) while forbidding others (to drive long distances, steal the car). Here’s that example’s explanation.

Before I continue, first a problem that exists in today’s Fediverse.

Fediverse: Compatibility and interoperability problem

The ActivityPub spec on which Fedi is based was intentionally published with many holes (authentication/authorization, finding users) and flexility points (extension mechanism), so that people could build projects and learn from experience. But this has led to:

  • The leading fediverse applications filling in the blanks in non-standard compliant ways.
  • Most notably Mastodon setting the trend and using the Mastodon API instead of Client-to-Server (C2S) interface.
  • Mastodon and Pleroma inventing additional properties in ActivityPub message types.

Result is that if you want to be fully fediverse compliant, you have to adopt Mastodon-specific ways of doing things. Back to object capabilities.

Fediverse: Object capabilities

Christopher’s work on Spritely mostly went ‘under the radar’, so I asked him about the specifications he was focusing on. Here’s his answer I got:

zcap-ld is one way to implement ocaps. Is it the right one for the fediverse?

There are really three viable paths for a fully rich federated social network:

  1. “sufficiently unguessable” ocap URIs (ocap literature: “sturdyRefs”)
  2. ocap certificates (eg zcap-ld)
  3. live references (requires CapTP, which I am working on)
  4. and ok also technically ocap powered storage (datashards)
  1. and 4) are the easiest tie-ins to present infrastructure, but…

  2. is going to be desirable if you have a lot of, er, “fast and furious short lived ocaps”, as a virtual world would need. That’s probably not necessary or within the scopes of most others right now.

  3. is nice, and I’m a big enthusiast of zcap-ld, but it’s kind of a jump in tooling vs the amount of payoff available for most implementors right now (whereas 3 is a big jump in payof while also being an increase in tooling)

I’m not really answering your question clearly, so basically: I think bearcaps + datashards (or something like either) for networked ocaps and storage are the fastest path to global fediverse adoption of ocaps.

(But for the virtual world stuff I’m working on, we’ll need CapTP too… but I’m not expecting most fediverse developers to take interest in that yet.)

(See also this discussion on Solid forum)


Cory Slep, developer of go-fed triggered a discussion about Ocap - the object capabilities spec that Christopher is working on. The reason for this post is this: As of September this year Christoper thinks he needs one more year of research before he can launch Ocap publicly. He also thinks that this may be too late for it to become adopted, as many people will have made their own implementation choices, like Mastodon, and unwilling to change. It would create a fork in the Fediverse!

Cory wrote:

It might take a year or so, but a direction of some devs on the #Fediverse around #ActivityPub is to make software that is fundamentally OCAP based. A big question will be: will there then be software that ignores it and effectively creates two fediverses? Or will existing software attempt to try to be a Swiss-Army-Knife implement-it-all? Or just migrate completely over?

I have no answers but it’s an uncomfortable question on the horizon.

That should be avoided if possible. I mentioned the risk of staying under the radar for another year to Christoper. In the discussion thread he started to explain the complex stuff he’s working on.

And here comes the gist: Ocap for the Fediverse looks to be really, really exciting!

Spritely and Fediverse: Object capabilities

Copying from the ongoing discussion here’s how Christopher describes his work (knitting the thread together):

So let’s try in bullet form. What is Spritely Goblins?

  • a distributed programming environment that’s safe to use even when you don’t fully trust the network.
  • ocap security is baked in, is just part of normal programming.
  • It follows the “classic actor model”; kinda like Erlang but more correctly
  • it even has such wild features as distributed garbage collection
  • it is meant as the foundational layer for writing Spritely programs
  • The distributed programming stuff already works in the captp branch, but needs to be documented to be exposed for public use (in the next release within the next month)
  • It has transactionality and “time travel debugging” built in, hence how Terminal Phase had trivial time travel (no more code than exposing it in the UI https://dustycloud.org/blog/goblins-time-travel-micropreview/
  • Its design means you can implement a distributed currency system in fifty lines of code or less and a toy authenticated chat system in 250 lines of code. Both of these have been written but I haven’t talked about them much yet. Yes, this means we could use this to bring payments to the fediverse.
  • ActivityPub interop is planned as an easy-to-use shim library.

I have implemented that design on top of Racket/Scheme. The core ideas are portable.

E came out of a distributed virtual worlds game that unfortunately died in the late 90s crash but was very interesting called Electric Communities Habitat https://www.youtube.com/watch?v=KNiePoNiyvE

I talked about this in my apconf talk last year: "ActivityPub: past, present, future" - Keynote by Christopher Lemmer Webber #apconf - ConfTube

So Spritely Goblins is not the distributed social system. A different Spritely project will be that system. But I have already written a few little demos, they work fine/great.

But because of Goblins, Spritely will be able to do things that seem absurdly, impossibly complex for contemporary fediverse applications like distributed virtual worlds. It’s designed to make that kind of thing easy. And it is, because it was based on an architecture built for that

The important thing is not distributed virtual worlds on its own (but who doesn’t crave a fediverse FOSS replacement for Animal Crossing right now?)

The important thing is that if you have something robust enough to make building virtual worlds easy, everything else is easy too.

But I probably sound like I’m full of bullshit. All I can ask is that you be patient and believe that I might not be. Or actually you don’t fully have to be, you can start learning now by reading the docs (which exist): https://docs.racket-lang.org/goblins/index.html

I don’t want Spritely to be vaporware, that’s why I’m taking the demo-oriented approach. Terminal Phase was the demo of how the basic programming system worked (pre-distributed). The next major demo will show off a distributed system.

I am inventing almost no new concepts. The core ideas are almost all taken from 25 year old technology.

The situtation for ocaps vs ACLs/origin-oriented programming is similar to the situation with functional programming: the ideas that are becoming popular today are mostly not new but were extremely obscure until enough people had reason (or interest) to explore them.

Anyway the outcome of all this will be one of three things

  1. Spritely succeeds and is ActivityPub interoperable. Horray, everyone wins!
  2. Spritely succeeds but the rest of the ActivityPub community won’t adopt and grow. I’ll be in the unfortunate state of abandoning the ActivityPub shim then and that means something resembling a fediverse fork which I DON’T want. But I won’t abandon this direction.
  3. I die from stress trying to make it happen

I should clarify on 1). I don’t expect everyone has to adopt Goblins for 1) to succeed. I don’t even expect everyone has to adopt something that looks like Goblins exactly.

I expect to extrapolate some ocap patterns generally that even django/rails users can use in their applications.

AND, such applications should be able to use stuff that spritely-based servers provide (such as the distributed payments and etc stuff) even if they can’t implement it themselves


Note: The discussion thread on all of this is crazily forked. I find different branches all of the time, so I encourage you to delve into it, as there are more valuable comments that I have missed in the above.

This feels so incredibly abstract (again). There’s a real-world problem I’m trying to figure out: how to know ahead of time what kinds of activities a given (S2S) inbox is capable of processing. That is, whether the software running on a remote server has the concept of a friend request, or whether it supports walls, or groups, or photo albums, and so on. This is required to make a UX that is convenient and frustration-free for everyone. There needs to be a robust capability negotiation mechanism. There also needs to be a way to specify privacy settings for active actions, so that e.g. only the users that can actually post on a wall see the form to do so.

Theoretical abstract concepts are nice, but I wish we talked more about the actual bits on the wire because that’s what everyone ultimately ends up dealing with.


Uhm, I gather you do not have gripe with my post in general, but with the information about ocap being unclear or maybe not addressing your needs. So I am happy I was able to bring it to your attention, and my work of collecting things from fleety fediverse exchanges into this hub was not for naught :slight_smile:

Since I am also not an expert on this complex stuff, I think it’s best to ping @cwebber with your concerns, and have discussion so his research is more likely to be embraced and adopted where that leads to most benefit for the Fediverse.

Sure, I understand what you mean, and would also like to see that. Make any topic you wish and lead the discussion. But IMHO informing all the various AP devs who frequent this forum about ongoing research elsewhere, however abstract that may be, is just as important and maybe even more so wrt the future of Fedi than going into nitty-gritty details. But both are surely needed and this forum has space enough.

@how, maybe we could have a tag called ‘research’ or something? Or a category maybe?

While loving some of the new infrastructure work (Goblin, et al), I don’t see people re-implementing existing ActivityPub applications.

I see three possible ActivityPub standardization directions:

  1. Evolution: codify existing conventions (HTTP signatures, …) and work to get existing implementations working toward a common point;
  2. Revolution-lite: rework standard with new solutions for what has been learned. Add solutions for signing, end-to-end encryption, proper sharedInbox, etc and then work with existing implementations to add those features toward a common interconnect;
  3. Revolution-big: design a new data/communication model and re-implement the world using the new capabilities.

Anyway, since I’m new to the ActivityPub milieu, I see several efforts going in different directions and don’t know where to start working on one standard. I would like to add a virtual world project to the mix and I lean more toward Revolution-lite.


In simplest possible terms, object capabilities are references. When OCaps come to be used with AP, AP will define the semantics of the operation to be performed and the token authorizing a capability will be an opaque reference to the code that the origin intends to execute on behalf of the caller. Opaque as in unguessable and irreversible, black box. When you get an OCap, you’re getting a function reference, and the code being referenced will run on the origin server when it’s called

And you can’t waste time worrying about the future. Just build your thing, get working federation with other instances, then collaborate and iterate in testing federation with other software. I suspect that the worst case of incompatible implementations is unlikely to become fully realized; the model being proposed is actually that good and I doubt that there’s the degree of bad faith in this community that would just dig in on maintaining the status quo

1 Like

For those interested to learn more about these and other exciting new Fediverse developments, see The Spritely Project.

1 Like