I am a bit lazy to collect many references to past discussions on how-to use Linked Data appropriately for the definition of ActivityPub extensions (formats + behavior) to the (pluggable?) ActivityPub protocol. But I’ll cross-ref Linked Data: Undersold, Overpromised?
Discussions have been endless on how to use Linked Data (JSON-LD) appropriately to define AP vocabulary extension, but also the behaviors, business logic, message exchange patterns that come with them.
Linked Data support is a sensitive opinionated area. Many devs do not like LD (to put it mildly) and are using plain JSON in their impls, while others feel that LD is a must-have for future versatility of the protocol in terms of all the use cases that AS/AP is good for. However, these benefits of LD on the protocol level (rather than having LD elsewhere in ones application) for the extension mechanisms have never been clearly expressed AFAIK.
I mentioned on fedidevs chat in context of discussing using JSON Schema for vocab validation, triggered by @stevebate (highlight mine):
Maybe this is a no-go area, given that we want to retain backwards-compat, but suppose we got rid of JSON-LD in favor of some other kind of extension mechanism, what’d we missing out on?
In other words: Is LD worth all the effort and overcoming the reluctance of devs to broadly adopt it? Because broad adoption is a requirement for a resilient future AS/AP Fediverse.
Discussion went on (follow the chat links to catch up) and led me to ponder …
What if, instead of…
- ActivityPub is a Linked Data spec, but you can also treat it as JSON
We redefine as:
- ActivityPub is JSON, with a well-defined extension mechanism (e.g. using JSON-Schema + living docs)
- ActivityPub has an additional profile that allows you to make it Linked Data, and do untold magic. (i.e. go the extra mile)
Could we formulate a non-Linked Data extension mechanism that is an addition to current specs - so that it can be introduced without breaking backwards-compatibility, and still offer everyone that wants to venture into Linked Data realms the opportunity to do so?
My thinking is we could, if we…
- Offered something along the lines of Compliance Profiles.
- Provide means of message format definition and validation (e.g. with JSON schema)
- Where robust namespacing of extensions is a key requirement
- Have discoverable place where behavior etc. docs of an extension are to be found.
- Don’t make it too hard for LD audience to parse msgs…
- Though: Current spec may see them faced with non-LD custom msgs already.