#Tag
I am periodically upset that ActivityPub does not mandate a closed json-ld context for all objects. The reason it can accept new context definitions is basically so that useless examples can fit on less documentation space. It sacrifices practical interoperability for the theoretical comfort of developers.
I am periodically upset that ActivityPub does not mandate a closed json-ld context for all objects. The reason it can accept new context definitions is basically so that useless examples can fit on less documentation space. It sacrifices practical interoperability for the theoretical comfort of developers.
How would one advertise a URI Template in a JSON-LD document?
How would one advertise a URI Template in a JSON-LD document?
#OpenScience and the #fediverse .. let's get that ball rolling 💪
@jfietkau @jonny and @bonfire opened a brainstorm and evaluation on how we can provide better support for the academic world and #science in general to the #ActivityPub-based fediverse.
Various different iniitiatives are underway, and there's great opportunity to bundle forces and align these efforts where possible. Set standards.
Interested? Join the discussion:
https://discuss.coding.social/t/my-current-goals-for-activitypub-and-academic-data/750
#OpenScience and the #fediverse .. let's get that ball rolling 💪
@jfietkau @jonny and @bonfire opened a brainstorm and evaluation on how we can provide better support for the academic world and #science in general to the #ActivityPub-based fediverse.
Various different iniitiatives are underway, and there's great opportunity to bundle forces and align these efforts where possible. Set standards.
Interested? Join the discussion:
https://discuss.coding.social/t/my-current-goals-for-activitypub-and-academic-data/750
3/
I would assume that, from an ActivityPub & JSON-LD point-of-view, that these WAFRN "bites" / "pokes" are probably some type of custom Activity type.
RE: https://wedistribute.org/2025/10/wafrn-chaotic-good/
#ActivityPub #FediUX #Fediverse #FediveseUX #JSONLD #SpreadFediverse #wafrn
3/
I would assume that, from an ActivityPub & JSON-LD point-of-view, that these WAFRN "bites" / "pokes" are probably some type of custom Activity type.
RE: https://wedistribute.org/2025/10/wafrn-chaotic-good/
#ActivityPub #FediUX #Fediverse #FediveseUX #JSONLD #SpreadFediverse #wafrn
A minor update to FEP-fe34: Origin-based security model
https://codeberg.org/fediverse/fep/pulls/662
- Explained how to identify public keys. They can be identified by publicKeyPem and publicKeyMultibase properties ("duck typing").
- Added a warning for JSON-LD consumers. Even innocuously looking property can become publicKeyPem or publicKeyMultibase after doing JSON-LD transformations.
You can read more about this problem in this post: https://socialhub.activitypub.rocks/t/am-i-understanding-something-wrong-or-is-json-ld-remote-context-support-a-gigantic-security-vulnerability-if-any-dumb-c2s-server-implementation-tries-to-federate-with-the-current-network/5439/1
@kopper suggests possible workarounds there but I think they are way too complicated. Just don't do JSON-LD.
A minor update to FEP-fe34: Origin-based security model
https://codeberg.org/fediverse/fep/pulls/662
- Explained how to identify public keys. They can be identified by publicKeyPem and publicKeyMultibase properties ("duck typing").
- Added a warning for JSON-LD consumers. Even innocuously looking property can become publicKeyPem or publicKeyMultibase after doing JSON-LD transformations.
You can read more about this problem in this post: https://socialhub.activitypub.rocks/t/am-i-understanding-something-wrong-or-is-json-ld-remote-context-support-a-gigantic-security-vulnerability-if-any-dumb-c2s-server-implementation-tries-to-federate-with-the-current-network/5439/1
@kopper suggests possible workarounds there but I think they are way too complicated. Just don't do JSON-LD.
i'm not 100% sure about this but i am starting to think that the way #jsonld context declarations propagate by default is generally an anti-pattern
the problem is when you cross a semantic boundary, which happens most often due to naively dereferencing and embedding an entire resource ("inlining", "hydration"). it's especially likely to be an issue when you are using one or more protected contexts (where terms can't be redefined later).
1/?
in "property-scoped" terms, we would have to say that tag.*.actor always means either Activity.actor or Movie.actor. in effect, we are saying that every tag MUST be an Activity, or MUST be a Movie. in other words, our semantic range is no longer unbounded.
now, remember this problem only happened because we naively merged in a JSON resource into another JSON resource, leading to a conflict between the two contexts. what's a better way to handle graph merges while maintaining context?
5/?
one approach is to just say "well, plain JSON consumers should just stop being so naive". a valid approach, but not very robust!
our goal is to preserve the semantic boundary between different resources but still allow merging those resources naively (as JSON objects rather than as #JSONLD graphs).
instead of saying that a term will always mean the same thing in the entire document, we want to allow the same term to be used in different contexts across semantic boundaries (resources)...
6/?
let's demo this with a simple case. say you want to tag something that is a Movie described by schema.org. the Movie declares that it has an actor who performed in it.
this is redefining the term actor as defined at the top-level by #activitystreams -- where actor means who performed an Activity, not who performed in a Movie.
if the activitystreams context was protected, then this would be a fatal error for any #jsonld validator. you cannot be sure which actor was meant!
3/?
we have some tools to deal with this in #jsonld. we can "type-scope" so that an Activity.actor uses a certain definition, and a Movie.actor uses a certain definition, but this requires us to say ahead-of-time that Movie will always mean a schema.org Movie. it also won't help us redefine protected terms, since "type-scoped" terms don't override protection. only "property-scoped" terms do. but we can't use "property-scoped" terms because that requires an explicit semantic range.
4/?
say you have a generic property whose range is relatively unbounded -- a grab-bag where anything goes. something like how attachment or tag are used in #activitystreams. using multiple contexts at the top-level introduces a potential conflict in terms. you could reconcile any conflicts with a custom context, but that prevents reuse / understanding a more well-known context.
unfortunately, due to context propagation, terms defined earlier on can "leak" into the naively merged subgraph.
2/?
let's demo this with a simple case. say you want to tag something that is a Movie described by schema.org. the Movie declares that it has an actor who performed in it.
this is redefining the term actor as defined at the top-level by #activitystreams -- where actor means who performed an Activity, not who performed in a Movie.
if the activitystreams context was protected, then this would be a fatal error for any #jsonld validator. you cannot be sure which actor was meant!
3/?
i'm not 100% sure about this but i am starting to think that the way #jsonld context declarations propagate by default is generally an anti-pattern
the problem is when you cross a semantic boundary, which happens most often due to naively dereferencing and embedding an entire resource ("inlining", "hydration"). it's especially likely to be an issue when you are using one or more protected contexts (where terms can't be redefined later).
1/?
A space for Bonfire maintainers and contributors to communicate
