Linked Data Notifications Specialisations

[csarven]

Note: I'm not sure if this Project Proposal about specialising LDN falls under Data Interoperability Panel but it is the closest one I can think of right now. It may not be an exact fit either and I think the work around it is significant enough that it can be its own panel (Notifications Panel?). So, for the time being, I'm dumping the following information here but happy to move it elsewhere. If you respond, please first mention whether a separate panel makes sense while coordinating with the Data Interoperability Panel.

LDN Specialisations

Note: "LDN Specialisations" is a temporary title.

Status: Considerations for further work on formulating specialisation of LDN.

Background

The LDN's Exit Criteria https://www.w3.org/TR/ldn/#exit-criteria states:

Interoperability occurs between senders and receivers, or between consumers and receivers, when the sender/consumer makes a request to the receiver, and the receiver sends the expected response, as defined by this specification.

An implementation is an LDN sender, receiver or consumer which implements the corresponding conformance class of the specification.

https://csarven.ca/linked-data-notifications#design-decision states:

Implementations of the protocol can play one or more of these roles, and interoperate successfully with implementations playing the complementary roles. This means that notifications generated by one application can be reused by a completely different application, accessed via the store where the notification data resides, through shared Linked Data vocabularies.

Specialisations

LDN can be specialised using specific data shapes or vocabularies eg. AP's use of LDN ( https://csarven.ca/linked-research-decentralised-web#relationship-with-activitypub ). Further, interoperability occurs between senders, receivers and consumers based on different interaction flows. For example, a specialisation would encompass a set of interactions using particular shapes to address LDN Requests to "Activity Subscription", "Resource Access" or even "Service Actions".

Requirements (min/max?):

• Data shapes or vocabularies
• Set of interactions

Note: The data shape or vocabulary is what's explored in Solid. Considering a class of interoperability possibilities based on multiple interactions isn't (that I know of).

Activity Subscription

Actors in the system may want information sent to them about particular shapes or when certain events or activities take place.

https://csarven.ca/linked-research-decentralised-web#subscribing-to-notifications discusses how "Subscriptions" (or push-like interaction) can be arranged between LDN applications.

What needs to be defined:

• Shape/Vocabulary to indicate a "Request Notification" about subscribing to certain activities eg. when resources are created, changed..
• Interaction path

One possible interaction path can be along these lines (after sender picking a target of interest and performing Inbox discovery as per LDN):

1. SenderA makes a "Request Notification" to ReceiverB.
2. ConsumerB gets the Request Notifications from ReceiverB (coordinating with SenderB).
3. SenderB (coordinating with ConsumerB) sends notification to ReceiverA (coordinating with Sender A).

Note: Perhaps interaction Step 2 may be quietly skipped by implementations performing both ReceiverB and SenderB with same access/reuse rights to the resources. The interaction above factors in a Consumer because the Sender needs to be informed somehow and that information is carried over the Request Notification that a Consumer fetches and possibly processes before Sender finalising the workflow.

Resource Access

Access to resources is generally about "x requests permission on y (in order to perform operation(s) z)" or many other variations.

See also some issue where this use case emerged (at least across 3 different repositories):

• Creating a PATCH request solid#250
• 'Request Access' html on 401 responses web-access-control-spec#40
• Extend 403 template to request access nodeSolidServer/node-solid-server#992

Service Actions

This may be a bit pie in the sky... but falls under the request category that may be worth to at least keep in mind - not necessarily a good idea to implement at this point in time.. Issues like solid/specification#36 needs to be considered as well as security implications.

• Activate service..
• Create resources..
• Create/Update/Delete user accounts..
• Migrating a pod to another server..
• Archiving a pod (taking snapshots at some service eg IA)
• Delegated agent performs a task at a certain time..

?

[RubenVerborgh]

Good stuff. IMHO we need a panel on notifications (which I'm interested in).

The "shape" part is indeed related to what happens here, but the "actions" are definitely something else. We need broader thinking on how to react to notifications etc.

[justinwb]

In complete support of what's proposed here as a worthy project (even several projects potentially). Notifications / events are a fundamental type of interoperability between different agents and pods. At the same time, they are also a fundamental part of the ecosystem architecture. So, I think that this warrants its own panel.

We should also consider carving out room for mechanisms to identify/verify the sender of a given notification, verify data hasn't been tampered with in transit, encrypt/decrypt payloads, etc.

[pmcb55]

Just a quick question/comment, there are a couple of references to 'Data shapes or vocabularies' or 'Shape/Vocabulary' - but aren't shared vocabularies a fundamental requirement here, and Shapes are simply constructed from terms from those shared vocabularies (with the caveat that inference could 'infer' the 'shared-ness' of vocabularies, e.g. if I use 'foaf:name' but you use 'schema:name', yet the context of our interaction also includes a 'foaf:name owl:sameAs schema:name')...? In other words, should the text above consistently say something like 'Shapes (made up of terms from vocabularies)'...? Or is the point that Shapes are kinda optional, and that simply having shared vocabularies can be enough for interoperability in relation to notifications...?

[csarven]

I intended to be brief up there to get ideas flowing and where to situate this work. We can explore further in a panel (I'll follow up with a proposal on that..)

I think there is room for both shapes and vocabs. Minimal or possibly simplest interop can indeed happen via specific vocab terms, but may not be flexible enough for "wider" interop. At the very least, specifying exact terms will have a scope. Nothing wrong with that if that kind of up-front agreement is made. In fact, on the vocab end of things, AP specialises LDN by using AS2 in notifications. Aside: AP serves as a decent example of a specialisation.. we can explore other possibilities. Shapes can further help to negotiate. Ditto profile Link relation type to negotiate vocabs. And, yes, term equivalences would be just as valid. We can figure out all that in layers - also a good reason to coordinate with data-interop-panel. Strawman: AS2, an extension of it, or something else in combination can be used to make Request Notifications provided that actors check/try alternatives first eg. checking constrainedBy or whatever for shapes.

We just need to put a sufficiently flexible mechanism for different specialisations to be formualised. Specific Use Cases can eventually set the requirements on what's ultimately allowed ie. what shapes/vocabs, interaction composition.

[dmitrizagidulin]

Enthusiastic +1 to establishing a notification panel!

@justinwb

We should also consider carving out room for mechanisms to identify/verify the sender of a given notification, verify data hasn't been tampered with in transit, encrypt/decrypt payloads, etc.

Yess!! I highly encourage everyone to come over to the dark side er I mean to the Solid Cryptography Panel for those very discussions!

[csarven]

Follow up at solid/process#116 .