First good night’s sleep ive had in weeks. I suddenly woke up and realized all the items that need fixing in AP, and for the most part, how to fix them. I need to write this up before I forget. I came to a conclusion that it’s going to be really hard to fix AP in the 1.x branch, especially within the current process. This conversation yesterday between Tim Berners-Lee and Sarven (Linked data notifications) about the new w3c notifications system solidified it for me:
We are going to need an Activity Pub 2.0 which fixes the major pain points in the eco system. It must be backward compatible with 1.x, but will introduce new, more scalable, extensible, interoperable ways of doing things for a larger federation and ecosystem. Systems using 1.x can signal it, and those using 2.0 should accept 1.x activities. Those using 2.x can run an upgraded protocol, and when signaling has reached a certain threshold, the old 1.x API can be sunset.
I think the first task on this track is to broadly outline the high level areas that need an upgrade, before drilling into the details. Split AP into its logical functions e.g. identity, payload, discovery, serializations (including parsing), namespacing, ontologies, authentication, signatures, c2s/s2s, large media types, version signalling, extensibility, authorization etc.
Different people will want to work on different things, so maybe the first step is to poll people to see what they want, what are the pain points, and then propose a new spec that gets most of it in.
For me the biggest blocker is ActivityStreams. I’m still forming thoughts on what is wrong with it. One of the main patterns is: It doesn’t have the Client / Server split ActivityPub does.
The other is: It’s probably not the choice of design pattern I would use. I have the impression that it aims at doing a lot of stuff through inheritance, when composition would be better. These are words from object oriented programming and not linked data. I hope it still gets the idea across.
The main advantage of composition would be, I get to use other vocabularies, without any integration work.
I don’t think this belongs into ActivityPub. ActivityPub (with a few exceptions) specifies how Actors interact with each other. It defines the side effects necessary to allow for basic social interactions.
One can take this step further [1] and claim that ActivityPub does not specify how a Server (something not defined in ActivityPub) should deliver messages. It just specifies that the messages arrive at the receiving Actor’s inbox. Then the road is open to specify server to server protocols.
One of these protocols could be the sharedInbox.
One of these protocols might be batch messages and send them after 32 seconds or when you have 64 messages.
However, these are then all details independent of ActivityPub. One should probably rename the spec to ActivityActor afterwards … this would clearer what it does.
AS does have sub classing, which is inheritance, the “is-a” concept in OO Programing. This comes from OWL, largely.
Composition is also part of AS and linked data, the “has-a” concept, which you can see in regular JSON.
So AS can have both, although the current implementation is somewhat convoluted to the point of being broken. Basically the main problem is that the hyperlinks point to the wrong places. That can be fixed, but then old and new locations of the hyperlinks will need to be supported for a while.
What part of inheritance vs composition do you think is a limiting factor. I’d like to hear, even if it’s just a gut feeling. What could be improved, or what cant be done now, that could be done in a different way.
Using other vocabularies without integration work, was part of the design of the spec, and linked data in general. You can put terms inline or in a context. Other vocabs etc. The only issue I see is when two different contexts contain the same term, especially if they are @protected, then typically the expansion will throw an error. This is exactly a point of centralization that we need to avoid, and was what lead me to write this out.
I think @aschrijver originally raised the question on how to define custom Activities, when I claimed that it’s probably best to use the CRUD operations (Create, Update, Delete Activities). I would like to have an architecture, where I can define new Activities without making it necessary to modify servers. My gut feeling is that composable Activities make this much easier than the inheritance model.
The important thought is that right now “ActivityPub et al is a Framework” and not a comprehensive spec where you can say to someone: “Here’s the spec to implement AP and let’s interoperate”.
Dennis wrote:
What I got was the exact opposite, and in a way that I found quite shocking, to be completely honest. Several folks who worked on ActivityPub, ActivityStreams, and other more or less related specifications reached out to me and told me they agree with pretty much everything I wrote. In general, people familiar with specifications and interoperability agreed that ActivityPub is less a specification for an actual protocol, but more a framework, which opens options for further dialects to be worked out, and specified on their own. Some implementors agreed with this statement, saying it is quite painful to implement these specs because there is no “source of truth” to work from. […]
The tamest reaction out of all was an article published by an organization [Feneas, now defunct] that claims to “spread knowledge about federated web projects and help people and projects involved in this area”, where one implementor took the time to take all my points and explain how you can work around those. The overall resentment of this reply was “you can implement ActivityPub just fine, you just have to talk to every single other implementation to make sure you are compatible”
That reference to AP being a framework is touche on in a previous article by Dennis Schubert where he explains What ActivityPub is.
And a last point to mention is that, when extension mechanism is clearly defined and intricate part of the specification itself, one might discover extensions on the fly… anyone can create extensions, anyone can discover them and integrate with them. I was hinting at that in my best-practices post (top link), but it was nicely described by @cjs in yet another old article An ActivityPub Philosophy:
"Why not build on top of ActivityPub to solve both of these problems?
First, we as a community create an ActivityStreams extension and define behaviors to document the specifications built on top of ActivityPub. We now have a way to store ActivityPub extension specifications in the Fediverse itself. Next, building an application server that understands this extension and can federate it over ActivityPub means anyone can simply host an instance, allow users to register, build its community, and be free to draft new specifications on top of ActivityPub. Since this data is then federated by ActivityPub itself, it is reachable by both technical and non-technical users. There is neither a central authority nor a central registry as each community is responsible for its own ActivityPub specifications. This is the democratization of ActivityPub across all domains. People cannot have their ActivityPub extension specification censored. As long as the core ActivityPub protocol as currently written is followed, federation compatibility naturally leads to new domains and apps implementing them."
I feel that if an ActivityPub 2.0 would bring back those clear distinctions of transport protocol, social data syntax and extensibility mechanism (linked data based), then v2.0 might constitute a significant simplification.
@melvincarvalho could you please summarize what you think should be changed in ActivityPub 2.0? Especially it would be interesting to see whether some of these changes could be implemented as #standards:fep, and clarify exactly why a version 2 would be required.
There’s quite a few things, but the main one I think is the data model.
My feeling in the WG was that they wanted the extensibility benefits of Linked Data, without the overhead, and to make JSON first class, and Linked Data opt-in.
That was sort of achieved, but perhaps in a hacky or confusing way. So the overhead of linked data is there, but without much of the benefits.
What could be good, and maybe some of this is true already, would be to make JSON first class and an easy path for new developers. The linked data parts consistent with existing standards, and more like an opt in. The context and vocabs at the right URLs. Maybe remove confusing content negotiation where possible, too.
Make extensibility easy and intuitive. Have clean separations of domain knowledge with examples.
Sort out what happens when two different teams define the same term. For example “Group”, how do you deal with that being:
in FOAF vocab
in vcard vocab
a regular JSON string
What happens now is that you go to the context, and look for @protected terms. And if two terms are protected you throw an error.
This is the main thing. Other things to look at are identity. For example did you know that in webfinger a better way would have been .well-known/webfinger?acct=user@host but we’re stuck with the acct: uri scheme now. Fix or upgrade the signature stuff if needed. An upgrade and versioning mechanism so that software can know what versions of stuff others are running etc. And whatever there’s appetite for.
Strongly disagree, in fact I would encourage exactly the opposite. By keeping json-ld, one can rely on an existing framework that takes care of a lot of the problems that arise from data the refers to other data, i.e. linked data, and how to define extensions.
It is of course easier to start something without having the complexities coming with learning json-ld. However, you will have to solve all the problems solved by json-ld that lead to these complexities later on.
Good data point, thanks. However, were you aware that AP already accepts regular JSON today? It’s just that it expands it to an obscure blank node syntax, which I think could do with some improvement.
JSON objects are JSON-LD because of the @vocab directive
You could say they are lower quality JSON-LD, that would be true
The question of whether every object should have a type, it’s normal for every JSON-LD object to have a type. But I dont know what the current practices are. Sometimes types are inferred.
I will add my 2cts to the discussion and refer back to the title of this topic: Towards ActivityPub 2.0
If one thing stands out to me in ALL the many discussions that occur all over the place in different settings and channels, then it is this:
Technology vision
The discussion is all over the place, utterly chaotic, lacking direction and focus. Technical insights, implementation details, app-specific use cases, pros/cons of other technologies. Big lists of things to add to AP specs. It is all fine and great to behold. But it is also utter chaos.
What is the Social Web and where does ActivityPub fit exactly?
How is ActivityPub positioned?
What needs should be addressed?
What can I do with the technology?
What shouldn’t I use it for?
Where does it fit in the larger technology landscape?
What is the level of ambition?
What promise to the future does AP hold?
Only by answering these kinds of question can there be a scope.
Only with a good scope can there be decomposition into constituent parts.
Only with proper decomposition can the technology become accessible.
Only when the technology becomes accessible will it become more attractive for broad adoption.
One thing is clear to me. And that is that the current Fediverse / AS / AP et al constitutes a loose framework with vague contours of an exciting paradigm for "The Decentralized Web. Where the only possible way for the ecosystem to grow is by ad-hoc, on-the-fly interoperability that naturally leads to incompatibilities, and explosion of different flavours to support, i.e. with assured protocol decay.
These are great questions. I think that new information warrants a new approach to this. Let me outline my thought process.
Meta have entered the ActivityPub space, with 70 million users in their first few days. It is likely that they will have in the hundreds of millions of users. So, they will at this point make up around 99% of the fediverse user base.
It stands to reason that with so many users and stake holders, there will be new needs. Optimizations, bug fixing, new features, small changes, and so on. Given a company the size of Meta they are likely to want to deal with an established entity. They have already said in their blog post, they will be working with “ActivityPub” and the W3C. See:
The way the W3C tends to work is that a new version of a spec needs to have a charter first, and then a working group. The whole process takes 2-3 years, sometimes longer, and the output will be ActivityPub 2.0. The charter itself decides what the deliverable are, and that can take as little as 6 months.
So perhaps it will be an idea to start working on a charter and try to include the things that we want to be in the next version, e.g. which FEPs, nomadic identity, other items.
Despite the speculative nature of this line of thought, an early start maximizes the likelihood that our desired elements will be included in the next version.
So I suggest figuring out which features we’d like to go into the next version of AP, and outlining them in a charter like document.
I don’t think ActivityPub 2.0 is a good idea. ActivityPub covers too many conceptual layers. It should be split into several specifications doing things on one conceptual layer.
That’s exactly my problem. I don’t believe the deliverables ActivityPub 2.0 and ActivityStreams 3.0 will lead to a better Fediverse. The likelihood of digging in on bad stuff in the specifications is too great.
I would use “Evolution of the ActivityPub / ActivityStreams specifications” instead.
You mean like a living standard? That would need to be proposed.
Im not commenting on whether it will be better or worse. I’m saying to normal way of w3c working, is to do a charter, then to create a specification which gets voted to be the new REC.
My limited experience with W3C charters is that WGs define a scope and specs they will DEFINITELY or POTENTIALLY complete within their scoping period-- the order is allowed to change, and specs can be worked on in parallel or in sequence if they’re downstream of one another. I like Helge’s idea to specify a few features and layers ABOVE the data model, maybe harden some FEPs into core features at those layers, and THEN return to core model after there’s more interop with today’s core model…