ActivityPub Won by Being Boring
27 points by boramalper
27 points by boramalper
The JSON-LD part of AP is far from boring and is actually fairly madness-inducing. Edit: See https://lobste.rs/s/1g5bum/why_implementing_activitypub_is_hard_why
Yeah the article says "boring is implementable" but implementing an activitypub server is ridiculously hard, in big part due to json-ld. Second hard thing being auth.
Also (I don't know if this is actually the same thing or not) the fact that any property can be a single thing, an array of things, or a link to a collection of things.
Software should treat a JSON-LD object as an RDF graph and JSON-LD as an RDF serialization format. Ignoring RDF is a recipe for sadness.
It is not though.
The extensibility of the JSON-LD vocabulary has very little impact on UX and UI. Generally, applications know, or at least assume, the shape of the data they work with in order to be able to present it to their users. So new introduced vocabulary will most likely be filtered out from what the users get to experience, or at best it will be converted to a shape recognizable by the application (it has a Name, it has Content, it maybe has a URL).
Being able to interpret an RDF graph brings absolutely nothing to the table, and it'll also be very slow.
But it's boring in the fact that most implementations don't need to bother with the extensibility that JSON-LD brings. Supporting the vanilla Activity Vocabulary objects as plain JSON is enough for most applications, and that's what usually happens in the ecosystem.
But that's why we're working on trying to make it easier for devs to work with ActivityPub.
Say more?
The latest article about the topic is by the Fedify guy: https://hackers.pub/@fedify/2026/why-activitypub-is-hard
ActivyPub "won" (insofar as it did...) By being used by Mastodon. That's it. Mastodon was popular, adopted the protocol, now the protocol is common.
I don't know if this is a fair characterisation. Yes, I think Mastodon was a huge driver of its adoption but then other sizeable projects such as Lemmy, PieFed, and Mbin (as reddit alternatives), and Pixelfed (Instagram) were able to use ActivityPub successfully too, which shows that the protocol is quite versatile.
This is why ActivityPub spread. JSON-ish objects, HTTP GET, HTTP POST, URLs, collections, actors, inboxes, outboxes. None of this is dazzling. Boring is implementable.
And yet, these are so much more complicated, so much more wasteful, than a bespoke binary protocol would have been. OK, maybe keep the URLs since those are human facing, but the rest has no business being textual.
The real criterion here is familiarity and leveraging existing implementations, not actual implementability. Typical network effect.
Hmm. I think ActivityPub mostly succeeded where it has by being implemented in a lot of software that could easily be self-hosted, notably Mastodon and Pleroma (at first), which created a network effect.
Implementing ActivityPub is pretty annoying, actually.
Nobody can fix that by saying “the spec says” loudly at a server log.
They can, actually, if they’re big enough to throw their weight around. Unfortunately it normally works the other way around, that weight-throwing makes things worse rather than better, and everyone else gets bullied into adding quirks for the big provider. I hear this has happened with ActivityPub in a few areas.
Gmail starts requiring SPF, DKIM, DMARC, whatever, years after almost everyone supports it? The remaining holdouts finally begrudgingly implement it.
It does not give it end-to-end encryption.
Is this seriously calling a lack of end-to-end encryption technical debt!?
Too often, end-to-end encryption is spoken of as a fundamental good. It really isn’t: it has severe trade-offs that make it frankly a bad idea in most areas. General-purpose one-to-one and few-to-few communications is one of the few areas where it’s more likely to be worthwhile, but it’s still not obviously worthwhile.
(In light of the other recent story here—no, lack of E2EE is not mess either.)
Personally I don't understand why people want to retrofit E2EE into ActivityPub. There are already working implementations out there that were designed from the ground up for it. I think ActivityPub should remain a low stakes social media protocol, where it's safe to post pictures of cats and comment on them, not your life and death political dissident communication.
Any competent Web engineer from the mid-2010s could look at ActivityPub and think, yes, this is roughly how I would have done it.
I find this a curious claim, given that its architecture is the exact opposite of RSS syndication.
RSS has the advantage of being really, really simple. (RSS 2.0 and Atom specifically. And yeah, you need to implement both, including error recovery for XML parsing, plus HTML tag encoding detection for RSS 2.0. But it's still simple.)
ActivityPub is not quite so simple. And outside of Mastodon, it's still pretty niche, as far as I can tell?
also a valid reaction may be 'omg, a reinvented wheel, inside out.'
Irony is, activitystream 1.0 started on top of atom/rfc4287 and only 2.0 got taken over by json zealots.
it's too soon to call it a win. And all the useless complexity for flexibility nobody can rely on isn't boring but embarrassing. It's a standard that refuses to be relied on and so isn't. It' just the big implementor(s) dictating.
But as a marketing term it sparked momentum.