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.

[githubkoma]

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

[Zocker1999NET]

@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

[sobassy]

Sorry to bother you all.

Are there any updates on this？
Many people really want to get notification via PWA.

[p1gp1g]

@Zocker1999NET Any chance you can you share your work ? It would be useful if someone wants to continue it

[Zocker1999NET]

Sorry that I discontinued my work on this (being another victim of RL coming up with more important stuff ^^)
@p1gp1g I'm not sure how helpful this might still be, as my work is still based of a commit from early 2023, namely 686cb5b.

But if someone wants to take a look, see: https://github.com/Zocker1999NET/nextcloud-notifications/tree/unified-push
I started to rewrite some parts to allow easier support of multiple notification methods by introducing common interfaces and by extracting common code for encryption/signing and so on.

[p1gp1g]

Thank you ! It will be useful if someone wants to continue it.

I think it would be more efficient, at least for the review, to split this PR in 2: The 1st to allow multiple pushers, and the 2nd to add webpush (based on the 1st)

[gavine99]

I have submitted some pull requests that don't change architecture to achieve nextcloud notifications to be sent via the 3rd party unified push app. see;

• Unified push nextcloud notifications server#47763 and Unified push nextcloud notifications #2027

... also a pull request for the 3rd party unified push app that can be applied after the pull requests above are applied; https://codeberg.org/NextPush/uppush/pulls/17

i have also submitted pr's for the generic (f-droid) android nextcloud client and talk apps to use the nextcloud server changes and these changes to create an end-to-end solution for unified push notifications and talk;

• nextcloud mobile client app: Unified push nextcloud notifications android#13516
• nextcloud mobile talk app: Unified push nextcloud notifications talk-android#4146