I have deeply mixed feelings about #ActivityPub’s adoption of JSON-LD, as someone who’s spent way too long dealing with it while building #Fedify

submitted by

I have deeply mixed feelings about #ActivityPub’s adoption of JSON-LD, as someone who’s spent way too long dealing with it while building #Fedify.

Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone’s just pattern-matching against what Mastodon does, but it’s not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don’t exist for many languages. No safety net, no validation, just vibes and hoping you got the @context right. Naturally, mistakes creep in.

But then the other part of me thinks: well, we’re stuck with JSON-LD now. There’s no going back. So wouldn’t it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That’s what Fedify does.

Here’s the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it’s more likely to break when talking to implementations that produce malformed documents. From the end user’s perspective, Fedify looks like the fragile one. “Why can’t I follow this person?” Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.

To be fair, there are real practical reasons why most people don’t bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn’t trivial either. Fedify uses some tricks to keep things fast, and I’ll be honest, that code isn’t my proudest work.

Anyway, none of this is going anywhere. Just me grumbling into the void. If you’re building an ActivityPub implementation, maybe consider using a JSON-LD processor if one’s available for your language. And if you’re not going to, at least test your output against implementations that do.

#JSONLD #fedidev

27
3

Log in to comment

Hot Top New Old
edited

@hongminhee@hollo.social I’ll give you my take on this… which is that my understanding of JSON-LD is that with JSON-LD you can have two disparate apps using the same property, like thread, and avoid namespace collision because one is actually https://example.org/ns/thread and the other’s really https://foobar.com/ns/thread.

Great.

I posit that this is a premature optimization, and one that fails because of inadequate adoption. There are likely documented cases of implementations using the same property, and those concern the actual ActivityStreams vocabulary, and the solution to that is to communicate and work together so that you don’t step on each others’ toes.

I personally feel that it is a technical solution to a problem that can be completely handled by simply talking to one another… but we’re coders, we’re famously anti-social yes? mmmmm…

 reply
5

Deleted by author

 reply
2

@mat@friendica.exon.name that’s a really interesting point of view, and has some parallels to how app development on the ATProto side is easier in many ways.

I do think that this is something C2S (aka the ActivityPub API) can enable.

I am critical of JSON-LD but I do certainly recognize I could be very wrong 😁

 reply
3

Deleted by author

 reply
1
they/them

@mat @julian there are many atmosphere apps now that support a ton of totally different lexicons at once

 reply
1

@julian @mat

Do you know about the backgrounds of the immers project ?
, "no-one's actually using AP to play chess"
the reason that we have noa AP chess service _anymore_ is #uspol …

This all feels very unfair somehow cause I know the backgrounds but anyway …
While we 2 days ago had a long thread about our use of Chess Games I will link the video from the thread digitalcourage.social/@sl007/1

immers with its federated locations and positional audio etc was supernice for playing chess !
Our use is fairly similar and straightforward like we did the chess Social CG meeting in 2018 and the rc3 (usually 18.000 people physically but here it was virtually cause pandemics) socialhub.activitypub.rocks/t/

Maybe it would really be fair if people are new to look into the 20 years Social CG history where some volunteers really gave much work :)
🧵 1/2

 reply
1

@julian @mat

We implemented this standard and you can create / describe your rooms [Place, `redaktor:fictional`] and the chessboard is just a geohash as described in the geosocial CG so the use is the same, just `redaktor:fictional` too,
You load the Collection of Chessfigures (pawn1 ...) can name them, they `Travel` over the chessboard ant the `Arrive` describes the `result`.
As always you can get very detailed with wikidata properties and entities but bare AS Vocabulary is enough.
In the end you have a Collection for the Travels which is your played game which you can replay or do whatever with.

But you can still install immers - it is worth a try github.com/immers-space

The reason for its end are the same as for the gup.pe groups and I hope people konw about it …

 reply
1

Deleted by author

 reply
1

@mat
Just btw, this is 7 years old reddit.com/r/chess/comments/94 but anyway

However, given that I have, including immers and redaktor, at least 3 apps where I can use the first chess spec.:
if more than 2 implementations will also support this second chess specification, I will do so too.

@julian

 reply
1

@mat Has a reason, just wrote it to @julian in a DM, just didn't want to post public.

Not sure if you visited the link. This _was_ the community approval …
Immers was famous and we had some official Social CG meetings where I linked one where thousands of community people attended (?)
The W3C Social CG _is_ the Community (?)
Meanwhile even Public Spaces Incubator uses it which is to my best knowledge the largest upcoming iimplementor by far.
I mean apart from that it is pretty obvious after the meeting where we talked about "factual" vs "fictional".
mastodon has nothing to do with this. The majority of projects count in a democracy. We had a demo playing chess between 4 softwares.

