ActivityPub being treated as JSON is a good thing.
-
ActivityPub being treated as JSON is a good thing.
1/
Some of us are old enough to remember RSS and blogs.
Some of us are old enough to remember the absurd levels of hype that blogs and RSS attracted — similar to the modern AI hype and recent crypto hype. During that era, it felt like everyone any their pet cat wanted a blog with an RSS feed. During that era, there was a get-rich-quick fever around blogs and RSS.
Web-Browsers even added built-in support for RSS.
-
ActivityPub being treated as JSON is a good thing.
1/
Some of us are old enough to remember RSS and blogs.
Some of us are old enough to remember the absurd levels of hype that blogs and RSS attracted — similar to the modern AI hype and recent crypto hype. During that era, it felt like everyone any their pet cat wanted a blog with an RSS feed. During that era, there was a get-rich-quick fever around blogs and RSS.
Web-Browsers even added built-in support for RSS.
ActivityPub being treated as JSON is a good thing.
2/
There are different version of RSS.
Most people who know of RSS (if they even know it at all) know of RSS 2.0. But, it wasn't the only version of RSS.
(RSS isn't even the first technology of its kind.)
When the online developer community became aware of RSS, there was a fight between two version of RSS:
RSS 1.0 versus RSS 2.0
...
-
ActivityPub being treated as JSON is a good thing.
2/
There are different version of RSS.
Most people who know of RSS (if they even know it at all) know of RSS 2.0. But, it wasn't the only version of RSS.
(RSS isn't even the first technology of its kind.)
When the online developer community became aware of RSS, there was a fight between two version of RSS:
RSS 1.0 versus RSS 2.0
...
ActivityPub being treated as JSON is a good thing.
3/
It would be reasonable for anyone to assume that RSS 2.0 is a newer version of RSS 1.0. And there were many who tried to promote that view.
But, really they were completely different formats.
The "RSS" in 1.0 and 2.0 didn't even stand for the same thing.
1.0 RSS = RDF Site Summary / Rich Site Summary
2.0 RSS = Really Simple Syndication
...
-
ActivityPub being treated as JSON is a good thing.
3/
It would be reasonable for anyone to assume that RSS 2.0 is a newer version of RSS 1.0. And there were many who tried to promote that view.
But, really they were completely different formats.
The "RSS" in 1.0 and 2.0 didn't even stand for the same thing.
1.0 RSS = RDF Site Summary / Rich Site Summary
2.0 RSS = Really Simple Syndication
...
ActivityPub being treated as JSON is a good thing.
4/
RSS 2.0 won the RSS war.
I think the reason RSS 2.0 beat RSS 1.0 is because the RDF-based syntax of RSS 1.0 made it complex. It made it too complex.
While both RSS 1.0 and RSS 2.0 were XML-based, RSS 2.0 wasn't RDF-based. RSS 2.0's syntax was much similar and easier to understand.
I think that was a big reason why RSS 2.0 won — it had a better developer user-experience.
...
-
ActivityPub being treated as JSON is a good thing.
4/
RSS 2.0 won the RSS war.
I think the reason RSS 2.0 beat RSS 1.0 is because the RDF-based syntax of RSS 1.0 made it complex. It made it too complex.
While both RSS 1.0 and RSS 2.0 were XML-based, RSS 2.0 wasn't RDF-based. RSS 2.0's syntax was much similar and easier to understand.
I think that was a big reason why RSS 2.0 won — it had a better developer user-experience.
...
ActivityPub being treated as JSON is a good thing.
5/
JSON-LD has similar complexity to RDF. They are actually related formats.
ActivityPub uses JSON-LD, and thus has the potential for the same type of developer user-experience problems as RSS 1.0.
But I think ActivityPub is its own "RSS 2.0".
Why‽ Because people can and do treat ActivityPub as JSON (rather than JSON-LD).
That is a strength. It makes ActivityPub much simpler and easier to understand than JSON-LD.
-
ActivityPub being treated as JSON is a good thing.
5/
JSON-LD has similar complexity to RDF. They are actually related formats.
ActivityPub uses JSON-LD, and thus has the potential for the same type of developer user-experience problems as RSS 1.0.
But I think ActivityPub is its own "RSS 2.0".
Why‽ Because people can and do treat ActivityPub as JSON (rather than JSON-LD).
That is a strength. It makes ActivityPub much simpler and easier to understand than JSON-LD.
@reiver No. ActivityPub being treated as pure JSON is the reason why ActivityPub software is not interoperable and big players can rule over it through their market share. Understanding RDF to an extent necessary to handle ActivityPub correctly takes an hour, maybe, and we would not have the issues we have with Mastodon's proprietary fork of ActivityPub.
-
@reiver No. ActivityPub being treated as pure JSON is the reason why ActivityPub software is not interoperable and big players can rule over it through their market share. Understanding RDF to an extent necessary to handle ActivityPub correctly takes an hour, maybe, and we would not have the issues we have with Mastodon's proprietary fork of ActivityPub.
I'd say both of you are right, and neither are. The decision "Should it be JSON or JSON-LD?" is only part of the story. Both are but low-level data formats.
What needs more rigour is "How do I develop interoperable apps and services?", or even better "How do WE develop interoperable apps and services?" since interoperability means relying on others.
Fediverse currently evolves as a Big Ball of Mud anti-pattern due to the fact that post-facto interoperability - meaning "if you are first you can invent it on-the-fly" - is the dominant work method, and there is too little reconciliation of the tech debt and protocol decay that causes.
When misconceptions in ActivityPub aren't addressed, things will not improve.
JSON: Figure out in my app's codebase and perhaps docs what it means.
JSON-LD: You have ultra open standard flexibility, here see N specs on the magic of "linked data".
Both can't be just handwaved to as AS/AP extensibility mechanism.
-
@reiver No. ActivityPub being treated as pure JSON is the reason why ActivityPub software is not interoperable and big players can rule over it through their market share. Understanding RDF to an extent necessary to handle ActivityPub correctly takes an hour, maybe, and we would not have the issues we have with Mastodon's proprietary fork of ActivityPub.
I can confirm that. And it’s not just about Mastodon. The JSON part itself can be implemented fairly quickly, but the real challenges emerge from the variations—how different software packages keys, how WebFinger is interpreted or extended, and similar inconsistencies.
I have a lot of respect for @grunfink@comam.es. His approach is very direct: either the behavior is predictable, or the feature is rejected outright with a minimal response—just answering back {}. It’s a tough stance, but a coherent one, and I can appreciate the clarity behind it.
That said, drawing from my 30 years of experience as an architect, I’ve seen that these kinds of issues rarely disappear on their own. If they’re not addressed early, they tend to resurface later—often with significantly higher costs and complexity.
I’ve spent at least 15 years in the telco world, implementing listeners for protocols ranging from TLV-based ones like MAP to Logica’s UCP, or SMPP, EAIF, and even SOAP-based systems such as AAA over Diameter.
In all that time, the specification never left room for the question “how should I implement this?” If something is truly a protocol, that question simply shouldn’t arise.
So if the goal is to evolve ActivityPub, my view is straightforward: make it a protocol.I do not have to ASK how to implement, I MUST find it in the protocol.
-
I can confirm that. And it’s not just about Mastodon. The JSON part itself can be implemented fairly quickly, but the real challenges emerge from the variations—how different software packages keys, how WebFinger is interpreted or extended, and similar inconsistencies.
I have a lot of respect for @grunfink@comam.es. His approach is very direct: either the behavior is predictable, or the feature is rejected outright with a minimal response—just answering back {}. It’s a tough stance, but a coherent one, and I can appreciate the clarity behind it.
That said, drawing from my 30 years of experience as an architect, I’ve seen that these kinds of issues rarely disappear on their own. If they’re not addressed early, they tend to resurface later—often with significantly higher costs and complexity.
I’ve spent at least 15 years in the telco world, implementing listeners for protocols ranging from TLV-based ones like MAP to Logica’s UCP, or SMPP, EAIF, and even SOAP-based systems such as AAA over Diameter.
In all that time, the specification never left room for the question “how should I implement this?” If something is truly a protocol, that question simply shouldn’t arise.
So if the goal is to evolve ActivityPub, my view is straightforward: make it a protocol.I do not have to ASK how to implement, I MUST find it in the protocol.
💯 agree. This is also the gist of my post in the other branch.
Must. address. misconceptions. first.
-
I'd say both of you are right, and neither are. The decision "Should it be JSON or JSON-LD?" is only part of the story. Both are but low-level data formats.
What needs more rigour is "How do I develop interoperable apps and services?", or even better "How do WE develop interoperable apps and services?" since interoperability means relying on others.
Fediverse currently evolves as a Big Ball of Mud anti-pattern due to the fact that post-facto interoperability - meaning "if you are first you can invent it on-the-fly" - is the dominant work method, and there is too little reconciliation of the tech debt and protocol decay that causes.
When misconceptions in ActivityPub aren't addressed, things will not improve.
JSON: Figure out in my app's codebase and perhaps docs what it means.
JSON-LD: You have ultra open standard flexibility, here see N specs on the magic of "linked data".
Both can't be just handwaved to as AS/AP extensibility mechanism.
@smallcircles @nik @reiver JSON vs JSON-LD is a red herring tbh. The real question is, "do you recognize that other people might do things differently"? If you do, then you recognize that conflicts may arise, and you can try to resolve the conflict. But if you don't recognize even the *possibility* of a conflict, then it's painful for everyone involved.
Ciao! Sembra che tu sia interessato a questa conversazione, ma non hai ancora un account.
Stanco di dover scorrere gli stessi post a ogni visita? Quando registri un account, tornerai sempre esattamente dove eri rimasto e potrai scegliere di essere avvisato delle nuove risposte (tramite email o notifica push). Potrai anche salvare segnalibri e votare i post per mostrare il tuo apprezzamento agli altri membri della comunità.
Con il tuo contributo, questo post potrebbe essere ancora migliore 💗
Registrati Accedi