I am periodically upset that ActivityPub does not mandate a closed json-ld context for all objects.
-
@gugurumbe As far as interoperability is concerned, most fediverse softwares/servers actually don't transmit activities at all! They consume the activities almost like RPC, unwrapping them for their side effects then discarding the actual activity. Fedi devs might ignore the parts they don't understand (as they SHOULD), but they also might just ignore the activity entirely -- leading to a state desync.
This lack of interoperability isn't due to the context at all, since context gets ignored.
@gugurumbe For ActivityPub in a more general sense outside of the fediverse, POSTing to the outbox should transmit the data as-is even if not understood, and POSTing to the inbox should preserve the transmitted data as-is even if not understood. There aren't really constraints on what the outbox and inbox do internally; they can store HTTP payloads, JSON payloads, or RDF payloads (as long as they preserve the context for reserialization).
-
@gugurumbe ...since the interop issues all stem from applications naively assuming that that any additional context *they* require is also being shared on the other end.
One solution is to force everyone to pre-expand everything not defined in the normative activitystreams context, but most devs want to work with compacted representations without running the compaction themselves.
The other solution is to have everyone be responsible for expanding what they receive, and this is what AS2 chose.
@trwnh ok, so activitypub accepts extra contexts for the comfort of developers, requiring json-ld compaction on the server. Thank you.
-
@trwnh ok, so activitypub accepts extra contexts for the comfort of developers, requiring json-ld compaction on the server. Thank you.
@gugurumbe no, i am saying it doesn't require json-ld *compaction*, but rather *expansion*.
if you didn't want to require json-ld expansion, you could instead require *pre-expansion*, i.e. using the expanded form to be completely unambiguous.
otherwise, you require a central registry.
-
@gugurumbe no, i am saying it doesn't require json-ld *compaction*, but rather *expansion*.
if you didn't want to require json-ld expansion, you could instead require *pre-expansion*, i.e. using the expanded form to be completely unambiguous.
otherwise, you require a central registry.
@trwnh the problem with compaction is that of expansion really: you have to query a different server, possibly offline (for you, for others, now, in the past, or in the future), possibly lying (to you, to others, now, in the past, or in the future), or with obfuscated contexts, and run an algorithm that redland considers “too complex to implement”.
-
@trwnh the problem with compaction is that of expansion really: you have to query a different server, possibly offline (for you, for others, now, in the past, or in the future), possibly lying (to you, to others, now, in the past, or in the future), or with obfuscated contexts, and run an algorithm that redland considers “too complex to implement”.
@gugurumbe that seems to be several completely separate issues to me. before any communication becomes possible, we have to agree on terms. after we agree on terms, we can make statements. but statements can be unavailable, false, outdated, etc. -- your understanding of the statements remains unaffected.
you can think of contexts as "obfuscation", but they are really just "definitions". the question is, should you expect everyone to provide definitions? and there are two levels of definitions.
-
@gugurumbe that seems to be several completely separate issues to me. before any communication becomes possible, we have to agree on terms. after we agree on terms, we can make statements. but statements can be unavailable, false, outdated, etc. -- your understanding of the statements remains unaffected.
you can think of contexts as "obfuscation", but they are really just "definitions". the question is, should you expect everyone to provide definitions? and there are two levels of definitions.
@gugurumbe the first level is mapping a shorthand term to a full identifier. this is what json-ld does, if you care to do it. you can make json-ld optional by requiring everyone to use full identifiers always.
the second level is mapping identifiers to concepts. this is more based on social agreement, but with http(s): identifiers there is an easy "hack" -- just use the authority component (web origin) to determine who gets to define what identifiers mean. whatever they say is whatever goes.
-
@gugurumbe the first level is mapping a shorthand term to a full identifier. this is what json-ld does, if you care to do it. you can make json-ld optional by requiring everyone to use full identifiers always.
the second level is mapping identifiers to concepts. this is more based on social agreement, but with http(s): identifiers there is an easy "hack" -- just use the authority component (web origin) to determine who gets to define what identifiers mean. whatever they say is whatever goes.
@gugurumbe fedi devs skip over these levels and go straight from a shorthand term to a concept. the problem with this is that no one "owns" the shorthand terms, so you can't get an authoritative answer on what anything means. you have to defer to some kind of lookup table, and everyone you talk to has to agree to use the same one. just like everything the IANA does with their central registries, but in fedi we do not have any authorities, so shorthand terms are defined by consensus only.
-
@gugurumbe that seems to be several completely separate issues to me. before any communication becomes possible, we have to agree on terms. after we agree on terms, we can make statements. but statements can be unavailable, false, outdated, etc. -- your understanding of the statements remains unaffected.
you can think of contexts as "obfuscation", but they are really just "definitions". the question is, should you expect everyone to provide definitions? and there are two levels of definitions.
@trwnh the understanding of the statements in the document may be different between the receiver and the sender, if the context dereferences to different term definitions for both parties.
Obfuscation is a different story, but it can be used to partially prevent human review of the data if something goes wrong. -
@gugurumbe fedi devs skip over these levels and go straight from a shorthand term to a concept. the problem with this is that no one "owns" the shorthand terms, so you can't get an authoritative answer on what anything means. you have to defer to some kind of lookup table, and everyone you talk to has to agree to use the same one. just like everything the IANA does with their central registries, but in fedi we do not have any authorities, so shorthand terms are defined by consensus only.
@gugurumbe so if you see a term "featured", it has effectively been claimed by Mastodon through prior use and most people assume the Mastodon definition. just like people see "actor" and assume it means "who performed this Activity" and not "who performed a character role in a movie", except in the latter case we have an actual definition by the W3C inherent to the media type of application/activity+json, and in the former case we do not have any way to disambiguate.
-
@gugurumbe For ActivityPub in a more general sense outside of the fediverse, POSTing to the outbox should transmit the data as-is even if not understood, and POSTing to the inbox should preserve the transmitted data as-is even if not understood. There aren't really constraints on what the outbox and inbox do internally; they can store HTTP payloads, JSON payloads, or RDF payloads (as long as they preserve the context for reserialization).
test refederation
-
@gugurumbe so if you see a term "featured", it has effectively been claimed by Mastodon through prior use and most people assume the Mastodon definition. just like people see "actor" and assume it means "who performed this Activity" and not "who performed a character role in a movie", except in the latter case we have an actual definition by the W3C inherent to the media type of application/activity+json, and in the former case we do not have any way to disambiguate.
test refederation
-
@trwnh the understanding of the statements in the document may be different between the receiver and the sender, if the context dereferences to different term definitions for both parties.
Obfuscation is a different story, but it can be used to partially prevent human review of the data if something goes wrong.test refederation
-
@trwnh the problem with compaction is that of expansion really: you have to query a different server, possibly offline (for you, for others, now, in the past, or in the future), possibly lying (to you, to others, now, in the past, or in the future), or with obfuscated contexts, and run an algorithm that redland considers “too complex to implement”.
gugurumbe@mastouille.fr iirc, general best practice in JSON-LD is to either preload contexts or to fetch and cache indefinitely, unless you encounter a new property you don't understand, and then refetch and cache.
-
@thisismissem Caching is why the server hosting the context can declare wrong term definitions even if it only lied in the past.
