洪 民憙 (Hong Minhee) :nonbinary: @hongminhee@hollo.social
Public

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

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.

kopper :colon_three: @kopper@not-brain.d.on-t.work
Public
@hongminhee洪 民憙 (Hong Minhee) :nonbinary: from the point of view of someone who is "maintaining" a JSON-LD processing fedi software and has implemented their own JSON-LD processing library (which is, to my knowledge, the fastest in it's programming language), JSON-LD is pure overhead. there is nothing it allows for that can't be done with

1. making fields which take multiple values explicit
2. always using namespaces and letting HTTP compression take care of minimizing the transfer

without JSON-LD, fedi software could use zero-ish-copy deserialization for a majority of their objects (when strings aren't escaped) through tools like serde_json and Cow<str>, or System.Text.Json.JsonDocument. JSON-LD processing effectively mandates a JSON node DOM (in the algorithms standardized, you may be able to get rid of it with Clever Programming)

additionally, due to JSON-LD 1.1 features like @type:@json, you can not even fetch contexts ahead of time of running JSON DOM transformations, meaning all JSON-LD code has to be async (in the languages which has the concept), potentially losing out on significant optimizations that can't be done in coroutines due to various reasons (e.g. C# async methods can't have ref structs, Rust async functions usually require thread safety due to tokio's prevalence, even if they're ran in a single-threaded runtime)

this is after context processing introducing network dependency to the deserialization of data, wasting time and data on non-server cases (e.g. activitypub C2S). sure you can cache individual contexts, but then the context can change underneath you, desynchronizing your cached context and, in the worst case, opening you up to security vulnerabilities

json-ld is not my favorite part of this protocol
Summary card of repository iceshrimp/LinkedData.NET, described as: A work-in-progress C# JSON-LD implementation based on System.Text.Json

LinkedData.NET

A work-in-progress C# JSON-LD implementation based on System.Text.Json

iceshrimp.dev · Iceshrimp development

0
2
1

If you have a fediverse account, you can quote this note from your own instance. Search https://not-brain.d.on-t.work/notes/aihcsxrs45sw0wbq on your instance and quote it. (Note that quoting is not supported in Mastodon.)

kopper :colon_three: @kopper@not-brain.d.on-t.work
Public
i was a bit curious about the actual transfer size impact of json-ld, and what would happen if you replaced json-ld with simply explicitly repeating the namespaces. so i threw a few payloads, both compacted and expanded, into lynn.github.io/flateview/ at gzip level 6

my actor, compacted - 1855 bytes gzip'd
my actor, expanded - 1877 bytes gzip'd
my actor, compacted with no context - 1793 bytes gzip'd

quoted post, compacted - 2024 bytes gzip'd
quoted post, expanded - 2033 bytes gzip'd
quoted post, compacted with no context - 1985 bytes gzip'd

mastodon.social instance actor, compacted - 2761 bytes gzip'd
mastodon.social instance actor, compacted, with unused context values removed - 644 bytes gzip'd
mastodon.social instance actor, expanded - 707 bytes gzip'd
mastodon.social instance actor, compacted, with no context - 667 bytes gzip'd

RE: not-brain.d.on-t.work/notes/aihcsxrs45sw0wbq
0
4
1