Doing the official AP Conf and becoming elected Policy Lead, I had always asked the community. For 20 years :(
conf.tube/c/apconf_channel/vid

Not sure if anyone did read the "Conformance Section" of ActivityPub. w3.org/TR/activitypub/#conform
It is section 2 - You have to support "The Entirety"...
If mastodon does not it is not ActivityPub.

 reply
1

@julian I don't think it's premature optimization, but an artefact of ActivityPub being built on top of the Activity Streams vocabulary, which predates it by some time.

@hongminhee

 reply
2

@julian

Manu, maker of JSON-LD who also helped with the AP Confs, made this nice video youtube.com/watch?v=vioCbTo3C-4

JSON-LD is a normative reference to ActivityPub. The context of AP is only 1 line, maybe 4 if you support the official extensions. It does not make anything much larger.

It is for example important if you want to consume the federated wikipedia, wikidata, European Broadcasting Union or these Public Broadcasters publicmediaalliance.org/public but also to know that e.g. mobilizon uses schema.org for addresses.

I give you an example, if you include
"mz": "joinmobilizon.org/ns#", "wd": "wikidata.org/wiki/Special:Enti",
"wdt": "wikidata.org/prop/direct/"

in your context, then you know about mobilizon extension but also the whole common knowledge of the world …
I like that, now you can support the whole vocabulary of wikipedia and wikidata which is just JSON-LD.
You get it in all the languages of the world including the properties name.
No problem, if others don't support it, but sad for users.

@hongminhee

 reply
1

@julian @hongminhee

PS, I am using the official JSON-LD processor of Manu and contributors, if support in any language is lacking, we just speak to the JSON-LD Group (glad about the 2 webintents coming together now as well ) …
Cause we are social …

 reply
1
he/him

JSON-LD is a trap. Sorry you fell in.

 reply
2

> @hongminhee@hollo.social said in I have deeply mixed feelings about #ActivityPub’s adoption of JSON-LD, as someone who’s spent way too long dealing with it while building #Fedify.: > > Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.

This asymmetry of blame and credit is a real problem in distributed systems generally, as much economically as emotionally. The system doesn’t actually scale to multiple disjoint platforms and orthogonal ecosystems without someone doing the hard work of open-world translation… if everyone hardcodes their preferred JSON shape it quickly becomes a zero-sum game and small players have to do much more work than big players. This has consistently been a challenge for public-benefit funders, who try funding load-bearing infrastructure like fedify to avoid those dynamics, but that often demands funding bigger teams on longer horizons than they are set up to fund by their structure.

 reply
1

@rimu@piefed.social we if it’s a trap we’re all in it because ActivityPub is a JSON-LD serialization fullstop, if the collective action problem results in a majority of projects wanting to abandon that and hardcode to a closed-world JSON model just fork the protocol and call it something else.

 reply
1
she/her

@hongminhee How hard would it be for a future version of ActivityPub to simply back out JSON-LD support? Would there be a downside to this?

 reply
2

@mcc@mastodon.social asking the important questions 🤣

@hongminhee@hollo.social

 reply
2

@julian @mcc @hongminhee the downside is that you now need a central registry of allowed terms and what they mean.

the way to avoid that is to always use "expanded" form, i.e. use full IRIs as property keys (and types) and {"id": "foo"} over "foo". in effect, you treat the http(s) authority as the social entity defining the term.

 reply
1
OP

@mcc@mastodon.social I’m not sure, but that would break some ActivityPub implementations relying on JSON-LD processors. 🤔

 reply
1

@hongminhee what i have found necessary (sadly) is to sometimes ignore what @\context a software produces and simply inject a corrected @\context describing what they *actually* meant instead of what they said they meant. x_x

gist.github.com/trwnh/d2f6fb1c

it would be an Exercise to sit down and map out the actual contexts of softwares like mastodon 4.5, mastodon 4.4, misskey 2025.12, akkoma 3.10.2, and so on...

for all else, there's shacl i guess, if you want to beat things into the correct shapes.

 reply
1

@trwnh@mastodon.social it’s not an exercise, not anymore, with the Fediverse Observatory!

 reply
1

@hongminhee

Great piece of writing, and I agree with lots of what you say here. Building this stuff is super hard, so good for you doing it “the right way.”

I hate not being able to trust the data I receive.

I’m one of those who’s taking the shortcuts, which has plenty of drawbacks, so I’m glad you’re in here fighting the good fight.

 reply
1

@benpate reminder that you can have a trusty library that fulfills more or less the same functionality of fedify any time you want to switch. ;;)

@hongminhee

 reply
2

@hongminhee do you use the activitystrea.ms module from npm? It takes a lot of the pain out.

 reply
1
OP

@evan@cosocial.ca I don’t remember exactly, but I think I came across it while doing research before developing Fedify. I probably didn’t use it because the TypeScript type definitions were missing. In the end, I ended up making something similar in Fedify anyway.

 reply
1

@hongminhee i struggling badly with rust cuz it's rust being rust... i can imagine a duck typing lang might have easier time

 reply
1

@hongminhee most of the time, i cant compile if really do jsonld as it is. unless i box everything onto the heap. but then it became a de-optimization point to the rest of the software

 reply
1
Insert image