WebPush support

[karmanyaahm]

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:

1. Create a v3 API endpoint to register devices with WebPush style keys
2. Change the encrypt function to handle the WebPush keys in case the device is v3
3. 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 nextcloud/talk-android#257 nextcloud/android#8684

#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?

[samuraikid0]

Implement it

https://unifiedpush.org/developers/android/

[Zocker1999NET]

@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.

[nickvergessen]

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

[karmanyaahm]

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.

[nickvergessen]

Is the UnifiedPush then hosted by the Nextcloud Server operator, the mobile app developer or the end user?

[provokateurin]

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

[provokateurin]

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.

[nickvergessen]

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.

[provokateurin]

Yes, I think the biggest problem will be SSRF because the server will have push to any endpoint the device registers with.

[provokateurin]

Btw another cool feature that could be implemented after having WebPush would be push notifications for browsers even when all the tabs are closed :)

[karmanyaahm]

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

[karmanyaahm]

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.

[provokateurin]

@Zocker1999NET any progress on your implementation?

[Zocker1999NET]

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.