Desired changes for a future revision of ActivityPub and ActivityStreams

This depends on what you think JSON-LD is. If you think of “plain JSON” with the following restrictions:

  • the key of every property must be an IRI
  • the value of every property is a set of either @id or @value nodes

then congratulations, you’ve just reinvented JSON-LD expanded form. The extra complexity only comes in once you want to use something other than IRIs as keys. But why would you? IRIs are better than plain strings or UUIDs or whatever, because they have the chance of returning something when you deref them. You can fetch http://schema.org/actor and it links to documentation on exactly what the term means. You also can immediately tell it’s not the same as https://www.w3.org/ns/activitystreams#actor.

Well, let’s say you still want to use non-IRIs as keys, because you already have an existing API that returns JSON. This is where you would stick a @context in there to make your ambiguous JSON into unambiguous JSON-LD. But this is an optional step. You can continue to work with the unqualified JSON… but the second you want to share data with some other system, you NEED that other system to have the same context as you, the same fundamental understanding of what an actor is. On the scale of the entire Web, you really CANNOT depend on any two random systems to share the same context a priori. Is this document using actor in the AS2 sense or the Schema dot org sense? You have no way of knowing. Suddenly, you’ve fractured your network into two halves: one that understands AS2, and one that understands Schema dot org. This is bad for the Web. The unambiguous thing to do would be to take whatever JSON you have, inject a @context… and then expand it to something unambiguous. But again, we don’t do that, because… it looks prettier to not do that.

This doesn’t require anything other than standard JSON handling unless you want to convert between JSON-LD forms, most likely to get rid of @context and end up with something unambiguous, which is what you need. Or alternatively, you can ignore the JSON-LD bits, but you lose extensibility and you’re forced to stay within whatever worldview you’re assuming the document shares with you. This is what I mean when I say that JSON-LD is the cost of decentralized extensibility, or that you get decentralized extensibility “for free” with JSON-LD – when everything is an IRI, it’s unambiguous. You don’t need a JSON-LD library to work with expanded form. You also don’t need a JSON-LD library to work with compacted form as long as you implicitly share the context of the document. The complexity only starts to creep in once your implicit context differs from that of the document. That’s when you have to start asking questions like:

  • “wait, is the actor of this activity the actor or the activitystreamsActor or the doer_of_activities or…”
  • “i have an actor property but how can i be sure that it refers specifically to the entity that performed an activity? what if it’s an actor in a movie? what if it’s a person or organization responsible for a process in the Internet Of Construction? what if it’s a contextual aspect according to BS EN 17412-1 (2020)? if only there was some way of unambiguously knowing this…”

and these questions start cropping up more and more as you stray further and further outside the bounds of any one specification or problem domain.

In summary, if the goal is to avoid using a special JSON-LD processor and be able to parse a document with standard JSON processors, then that’s something that can be accomplished. But generally this means either “use expanded form” or “assume shared context ahead-of-time”. And AS2 went with the latter, but basically punted all other extensibility considerations to JSON-LD, which I admit can get annoying (and non-trivial!) when you have to process @context. So AS2 ended up in this situation where JSON-LD is the extensibility method, but you’re forced into using the compacted form, which is decidedly not ideal for extensions. I’m going to once again point to the discussion at FEP-e229: Best practices for extensibility for exploration of the implications of extensibility in a world where you’re forced to use compacted form.