I am periodically upset that ActivityPub does not mandate a closed json-ld context for all objects.
General Discussion
21
Posts
3
Posters
40
Views
-
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 ...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.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@pixelschubsi @tris Yes, agreed. Tremendous value in reusing identities and login credentials. Big skepticism with regards to using AP as a protocol. One can probably kinda make it work… But why? What’s the benefit?
-
@daniel @tris I'm also genuinely surprised that people believe that ActivityPub, a protocol even named after its purpose, to publish activities, is a good protocol to pursue private instant messaging. The goals of those two couldn't be more detrimental.
I do see a purpose of being able to reuse your "ActivityPub identities", which actually are just WebFinger identities. Maybe someone should specify how to discover XMPP accounts via WebFinger and push that as a solution for AP messaging?
-
@tris Soatak is an expert in cryptography. I’m not. I’m more than happy to stand on the shoulder of giants when it comes to E2EE. That’s why we used the Signal Protocol 10+ years ago for #OMEMO and are now looking towards #MLS. However, good, interoperable protocol design is so much more than just E2EE. And maybe I've learned a thing or two about protocol design in my career that they don’t necessarily know.
-
@tris there are three actively developed protocols for federated instant messaging (XMPP, Matrix, Deltachat). At least one of them is very open to new developers and new ideas and has a structure in place to collaboratively work on those ideas and bring various stake holders together. With no disrespect to that individual I don't see why there needs to be a forth protocol loosely based on ActivityPub.
-
@daniel Ah, fair, their work for E2EE Fedi looks interesting: https://github.com/fedi-e2ee/public-key-directory-specification
-
@tris two things: I already said in my follow up post that if someone wants to build their own clients on top of XMPP and prefers MLS over OMEMO, the XMPP community is very open to that. A protocol is much more than just the encryption. They would still benefit from all the other things XMPP has solved.
A lot of what's in that blog post is ill-informed and bordering on disinformation and fear mongering.
-
@daniel Someone have to solve https://soatok.blog/2024/08/04/against-xmppomemo/ issues first
-
@dragospirvu75 @matrix @delta @lazarus The way to achieve interoperability is to stop reinventing the wheel and agree on one standard. Implementing three protocols is completely unfeasible and unnecessary. This worked 20 years ago with MSN, ICQ and AIM when IM protocols had a lot less features and no E2EE. Doesn’t work today.
