MSC4174: webpush push kind #4174
Conversation
p1gp1g
force-pushed
the
webpush-pushkind
branch
from
0f3f077
to
6ccf76d
Compare
Signed-off-by: S1m <[email protected]>
p1gp1g
force-pushed
the
webpush-pushkind
branch
from
6ccf76d
to
24473e5
Compare
turt2live
added
push
proposal
There was a problem hiding this comment.
Implementation requirements:
- Client
- Server
| are defined in the Push Gateway Specification. Currently the only format available is ’event_id_only'. | ||
| - `url`: Required if `kind` is `http`, not used else. The URL to use to send notifications to. MUST be an | ||
| HTTPS URL with a path of /_matrix/push/v1/notify | ||
| - `endpoint`: Required if `kind` is `webpush`, not used else. The URL to send notification to, as defined as a |
There was a problem hiding this comment.
Probably a stupid question but could you not just reuse the url field?
There was a problem hiding this comment.
I wanted to mention it in the alternative part. Clients that already use webpush and must use a push gateway uses endpoint because url is the one used for the gateway.
So, defining that way would make their current PusherData spec compliant
There was a problem hiding this comment.
IMO, it would have been better to set pushKey and url in the PusherData too, but that's out of this proposal scope
There was a problem hiding this comment.
I agree that re-using the current field seems simpler.
There was a problem hiding this comment.
Re-using url as the http kind do ? Or Re-using endpoint like hydrogen and sygnal do ?
There was a problem hiding this comment.
Reusing the endpoint -- this definitely needs a different kind.
There was a problem hiding this comment.
Can I resolve this "conversation" then ?
| Having a webpush push kind would provide push notifications without gateway to | ||
| - Web app and desktop app | ||
| - Android apps using UnifiedPush (MSC2970 was open for this and won't be required anymore) | ||
| - Maybe other ? We have seen apple moving a lot into web push support |
There was a problem hiding this comment.
|
|
||
| Having a webpush push kind would provide push notifications without gateway to | ||
| - Web app and desktop app | ||
| - Android apps using UnifiedPush (MSC2970 was open for this and won't be required anymore) |
There was a problem hiding this comment.
Links showing UnifiedPush supports this would be helpful!
There was a problem hiding this comment.
The spec will be updated next month, and will be defined as RFC8030+RFC8291+RFC8292 aka webpush
Else, there is this comment: UnifiedPush/wishlist#15 (comment)
There was a problem hiding this comment.
https://unifiedpush.org/ Images shows Web Push now
| are defined in the Push Gateway Specification. Currently the only format available is ’event_id_only'. | ||
| - `url`: Required if `kind` is `http`, not used else. The URL to use to send notifications to. MUST be an | ||
| HTTPS URL with a path of /_matrix/push/v1/notify | ||
| - `endpoint`: Required if `kind` is `webpush`, not used else. The URL to send notification to, as defined as a |
There was a problem hiding this comment.
I agree that re-using the current field seems simpler.
| If the `kind` is `webpush`, this is the user agent public key encoded in base64 url. The public key comes from a ECDH | ||
| keypair using the P-256 (prime256v1, cf. FIPS186) curve. |
There was a problem hiding this comment.
Links off to the sections of the RFCs that define how to do this would probably be good.
There was a problem hiding this comment.
I don't see link to 25519 curve when ed25519 is mentioned, P-256 is a known curve. And this is already implemented in libraries
| Security considerations are listed by RFC8030 [4], there are mainly resolved with RFC8291 (Encryption) and | ||
| RFC8292 (VAPID). |
There was a problem hiding this comment.
To be clear -- Matrix would require all of these to be implemented then?
There was a problem hiding this comment.
WebPush is defined by those 3 RFC, so it would require these RFC
| [2] https://github.com/matrix-org/sygnal/blob/main/sygnal/webpushpushkin.py#L152 | ||
| [3] https://spec.matrix.org/v1.9/client-server-api/#post_matrixclientv3pushersset (search for PusherData) | ||
|
|
||
| ## Proposal |
There was a problem hiding this comment.
Examples of the request would be useful!
There was a problem hiding this comment.
Client side, this is already ~ implemented by hydrogen just changing http to webpush
Server side, this has to be merged into the server: https://github.com/matrix-org/sygnal/blob/main/sygnal/webpushpushkin.py#L351
There was a problem hiding this comment.
Isn't the whole point to bypass sygnal though?
Regardless, having examples in the MSC is important to show a full request/response.
There was a problem hiding this comment.
Definitely, I just wanted to say that most of the code in sygnal webpushpushkin can be used to write a synapse webpushpusher
proposals/4174-webpush-pushkind.md
Outdated
| Push notifications have the problem that they typically go through third-party gateways in order to | ||
| be delivered, e.g. FCM (Google) or APNs (Apple) and an app-specific gateway (sygnal). In order to | ||
| prevent these push gateways from being able to read any sensitive information the `event_id_only` format | ||
| was introduced, which only pushes the `event_id` and `room_id` of an event down the push. After | ||
| receiving the push message the client can hit the `GET /_matrix/client/r0/rooms/{roomId}/event/{eventId}` | ||
| to fetch the full event, and then create the notification based on that. |
There was a problem hiding this comment.
I think it isn't quite spelled out, but the goal here seems to be to avoid the push gateway, which avoids the application author seeing anything about the pushed information. So it allows going directly from homeserver -> push server.
There was a problem hiding this comment.
2 things:
- it avoids using a push gateway
- it adds E2EE to the notifications, so the push server don't see the content of the notifications
|
Thank you for your feedback @clokep, I'm updated the proposal soon |
Reword some sentences, add links
rendered