search

zg009 / solid-subscription-server

0 stars 0 forks source link

NSS notifications endpoints #1

Open bourgeoa opened 3 months ago

bourgeoa commented 3 months ago

1. I was looking at CSS and found the following workflow endpoints on https://solidcommunity.net:3000 :

bo: a space:Storage; not:subscription Web:, We: .

Web: not:channelType not:WebhookChannel2023; not:feature not:accept, not:endAt, not:rate, not:startAt, not:state. We: not:channelType not:WebSocketChannel2023; not:feature not:accept, not:endAt, not:rate, not:startAt, not:state.

   - notifications endpoint
     - https://solidcommunity.net:3000/.notifications/WebhookChannel2023/
     - https://solidcommunity.net:3000/.notifications/WebSocketChannel2023/

#### 2. NSS is already using : 
- `.well-knom/solid` as capability-discovery for the discovery of accounts API endpoints :

{ "root":"https://bourgeoa.solidcommunity.net/.well-known/solid", "api": { "accounts": { "new":"https://solidcommunity.net/api/accounts/new", "recover":"https://solidcommunity.net/api/accounts/recover", "signin":"https://bourgeoa.solidcommunity.net/login", "signout":"https://bourgeoa.solidcommunity.net/logout", "validateToken":"https://solidcommunity.net/api/accounts/validateToken"} }}



There are at least 2 questions : 
- what endpoint for notification discovery ? I'm not very inclined to expend the actual capabilty-discovery endpoint
   What do you think of `.well-known/notifications` or  `.well-known/solid-notifications`
- notifications endpoints :
  CSS is using the idp hostname server `https://solidcommunity.net:3000/.notifications/` and not the pod hostname `https://bourgeoa.solidcommunity.net:3000`
  What shall NSS do ?  Is there any notification specification (I did not see any), or notification performance issue ?
zg009 commented 3 months ago

@bourgeoa

what endpoint for notification discovery ? I'm not very inclined to expend the actual capabilty-discovery endpoint What do you think of .well-known/notifications or .well-known/solid-notifications

I think .well-known/solid-notifications is fine. If you want to make it a configuration option on NSS config.json file, that would also work, so if a server provider wants to change it then they can. But I think solid-notifications is a good default.

notifications endpoints : CSS is using the idp hostname server https://solidcommunity.net:3000/.notifications/ and not the pod hostname https://bourgeoa.solidcommunity.net:3000 What shall NSS do ? Is there any notification specification (I did not see any), or notification performance issue ?

I do not think it is anything specifically regarding performance, but the Discovery specification on the Notifications Protocl mentions two separate things:

From Solid Notifications Protocol - Discovery

"Resource Servers that want to enable Subscription Clients to discover subscription services and notification channels available for a given resource MUST advertise the associated resources describing the subscription services and notification channels by responding to an HTTP request including a Link header with the rel value of describedby [POWDER-DR] and the Description Resource as link target [RFC8288]."

and

"Resource Servers that want to enable Subscription Clients to discover subscription services and notification channels available to a storage in which a given resource is in MUST advertise the associated resources describing the subscription services and notification channels by responding to an HTTP request including a Link header with the rel value of http://www.w3.org/ns/solid/terms#storageDescription [SOLID-PROTOCOL] and the Description Resource as link target [RFC8288]."

So I believe CSS is following the second discovery method in this instance, because they are using #storageDescription for storage level notifications advertisement. I would ask Rahul for more input on this question though.