ActivityPub/ActivityStreams and JSON-LD


Hello there,

I am currently (re-)reading the ActivityStreams and ActivityPub specs regarding the usage of JSON-LD. In my mind there is (was), stuck around from reading elsewhere, the assumption/allegation that AP cannot be implemented without an fully-fleged JSON-LD parser. As for example stated here:

[…] I believe this promise [(all that is required is to add some context metadata)] falls short in the case of ActivityPub, though, or any federated system that tries to build directly on JSON-LD. Here, producers and consumers are different implementations that have taken the freedom of JSON-LD to format documents any way they want, through namespacing and aliasing. Now, every consumer needs to be a full implementation of JSON-LD in order to understand anything from its peers.

After reading the spec(s) again, I do not think this (a federated system build directly on JSON-LD) is the case for AP/AS (Activity Streams 2.0, §(?) 2.1 JSON-LD):

The serialized JSON form of an Activity Streams 2.0 document MUST be consistent with what would be produced by the standard JSON-LD 1.0 Processing Algorithms and API (JSON-LD-API) Compaction Algorithm using, at least, the normative [ActivityStreams 2.0] JSON-LD @context definition provided here.

To me this then means basic AS properties (type, id, …) must be there without needing to do to JSON-LD transformations – otherwise the implementation is not AS2 conform. To ActivityPub, being an extension to ActivityStreams, the same should apply.

Thanks so far. :slight_smile:


My opinion: A fully-fledged JSON-LD parser is nice but not required for an ActivityPub implementation.

For example, Jeremy (author of Pterotype) does normalize JSON-LD in order to cut down on boilerplate code accessing values. Because the tricky thing with JSON-LD is that the values of properties could be an IRI, a value literal, or an array-of-IRI/value literal/array-of-etc. He uses it more for convenience of accessing data than for any non-ActivityStreams-formatted-JSON-LD reasons.

I had the same convenience problem but had taken a different approach with go-fed, which uses code generation to cut down on this boilerplate. But that means at runtime it doesn’t have a fully-fledged JSON-LD parser, it just knows about JSON encoding and how to interpret properties (whatever their values’ form may be).

I think the result is, most implementations I am aware of don’t use JSON-LD parsing in order to transform all outside JSON-LD into a compacted format for further processing. They just accept the JSON as-is and attempt to then process it. Implementing the compaction algorithm is a lot of effort, and right now there’s not much in the ecosystem to be gained.


AP/AS was designed to be useable in applications naive of linked data. The grain of truth to the FUD is that establishment of an ecosystem of LD aware ActivityPub applications could render non-aware applications useless. As you noted this hasn’t happened yet, but even if it did then applications without LD support would still function as intended.

So you build with LD support if 1) your application uses other LD formats in addition to AP, or 2) a LD library already exists for your platform and using it isn’t significant overhead or learning curve.