Skip to content

Latest commit

 

History

History
204 lines (143 loc) · 10.7 KB

2023-01-12.md

File metadata and controls

204 lines (143 loc) · 10.7 KB
Raw

W3C Solid Community Group: Notifications Panel

Present

Announcements

Meeting Recordings and Transcripts

  • W3C Solid Community Group Calendar.
  • W3C Solid Community Group Meeting Guidelines.
  • No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
  • Join queue to talk.
  • Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed.

Participation and Code of Conduct

Scribes

  • SC

Introductions

  • name: text

Topics

  • SC: Keeping the topics focused on work we need to iron out for the next release.

WIP Implementation Feedback

  • SC: We'll allocate some time for implementation feedback. Links to servers/applications and demos welcome.

Call for Implementations

URL: solid/notifications#141

  • SC: Please re-share and help keep the data up to date.

Add TR/2022/notifications-protocol-20221231

URL: solid/specification#491

Add Solid Notifications vocabulary and JSON-LD context

URL: solid/vocab#85

  • SC: Will make sure to merge next week alongside TR/2022/notifications-protocol-20221231.
  • SC: I do want to triple check here with the naming. Note the strings and differences:
    • http://www.w3.org/ns/solid/notifications
    • https://www.w3.org/ns/solid/notification/v1
  • SC: It'll work just fine (even considering notifications and notification as different things under solid/).
  • SC: I just hope there won't be confusion in reuse and that developers will copy/paste.
  • SC: Does anyone have concerns we should address about the naming before really going out live with it?
  • eP: Assuming the content-type will be right for the JSON-LD Context, i.e., application/ld+json.
  • SC: Yes for the JSON-LD context, and at least the Turtle for the vocab.
  • eP: LGTM.
  • RG: should both be http or https?
  • SC: No. Vocab uses http:, and JSON-LD context uses https:. http: is still the ongoing/predominant convention.
  • eP: Should I add notify: prefix to http://prefix.cc/notify with http://www.w3.org/ns/solid/notifications#?
  • SC: Please do.
  • eP: Why singular and plural difference?
  • SC: AFAIK, it is more for convenience of publishing at w3.org.
  • eP: I would prefer to avoid that singular plural nuance in URLs
  • RG: +1
  • SC: I can doublecheck with W3C Team about that before the merge.
  • SC: Should this be parked under /ns/solid or find something directly under /ns/, e.g., /ns/notify?
  • eP: I see no problem with /ns/solid, probably something to figure out with W3C if they have opinion.
  • RG: Prefer /ns/notify for reasons SC explained.

notifications-ucr

URL: #76

  • SC: Still in my todo. As mentioned, it needs a proper revision.
  • SC: Mostly we've been talking about topic-centric subscriptions, but subscriptions that match a certain shape seem also of interest by some implementers, e.g., only create activities. Just want to make sure this is well covered.
  • eP: Do you have a link? Data Registrations from SAI (interop spec) can possibly help with it.
  • SC: e.g., #1 mentions: Mechanism for actors to make a request to be notified about particular activities.
  • SC: Also recently expressed in CommunitySolidServer/CommunitySolidServer#1388

Too Slow: Please provide Updates-Via shortcut to secure web socket address

