(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 Christine Lemmer Webber, the primary author of the ActivityPub specification. This work centers around Spritely and Goblins, 2 projects of Christine’s (see: spritely · GitLab).
(Spritely concept art someone created using Krita. See this toot)
The ideas Christine 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
Christine’s work on Spritely mostly went ‘under the radar’, so I asked them 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:
- “sufficiently unguessable” ocap URIs (ocap literature: “sturdyRefs”)
- ocap certificates (eg zcap-ld)
- live references (requires CapTP, which I am working on)
- and ok also technically ocap powered storage (datashards)
and 4) are the easiest tie-ins to present infrastructure, but…
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.
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)
Now…
Cory Slep, developer of go-fed triggered a discussion about Ocap - the object capabilities spec that Christine is working on. The reason for this post is this: As of September this year Christine 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 Christine. In the discussion thread they started to explain the complex stuff they are 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 Christine 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 Time travel debugging in Spritely Goblins, previewed through Terminal Phase -- DustyCloud Brainstorms
- 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 EC Habitats Beta - Avatars 97 Exhibit - YouTube
I talked about this in my apconf talk last year: “ActivityPub: past, present, future” - Keynote by Christine Lemmer Webber
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): Goblins: a transactional, distributed actor model environment
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
- Spritely succeeds and is ActivityPub interoperable. Horray, everyone wins!
- 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.
- 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
