notifications
notifications copied to clipboard
nextcloud
WebPush support
Support for pushing to WebPush compatible servers would be very useful. It would allow pushing to the web app even when the tab is closed, and to the F-Droid version of Nextcloud Android using UnifiedPush.
Implementation
The primary things that need to be changed are:
- Create a v3 API endpoint to register devices with WebPush style keys
- Change the encrypt function to handle the WebPush keys in case the device is v3
- Minor changes to headers on sending the push request
Advantages
Can push to Web and open source Android apps (using a fully self-hosted notification stack) through existing push channels (no need to keep a new connection open).
Previous relevant discussions
This repo is the first step before such a feature could be used in apps. See https://github.com/nextcloud/talk-android/issues/257 https://github.com/nextcloud/android/issues/8684
https://github.com/nextcloud/notifications/issues/1054 mentioned https://github.com/nextcloud/notify_push as a solution, however, it doesn't solve the problem of receiving notifications when either the web app is not open, or on Android without a persistent connection.
Would you be interested in receiving a PR for such a feature?
@maintainers: I'm currently implementing UnifiedPush support to the notification backend / this app to then enable the Android app to use it.
I have a technical question regarding the database handling (as I target for the implementation to be merged into master): Should I try to reuse the current table notifications_pushhash table to store the UP information (distributor URI) or can I create a separate table to handle that data?
The second way seems cleaner to me but I can think of some reasons to re-use the current existing table (e.g. so one app cannot register for both normal & unified push), hence the question.
If the current table structure works it would be totally fine too reuse it. If you need more or different columns to store different data you could use a different one. The proxy column can be the distributor uri, that's exactly how we do it as well.
so one app cannot register for both normal & unified push
I guess this is very unlikely to happen or to be needed.
But i leave this up to you
For context, Right now, nextcloud-specific columns are: 1 - id 2 - uid 3 - token 4 - deviceidentifier 9 - apptype
push-v2 specific columns are: 5 - devicepublickey 6 - devicepublickeyhash 7 - pushtokenhash 8 - proxyserver
WebPush only needs
Public Key = 5 Auth Token ~= 7 endpoint = 8 And a way to identify it is WebPush not push-v2.
Is the UnifiedPush then hosted by the Nextcloud Server operator, the mobile app developer or the end user?
Usually by none of those groups, although some people self-host. Take ntfy.sh for example, someone runs it and anyone can use it, but you can also choose to host your own ntfy server. Also there is no "the Unified Push", it's just a set of standards and protocols and can be implemented independently of any other component of the whole push system. See the animated chart at https://unifiedpush.org
There is also https://apps.nextcloud.com/apps/uppush which can serve as a provider if the users chooses so. Once Nextcloud has native WebPush support it will be possible to completely self-host notifications without any 3rd party in between, because everything is done using Nextcloud.
Okay, the auth token is enough to verify that someone is allowed to push to something? There is no additional origin confirmation of any sorts? Just thinking about potential abuse scenarios which we would like to prevent.
Yes, I think the biggest problem will be SSRF because the server will have push to any endpoint the device registers with.
Btw another cool feature that could be implemented after having WebPush would be push notifications for browsers even when all the tabs are closed :)
There is no additional origin confirmation of any sorts?
In WebPush (RFC8030, from which UnifiedPush derives key principles), the endpoint, the URL the notifications are pushed to is a capability URL. The endpoint might be https://ntfy.sh/upRANDOM98765432?up=1. That URL serves as a password for who is allowed to push to a UnifiedPush/WebPush endpoint.
The public key and auth token are separate, defined by RFC8291 for encryption of the payload.
TL;DR RFC8030 or the UnifiedPush spec is for sending stuff, RFC8291 is for encrypting that stuff
In addition, if you want to push to Chrome (neither UnifiedPush nor Firefox require this), you need VAPID (RFC8292), but that is a per-server key not per-user, so it's trivial to add on after the fact.
Sorry, I'm currently a little bit overwhelmed by life stuff (especially my studies).
But to the progress: I've mostly worked on rewriting the current code to easily support multiple notifications as the current implementation is heavily specialized for routing notifications through Nextcloud's Push Proxy for GCM/APNS (e.g. by batching notifications, triming content, …). That should/may be finished after an additonal 6 to 8 hours of work, I plan to then publish a PR for this refactoring.
Implementing UnifiedPush on this refactored code is then plain simple and nearly already done.
That should/may be finished after an additonal 6 to 8 hours of work, I plan to then publish a PR for this refactoring.
This sounds great, much more sophisticated than my proof of concept over at: https://github.com/githubkoma/webpush
@githubkoma Probably it is as it should enable UP notifications for all Nextcloud notifications. However, your work & expertise might come in handy as I've no idea on how WebPush works. I hope I find time this week to at least publish my current progress so you (or anyone else) could start on implementing WebPush on top of that
Sorry to bother you all.
Are there any updates on this？ Many people really want to get notification via PWA.
