Define WebPushSubscription2022 type for Solid Notifications #64
Conversation
|
I will review it this weekend, meanwhile, I pushed your branch to my fork so that GitHub action renders it. I still need to set up the rendering preview for each PR. Preview of this branch at d5ff597 is available here: https://elf-pavlik.github.io/notifications/webpush-subscription-2022 |
| <li> | ||
| **Establish Subscription:** | ||
| The *subscriber* subscribes to the *browser messaging service* to receive Web Push notifications using the `vapidPublicKey` of the *subscription service*. | ||
| In return, the *subscriber* retrieves the `endpoint`, `auth` and `p256dh` values. |
There was a problem hiding this comment.
We're trying to move away from the use of endpoint. Depending on the context, we generally use subscription, topic or source. It seems that subscription might be best suited here, but I'll leave that up to you.
There was a problem hiding this comment.
This particular endpoint is the "Push Endpoint" of the PUSH API. Discussion in the other comment on code.
However, I did use the term subscription endpoint which I now have replaced with Notification Subscription API as used by the Notifications Protocol.
| %% Issue(62): | ||
|
|
||
| : endpoint | ||
| :: The `endpoint` property indicates the "Push Endpoint" as defined in the [[!PUSH-API]] specification. |
There was a problem hiding this comment.
The Push API, does refer to this as an "endpoint", but in our context, subscription is likely the better term
There was a problem hiding this comment.
Hm. I am hesitant to call the property 'subscription' / pushSubscription.
- the property name is already defined by the Push API
- the property is also called
endpointin the corresponding JS implementation of the Push API.
I think renaming this property would make it more confusing to an implementer.
On the other hand,
A push subscription has an associated push endpoint. It MUST be the absolute URL exposed by the push service where the application server can send push messages to. A push endpoint MUST uniquely identify the push subscription.
indicates that the endpoint is quite the overloaded term when they try to say that the URL identifies the push subscription.
If I had to switch from endpoint to something else, I'd prefer pushSubscription over subscription just to be explicit which one is meant.
There was a problem hiding this comment.
Since this is a property on the subscription request, not the subscription response I would not use subscription here. I think other subscription types call this endpoint a target, since the publisher of notifications, should deliver them to that target` endpoint.
| "Aaron Coburn", | ||
| "Sarven Capadisli" | ||
| ], | ||
| "href": "https://solid.github.io/notifications/protocol", |
There was a problem hiding this comment.
not to change now, but just FYI that this will (soon?) be under the https://solidproject/TR/ URI space
| "elf Pavlik", | ||
| "Dmitri Zagidulin" | ||
| ], | ||
| "href": "https://solid.github.io/solid-oidc", |
There was a problem hiding this comment.
not to change now, but just FYI that this will (soon?) be under the https://solidproject/TR/ URI space
There was a problem hiding this comment.
Approving (and will follow with a merge) as per https://github.com/solid/notifications-panel/blob/main/meetings/2022-05-05.md#define-webpushsubscription2022-type-for-solid-notifications with the understanding that there are no significant blockers or objections for this document to be added here as the initial Editors Draft. The work on the work item can continue - including issues that it needs a solution for, as well as the unresolved conversations here.
Thanks for kicking this off.
Dear all,
I propose a first draft for defining the
WebPushSubscription2022type, based on my original submission, as decided in the Notifications Panel meeting on 2022-03-22 (see solid/notifications-panel#52).This PR addresses #35.
While writing this draft, I noticed that several existing issues need to be resolved prior to finishing this draft, including but not limited to #36, #62 and #63.
I deeply appreciate any feedback.