Add ldn-channel-2023 ED

[csarven]

This ED defines the LDNChannel2023 Notification Channel Type. This specification deprecates LinkedDataNotifications Subscription 2021.

---

Preview

[csarven]

• Updated to follow the structure of Solid Notifications Protocol Version 0.2.0.
• Introduced activityType as a feature to indicate the desired notification activity type, e.g., messages can be about particular activities, like when a resource is created or added to a container (a general requirement as suggested in https://github.com/solid/notifications-panel/issues/1#issue-489650894 ). I suggest making this a core feature of Solid Notifications Protocol.
• Subscription Server and Notification Receiver is a specialisation of LDN Receiver. (See also https://www.w3.org/TR/ldn/#subscribing-to-notifications ).
• Subscription resource and sendTo act like LDN inboxes. (See also https://github.com/solid/notifications/issues/36 )
• POSTing to it returns a 201 to a resource where it can be modified or deleted (aka unsubscribing). Whether DELETE is used to unsubscribe or POSTing again to the created resource indicating the changes to be determined. (See also https://github.com/solid/notifications/issues/145 ).
• Introduced receiver (analogous to sender) to identify the party (Notification Receiver) that controls the sendTo resource.
• Described an outline for exchanging public keys and towards signing messages. (Copied to issue https://github.com/solid/notifications/issues/148 ).

[acoburn]

Introduced activityType as a feature to indicate the desired notification activity type, e.g., messages can be about particular activities, like when a resource is created or added to a container (a general requirement as suggested in https://github.com/solid/notifications-panel/issues/1#issue-489650894 ). I suggest making this a core feature of Solid Notifications Protocol. Subscription Server and Notification Receiver is a specialisation of LDN Receiver. (See also https://www.w3.org/TR/ldn/#subscribing-to-notifications ).

I really like this idea, and I also think this should be considered for the core notifications protocol. I would suggest generalizing this a bit further, calling it, perhaps, filter, which would accept an object. For example:

{
    "filter": {
       "type": "Add"
    }
}

This would allow implementations (that support the feature) to have a much more generalized filtering mechanism.

To continue this example, one could add an actor property in the filter to accept only notifications from a particular agent. Other properties (e.g. tag) could be added to this, as needed. It could be a very extensible mechanism.

[csarven]

Merging as per https://github.com/solid/notifications-panel/blob/main/meetings/2023-02-02.md#add-ldn-channel-2023-ed .