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.
-
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
@contextright. 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 i struggling badly with rust cuz it's rust being rust... i can imagine a duck typing lang might have easier time
-
@hongminhee i struggling badly with rust cuz it's rust being rust... i can imagine a duck typing lang might have easier time
@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
-
Can you specify "threadiverse" software cause like all properties which are not marked as "functional" in the ActivityPub Spec, `context` is an Array and I do not see any problem …
^ what I mean :
"context": [
"https://threadiversesoftware.example.org/thread/123",
"https://www.wikidata.org/wiki/Special:EntityData/Q64 "
];then says:
"Hi machine, I am in the context of thread 123 about Berlin." -
@sl007@digitalcourage.social eh? You use
context?ForumWG decided to use context to represent threads in threadiverse software (and Mastodon too, now).
Just FYI.
Is there a W3C minutes or kind of a meeting-protocol|spec. about this use of context?
-
Is there a W3C minutes or kind of a meeting-protocol|spec. about this use of context?
@sl007@digitalcourage.social FEPs 7888 and f228 details the use of
contextand one use case of it, to backfill conversations. -
@silverpill@mitra.social POSTing that inbox sends a 404?
-
@sl007@digitalcourage.social FEPs 7888 and f228 details the use of
contextand one use case of it, to backfill conversations.well, but that is _exactly_ the same of the official Social CG meetings !
"This context property is the URL of the NodeBB topic."
vs.
"The context property should be used to identify the context in which the object appears in, form a common topic or group content. This can be a well known JSON-LD vocabulary or any ActivityPub Object useful for the implementation."
vs
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-context :„Identifies the context within which the object exists or an activity was performed.
The notion of "context" used is intentionally vague. The intended function is to serve as a means of grouping objects and activities that share a common originating context or purpose. An example could be all activities relating to a common project or event. “and I am glad cause, as said
"context": [
"https://threadiversesoftware.example.org/thread/123",
"https://www.wikidata.org/wiki/Special:EntityData/Q64 "
];
then says:
"Hi machine, I am in the context of thread 123 about Berlin."and then
🧵 1/2
-
well, but that is _exactly_ the same of the official Social CG meetings !
"This context property is the URL of the NodeBB topic."
vs.
"The context property should be used to identify the context in which the object appears in, form a common topic or group content. This can be a well known JSON-LD vocabulary or any ActivityPub Object useful for the implementation."
vs
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-context :„Identifies the context within which the object exists or an activity was performed.
The notion of "context" used is intentionally vague. The intended function is to serve as a means of grouping objects and activities that share a common originating context or purpose. An example could be all activities relating to a common project or event. “and I am glad cause, as said
"context": [
"https://threadiversesoftware.example.org/thread/123",
"https://www.wikidata.org/wiki/Special:EntityData/Q64 "
];
then says:
"Hi machine, I am in the context of thread 123 about Berlin."and then
🧵 1/2
and then
1) machine gets thread (cause is JSON-LD by known/allowed `generator`)
2) machine fetches or gets cached wikidata entry about Berlin and displays the card (kind of "infobox" then).
.. from the named "SpecialEntitiyData" of wikidata which is JSON-LD as well.
3) machine is happyapart from our tools, I need to credit Max Lath who is doing inventaire, the federated book library and did a lot of previous work for wiki JSON-LD like the wonderful https://github.com/maxlath/wikibase-sdk
-
and then
1) machine gets thread (cause is JSON-LD by known/allowed `generator`)
2) machine fetches or gets cached wikidata entry about Berlin and displays the card (kind of "infobox" then).
.. from the named "SpecialEntitiyData" of wikidata which is JSON-LD as well.
3) machine is happyapart from our tools, I need to credit Max Lath who is doing inventaire, the federated book library and did a lot of previous work for wiki JSON-LD like the wonderful https://github.com/maxlath/wikibase-sdk
PS - just btw;
about inventaire I am sharing currently photobooks for free rent in Dortmund, Germany
https://inventaire.io/users/sl007
they have also nice use for JSON-LD re. books /authors etc. https://data.inventaire.io/ like so many software in fedi.
If you ask the redaktor Service Actor for Place (`Question`) to find you a waffle restaurant in Amsterdam serving blue syrup near a train station then we do also use SPARQL like them - without the AI bullshit - just cause millions of friendly humans contributing to wd and OSM … -
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
@contextright. 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 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?
-
@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?
@mcc@mastodon.social asking the important questions
-
@julian Yes, POST to personal inbox sends a 404, POST to group inbox sends a 202 (I guess group inbox is how we communicate now).
@silverpill@mitra.social okay! That's a little concerning because all of those routes just end up going to the same controller... but this gives me enough to debug, so thank you!
-
@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?
@mcc@mastodon.social I'm not sure, but that would break some ActivityPub implementations relying on JSON-LD processors.
-
I incentive moved this topic from Uncategorized