URL: solid/notifications#110

  • eP: {Walks through notifications-protocol-20231231}
  • SC: ???
  • TBL: That is an improvement but still extra GET.
  • eP: Can use same connection when description resource is on same origin, but would be good to have benchmarks.
  • RG: Could the channel be put on the header to bypass the GET?
  • TBL: That'd be ideal.
  • SC: The current spec takes the payload approach where information about the channels is revealed.
  • TBL: Danger with general framework would be more bureaucracy. The fast one gives the shortcut.
  • eP: The main problem with headers is that NotificationReceiver connects to Sender. When we try to put it in the header, which of those different types need to advertise? For multiple channel types, we need to define which are defined there. There may be much more delay connecting to wss. The second connection to HTTP/2 would be minimal before connection. Needs benchmark / speculation. Even if they can't be in parallel, there is minimal delay.
  • RG: Why is it a problem when we discover a resource to advertise one channel? Then the consumer wouldn't have to do the discovery.
  • eP: If we want to optimise speed, we need benchmarks and I'm willing to do Streaming HTTP benchmarks. Confident that Streaming HTTP would be faster than websocket. There is still work on the server to mint the capability URL. Designing without benchmarks may be premature optimisation.
  • TBL: Why do you feel that Streaming HTTP is faster to set up than websocket?
  • eP: Don't need to use capability URL and can regular authorization with the header. NotificationSender on the same origin as the server, then it'd use HTTP/2, then take the benefit of not making a second connection. I believe Streaming HTTP would be faster in benchmarks — don't have to create capability URL.
  • SC: Does this Updates-Via feature have to be part of this coming release?
  • TBL: Would be good to have benchmarks, but not sure if solidlabs would.
  • TBL: What do you think about rolling this out in rdflib? It would tell the app that if Updates-Via is there it can watch the resource, and then open the websocket.
  • TBL: I worry about rolling out code in the back where you don't know — client code would be much more complicated provided by the possibility of servers. From the point of view serving the app — very nice to be able to change the updates-via so that both the code ??? the rdflib code can take the change more quickly. We need to decide if rdflib can take the server-metadata.
  • SC: Will implementation in rdflib address some of the concerns?
  • SC: Currently the difference is additional request to description resource. After HEAD, you do GET, and have your websockets URL. So we have that extra GET. describedby/http://www.w3.org/ns/solid/storageDescription relations are already part of the Solid Protocol.
  • TBL: If in the second GET we get the websockets URL, that's already pretty fast.
  • SC: Continue the following topics in the next meeting.

Several questions after implementing

URL: solid/notifications#114

  • SC: I commented. Commenter satisfied. Will follow up with editorial updates.

Notification Channel Type Registry

URL: https://solidproject.org/TR/#notification-channel-type-registry

  • SC: Includes registry definition and table.

TR/notification-subscription-types

URL: https://solidproject.org/TR/notification-subscription-types

Include outdated warning in all subscription-types reports

  • SC: TODO for editors/authors of:
    • WebSocketSubscription2021
    • StreamingHTTPSubscription2021
    • EventSourceSubscription2021
    • LinkedDataNotificationsSubscription2021
    • WebHookSubscription2021
    • WebPushSubscription2022
  • SC: I can follow-up with updates to the README to draw attention to channel-types (indicate subscription-types is earlier work etc.)

Ensure EDs of notification-channel type

  • SC: Let's please make sure the ED publications of the notification-channel-type reflect notifications-protocol-20221231 for normative and non-normative information (e.g., update examples, authorization info).
  • SC: There should be no conflation with the earlier subscription-types approach. Implementers will be referring to these EDs and TRs soon!

Channel Types

Rename Subscription Resource to Subscription Service?

URL: solid/notifications#63

  • SC: There is some support to use "subscription service" or "subscription service resource".
  • SC: This change doesn't affect conformance, if we agree on change, I suggest that we quickly roll it into Version 0.2.0, TR/notifications-protocol-20221231.
  • SC: Any objections or concerns to change to "subscription service"?

A consistent naming scheme for Channel Types

URL: solid/notifications#34

  • SC: Commented.

Is the proposed notification endpoint negotiation tied to OIDC?

URL: solid/notifications#21

  • SC: Commented.

How does the proposed notification mechanism work?

URL: solid/notifications#8

Upgrade live update using to web sockets to "Secure Web Sockets"

URL: solid/notifications#13

Clarify you can watch a WebSocket for a resource to be created

URL: solid/notifications#5

WebSocket authentication/authorization

URL: solid/notifications#4

Recursion of WebSocket subscription requests

URL: solid/notifications#20