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.
-
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 "
];just says:
"Hi machine, I am in the context of thread 123 about Berlin." -
Is ther a W3C minutes or kind of a meeting-protocol|spec. about this use of context?
-
Is ther 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?
@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).
-
@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 … -
@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
-
@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.
-
@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 @hongminhee Mastodon, Fedify and other implementations that treat LD as mandatory (
MUST) even if it's optional (SHOULD) will be non conformant. As Mastodon is the biggest implementation by far margin, deprecating it is no small feat. -
@mcc @hongminhee Mastodon, Fedify and other implementations that treat LD as mandatory (
MUST) even if it's optional (SHOULD) will be non conformant. As Mastodon is the biggest implementation by far margin, deprecating it is no small feat.@cochise @hongminhee But Mastodon famously doesn't actually *support* LD right? That's the point of the thread? So wouldn't they be the easiest to convince to stop supporting the thing they never supported?
-
@cochise @hongminhee But Mastodon famously doesn't actually *support* LD right? That's the point of the thread? So wouldn't they be the easiest to convince to stop supporting the thing they never supported?
@mcc @hongminhee Don't really support, but discards activities without
@contextanyway.I suspect JSON-LD was a way to have extensibility and escape XMPP's XEP hell with servers and clients not supporting or disabling features in an infinite matrix.
But seems community favors FEPs describing JSON schemas and hardcoding it over getting them from a server and mapping the object at runtime. -
@hongminhee I had a similar realization early on when implementing Pinka. I almost went full JSON-LD but found that to properly expand the document I might need to make network calls. I stopped worrying about unknown terms and just hard coded a list of well-known AS and APub terms for interoperability.
-
@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
the "incorrect" mastodon context in use right now (or equivalent), which can be swapped out for the "correct" mastodon context to be more compatible with generic json-ld (and more semantically correct)
the "incorrect" mastodon context in use right now (or equivalent), which can be swapped out for the "correct" mastodon context to be more compatible with generic json-ld (and more semantically correct) - mastodon-context-correct.jsonld
Gist (gist.github.com)
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.
-
@hongminhee I had a similar realization early on when implementing Pinka. I almost went full JSON-LD but found that to properly expand the document I might need to make network calls. I stopped worrying about unknown terms and just hard coded a list of well-known AS and APub terms for interoperability.
@kanru @hongminhee ironically this is what you're supposed to do! preload the terms you understand into local contexts. newer jsonld-adjacent specs (vc, cid, and so on) tell you that you MUST NOT fetch the contexts over the network at runtime, and instead MUST treat them as already fetched with a given sha256sum. https://www.w3.org/TR/cid-1.0/#json-ld-context
-
@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.
-
@mcc @hongminhee Don't really support, but discards activities without
@contextanyway.I suspect JSON-LD was a way to have extensibility and escape XMPP's XEP hell with servers and clients not supporting or disabling features in an infinite matrix.
But seems community favors FEPs describing JSON schemas and hardcoding it over getting them from a server and mapping the object at runtime.@cochise @mcc @hongminhee mastodon is one of the "better" ones in that regard, but famously requires you to have the same context as it (instead of expanding shorthand terms to the full IRIs and comparing those...)
-
@hongminhee if i can give one piece of advice to devs who want to process JSON-LD: dont bother compacting. you already know the schema you output (or you're just passing through what the user gives and it doesn't matter to you), serialize directly to the compacted representation, and only run expansion on incoming data
expansion is the cheapest JSON-LD operation (since all other operations depend on it and run it internally anyhow), and this will get you all the compatibility benefits of JSON-LD with little downsides (beyond more annoying deserialization code, as you have to map the expanded representation to your internal structure which will likely be modeled after the compacted one)generally agreed except
> you have to map the expanded representation to your internal structure which will likely be modeled after the compacted one
this is compaction but manual instead of using a jsonld processor to do it. maybe the more precise argument is "don't bother with auto/native compaction"?
with that said: you also lose out on flattening and framing, which are pretty cool features for transforming the serialization. if you don't care about those, ok fine
-
@julian @mat atproto lets you section things off by "app" roughly, which is something that could be done with "plain old http" using content-types and well-known uris.
json-ld makes it so that you don't have to use those -- the uris can be anything you'd like, including more natural names.
the problem is that people can and will disagree. "talk it out" is not a complete solution. the "talk it out" solution is things like central registries managed by the IANA which most treat as consensus.
