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”.
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.
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:
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.
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.
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…
To add to what @by_caballero said, though from an IETF perspective, it is not unusual for IETF to split “a specification” into a bunch of different documents, which include the following topics and may even have one document per topic:
Problem statement: this is why we’re doing this.
Use cases: current and envisioned use cases.
Gap analysis/requirements: derived from use cases, what does AP currently offer or not offer.
Architecture: with this high-level approach we think we can meet the requirements.
Core specs: the main specifications, which reference the above.
Extension specs: any additional things that aren’t really part of the core.
I have Thoughts ™ on how many core specs are necessary, but that’s not the main point. The main point is that a WG charter can easily encompass writing a single doc on each those points, with the last two most likely warranting several docs each.
That also means that the WG charter can be written so that these topics are covered.
(W3C works a bit differently and I have less experience there, so YMMV on the above. It’s more the topic-based approach that I’m advocating for here.)