@gugurumbe ActivityStreams 2.0 Core says you MUST assume the normative w3 activitystreams context even if not explicitly declared, although you MAY use additional context, provided that you MUST NOT override any terms defined in the normative context.

this is done to allow extensibility, because AS2 is not a universally complete model. not for "useless examples", unless you consider public keys or pinned posts "useless".

the problem is not requiring json-ld compaction but rather *expansion*...

@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.

@gugurumbe Unfortunately for the 2nd solution, despite what AS2 says about expanding terms not defined in the normative activitystreams context, most devs expect to work directly with the compacted representations and not run the expansion themselves.

Thus, they open themselves to ambiguity because they are ignoring the context and assuming the meaning without actually verifying it. This works for consensus terms within the activitystreams context, but fails for non-consensus "extension" terms.

@gugurumbe The 3rd solution, which is not really a solution at all, is that AS2 could instead treat the normative context like a central registry. Similar to how the IANA tracks things like media types and HTTP headers, the W3C could have required that properties are centrally registered with them before they become valid for use. This would likely involve adopting things like the Security Vocabulary or the Mastodon-specific extensions, but which things should get adopted and which ones not?

@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).

@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.

@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 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.

@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 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

test refederation

test refederation

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.