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