I am periodically upset that ActivityPub does not mandate a closed json-ld context for all objects.
-
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.
Interoperability is when the servers can transmit the activities even if they don’t understand all the data. Practical interoperability is when you don’t need to implement json-ld compaction on the server.
-
Interoperability is when the servers can transmit the activities even if they don’t understand all the data. Practical interoperability is when you don’t need to implement json-ld compaction on the server.
@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 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 ...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 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 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 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 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*...
@trwnh public keys and pinned posts do not require the context to be extended.
-
@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*...
@trwnh so, if an extra bit of context is present, you have to check it, with all the pitfalls of json-ld expansion / compaction.
-
@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 public keys and pinned posts do not require the context to be extended.
@gugurumbe how do you represent public keys or pinned posts without additional context? if you are advocating for "everything should be pre-expanded", i.e. the literal representation being
"https://w3id.org/security#publicKey": [{"https://w3id.org/security#publicKeyPem": "..."}]
then i don't necessarily disagree with you, but most fedi devs will not like this.
-
@trwnh so, if an extra bit of context is present, you have to check it, with all the pitfalls of json-ld expansion / compaction.
@gugurumbe no, you can (and most fedi devs do) ignore it instead. this is what creates the interoperability problems, unless both peers share the same understanding of the meaning of "publicKey" or "featured". if you use "featured" to mean "a boolean for whether this current object is a featured object", this conflicts with mastodon's definition of "an AS2 Collection containing objects featured on the profile".
-
@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 how do you represent public keys or pinned posts without additional context? if you are advocating for "everything should be pre-expanded", i.e. the literal representation being
"https://w3id.org/security#publicKey": [{"https://w3id.org/security#publicKeyPem": "..."}]
then i don't necessarily disagree with you, but most fedi devs will not like this.
@trwnh yes, something like that. If they are reluctant, tell them it would be the only canonical way to represent it. Anyway, it is already a shape they should match, along with others with differently partially expanded IRIs. Now they would only have to match 1 shape.
-
@trwnh yes, something like that. If they are reluctant, tell them it would be the only canonical way to represent it. Anyway, it is already a shape they should match, along with others with differently partially expanded IRIs. Now they would only have to match 1 shape.
@gugurumbe that's indeed something i have pitched before and continue to pitch, for the exact reasons/benefits you stated just now. but there is a lot of inertia and reluctance still.
-
@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.
