solid-notifications

[bourgeoa]

Objectives : apply solid-notifications protocol https://solid.github.io/notifications/protocol
and compatibility with CSS implementation https://github.com/CommunitySolidServer/CommunitySolidServer/documentation/markdown/usage/notifications.md

• discovery subscription service : link header (relative URL ?)
  link: <.well-known/solid-notifications>; rel="http://www.w3.org/ns/solid/terms#storageDescription"
• turtle subscription service document (if turtle relative ?)
  - [ ] WebSocketChannel2023 : podRoot/.notifications/WebSocketChannel2023/
  - [ ] WebHookChannel2023 : podRoot/.notifications/WebHookChannel2023/
• subscription
  - [ ] authenticated json-ld POST
  - [ ] read followed item
  - [ ] json-ld response (contains subscription URL)
• default duration of the subscription URL) : 2 weeks (?)
• unsubscribe : DELETE the subscription url received in the subscription response (no need to be authenticated)
• notifications messages json-ld
  - [ ] notification types
  - [ ] extra features

[csarven]

Objectives : apply solid-notifications protocol https://solidproject.org/TR/notifications-protocol

I suggest implementing: https://solid.github.io/notifications/protocol

• discovery subscription service : link header (relative URL ?)
  link: <.well-known/solid-notifications>; rel="http://www.w3.org/ns/solid/terms#storageDescription"

The reference to storageDescription is essentially same as storage resource's (e.g., the root container, /) describedby resource. So consider using something like </storage-description>.

Resource-centric notification information could also be obtained from a given resource's describedby.

Neither the Storage Description Resource or the Description Resource is limited to notifications information.

• unsubscribe : DELETE the subscription url received in the subscription response (no need to be authenticated)

Neither unsubscribe or DELETE is specified in Notifications Protocol.

[bourgeoa]

I suggest implementing: https://solid.github.io/notifications/protocol

done

Neither the Storage Description Resource or the Description Resource is limited to notifications information.

@csarven there is a discussion here zg009/solid-subscription-server#1

Neither unsubscribe or DELETE is specified in Notifications Protocol

Agreed. But CSS felt it was needed. No personal feeling

[csarven]

As you like.

I've already explained why DELETE to unsubscribe is unnecessary in some cases, relatively complicated, and inconsistent with how subscribing works ( solid/notifications#145 ). If folks still want to pursue that path, that's their call entirely.

As for CSS is doing it so NSS should too line of reasoning: keep in mind that decisions in CSS dev is along the lines of "we only implement what's in spec" (which is evidently not true in this and other cases) whenever it is convenient to handwave. On a related note, see also the copyright line. No personal feeling.

[zg009]

I agree with csarven . I think unsubscribe is unnecessary, especially since an endAt field can be specified by the server and is in spec. endAt doesn't mean you have to stop listening, just you have to open another channel. If a user needs an infinite channel, that could possibly be a separate notifications spec for themselves, or just creating a resource without endTime as a field in the subscription data model.

Edit: It can also be prudent for a server to sleep/end/suspend a channel if it is capable of managing servers.

[csarven]

To be clear, "[u]nnecessary [for some notification channel types]".

And for notification channel types that unsubscribing is useful, it can be accomplished in a similar way to subscribing, i.e., using POST to unsubscribe (as opposed to DELETE).

Any way, this is discussion for the spec space.