#ActivityPub ✅ #jsonld 🤷‍♀️ Why? 🤪

Hopefully the SocialWG will adopt a real schema language. 🙏

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

1/

RE: https://mastodon.social/@reiver/115945290105913697

Right now, Fediverse IDs resolve to HTTPS URLs.
For example, the Fediverse ID:

＠reiver＠mastodon.social

Resolves to HTTPS URL:

https;//mastodon·social/users/reiver

...

If we wanted cryptographic public-keys to serve as a basis of Identity on the Fediverse, then —

We would (similarly) also need a Fediverse ID to resolve to one or more cryptographic public-keys

...

#ActivityPub #Cryptography #FediDev #FediDevs #Fediverse #JSONLD

Fediverse & AI Coding Tools & Vibe Coding

...

I noticed 2 or 3 people lately using AI coding tools to create Fediverse software.

2 of them even seemed to be Vibe Coding.

...

I have been programming for over 30 years. I am probably not going to Vibe Code, but —

I wonder if we should help them.

There are tools we (Fediverse developers) could create to make it so others could Vibe Code Fediverse apps.

#ActivityPub #AICodingTools #Fedidev #Fedidevs #Fediverse #JSONLD #VibeCoding

Cryptographic public-keys are one way that one can have an identity (on the Fediverse, and elsewhere) while also having privacy — through a pseudonymous identity.

Yes, we have Fediverse IDs such as:

＠joeblow＠example.com

But a (non-delegated) public-key can function as a PORTABLE form of identity on the Fediverse.

#ActivityPub #Cryptography #Fedidev #Fedidevs #Fediverse #JSONLD