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

@hongminhee thank you for doing hard work with the plumbing! You are helping build coherence in this place and I'm grateful for it. Diverse people, unified standards 🖤

JSON-LD 를 제대로 다루는 라이브러리를 하나 만들어 보시면 어떨까요

@hongminhee@hollo.social boosting this for the excellent points, even though I'm one of the people not using JSON-LD and frequently producing malformed documents.

(And honestly, I don't think I'll change that soon. Sharkey only uses JSON-LD on one single code path, and even that's been enough to introduce critical bugs. I'm planning to remove the JSON-LD lib entirely from Campfire fork.)

((And that's not even getting into the security problems with every JSON-LD lib I've ever audited...))

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

@hongminhee Not into the void. I don't know shit about JSON or programming, but I did read your post! :-)

@hongminhee

>There's no going back.

We absolutely must go back. Either we have a vibrant ecosystem where building stuff is a pleasant experience, or fediverse slowly dies while linked data cultists harass developers about nonresolvable URLs in @context.

JSON-LD adds nothing to ActivityPub, it only creates problems. Time to move on.

@hongminhee - boosting as I think this is an interesting discussion to have. I'm working on some ActivityPub adjacent ideas which use semantic web concepts, but I'm not deep enough in yet to have strong feelings about the right standards to use in different places.