Negotiating protocols between actors or clients

I neglected to mention this before, but in Linked Data Notifications there is a link relation of http://www.w3.org/ns/ldp#constrainedBy that seemingly could help here:

Inbox URLs can announce their own constraints (e.g., SHACL, Web Annotation Protocol) via an HTTP Link header or body of the resource with a rel value of http://www.w3.org/ns/ldp#constrainedBy. Senders should comply with constraint specifications or the receiver may reject their notification and return an appropriate 4xx error code.

This is mostly in line with some earlier discussion in FEP-eb22: Supported ActivityStreams types with NodeInfo - #11 by trwnh …but unfortunately, the LDN spec didn’t flesh this out fully. It’s not explained how a constraint should be described. Web Annotation Protocol describes basically using what amounts to an opaque profile URL:

Link: <http://www.w3.org/TR/annotation-protocol/>; rel="http://www.w3.org/ns/ldp#constrainedBy"

Presumably the simplest theoretical analogue would be something like:

Link: <http://www.w3.org/TR/activitypub/>; rel="http://www.w3.org/ns/ldp#constrainedBy"

Or possibly even:

Link: <https://docs.joinmastodon.org/spec/activitypub/>; rel="http://www.w3.org/ns/ldp#constrainedBy"

This is perhaps not ideal, because:

  • it relies on a lot of out-of-band knowledge, so it isn’t very useful for validating your payloads ahead-of-time (as SHACL would allow you to do).
  • You also end up with a potential proliferation of these “constraint URIs” which is not so much a problem for humans as it is a problem for machines.
    • Constraints may vary over time and thus should be versioned. This means even more URIs to deal with.
  • There is no inherent decomposition possible into separate features, since there is no expectation that the link resolves to anything machine-usable.
  • The scope of this link relation is more closely tied to validating payloads than it is describing side effects or behaviors.

…but at the very least, it’s worth bringing it up as prior art. Solid Protocol alludes to this briefly but still doesn’t define it.