WIP: HTML5 Push Notifications

[jamesorlakin]

Edit: This PR is currently being rewritten. I'll force push it when I'm done but feel free to see my pushNotificationsNew branch in the meantime.

---

Fixes #10804, #9327.

This is a 'mostly there but unpolished' PR to implement push notifications using the Web Push and Notification API, powered by the webpush-go library. I feel this is a very useful piece of functionality to be productive, especially if emails aren't configured.

---

To give an overview:

1. Web Push servers need VAPID keys, a Base64'd asymmetric keypair. Gitea will generate a keypair on startup and add to app.ini if not set - similar to JWT secrets.
2. The user pushes a button to opt-in to notifications.
3. The JS requests the notification permission from the user. This permission also grants access to the service worker's PushManager to enable Web Push. For Firefox at least it needs to be triggered by a user event to reduce spam.
4. If granted, the JS subscribes the service worker for Web Push using the VAPID public key embedded in the JS config object. This will then return a URL, auth token, and a signing key from the browser's vendor. (Further requests to subscribe will return the same details) Currently this includes Chrome, Firefox, and Edge. Safari has its own proprietary system I haven't looked into.
5. The URL, auth token, and signing key are POSTed to Gitea under a new endpoint. The endpoint will send a test notification in order to verify the provided details before storing it against the user in the Web Push subscription table.
6. Done! 🎉

Whenever a notification model is created or updated we send a push notification:

1. Fetch all the subscribed pushes for a user.
2. Loop through each one and send a JSON object containing a message about the issue/PR and a URL.
3. If the HTTP code isn't 201 (created), delete the subscription. Under the spec 410 (gone) is sent for expired subscriptions but I think there's other codes if the auth/signing is wrong, etc. (Edit: This is a bit dumb in retrospect. We should ignore 5xx errors as they shouldn't be our fault and are likely temporary.)
4. The service worker receives the JSON object and uses the Notification API to show a corresponding notification.

---

As a result the service worker is required to be enabled - it's quite key! Having this lays the foundation for live messaging outside of notifications later on: updating the bell icon, informing the user of new activity while viewing a PR, etc.

This is WIP because I have some things outstanding/discussing:

• Decouple the sending of pushes from the actual web request that triggered it. Would a simple goroutine be sufficient? Let's say a push service took 10s... ouch!
• Refactor web push to be a module using the notification service entrypoint, rather than hijacking events on the notification model
• Figure out the Notifier queue system and use that instead of hijacking the notification model
• Localisation. I can do most of the server-side bits but not sure about the JS button. It won't show until it passes feature discovery. I guess I should put it in the template and add all required localised messages as custom attributes.
• Add the repo name to the notification - oops!
• Only remove subscription when encountering a 4xx error.
• Rename .ini config names
• More error handling on the JS side
• Figure out a nicer/more obvious UI to opt-in.
• Allow the user to opt-out
• Testing?!

And as always, even minor nits are welcome! A lot of the logic is in the models, but I need it to automatically delete old hooks and react to notifications. It was a module but I caused an import cycle... 🤦‍♂

---

[hilariocoelho]

Wow! 👏
@6543 @zeripath come have a look at this!

[6543]

Can you resolve the conflict - Ill look at it afterwards :)

[silverwind]

Don't piggy-back on the service-worker pref, these are two distinct features. Add a new one, like USE_PUSH_NOTIFICATIONS.

[jamesorlakin]

True - I'll pop a note saying the service worker is required as well.

[silverwind]

PUSH_NOTIFICATIONS_PUBLIC_KEY and PUSH_NOTIFICATIONS_PRIVATE_KEY would be more better imho.

[jamesorlakin]

In the codebase I've tried to be consistent with 'Web Push', but I could change the user-facing config quite easily

[jamesorlakin]

Go's modules confuse me a fair bit!

So CI is failing because my machine adds go 1.13 to the vendored package's go.mod and CI seemingly doesn't:

I'm using Go 1.14.1 locally, but if I try and do make vendor with 1.13 the vendored modules.txt goes ...haywire:

I'm using Windows if that makes any difference.

[jamesorlakin]

Cheers, but it's insistent on putting the go 1.13 back into that file even with make fmt && make vendor on Go 1.14.1 for me. 😕

[6543]

Cheers, but it's insistent on putting the go 1.13 back into that file even with make fmt && make vendor on Go 1.14.1 for me.

this could be indeed a windows only issue

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 months. Thank you for your contributions.

[6543]

Pleace resolve conflicts

[silverwind]

Serviceworker implementation has changed significantly since this PR as it's now handled by workbox so this will need quite a few updates. Also I think I'm not generally against adding push notifications but it needs to be integrated with our existing EventSource-based notifications, probably sharing much code with that implementation.

[jamesorlakin]

Hi all,

Yep, this one certainly needs updating! I was testing the water with how push notification implementations work for sure. It's been a while since I've had time to dig through Gitea's codebase but I'll try and block some time this weekend to have a play.

I might restart this from the latest commit from master. I haven't really touched Workbox before, but I'm guessing I'll be able to add push events handlers to the generated serviceworker? I discovered very late on about the queue-based event system so I'd be keen to try and utilise that as well.

This might take quite a while in the grand scheme of things, and we'd have to accept it wouldn't work (or do we try to fallback to AJAX as in #10961?) in IE or Safari.

Thanks.

[6543]

@jamesorlakin IE support was droped in v1.13

[jamesorlakin]

Even better 👍

[silverwind]

I imagine the new implementation can re-use the EventSource to add a new notification event and then push that to the serviceworker for display. These parts don't depend on workbox, but they do have this example which includes push notifications. Also, I wonder if desktop browsers would need a fallback to the older web notifications API.

[mohe2015]

@silverwind

Also, I wonder if desktop browsers would need a fallback to the older web notifications API.

I'm pretty sure they don't as I have implemented push notifications for desktop and mobile a while ago using the standard APIs.

Edit: https://caniuse.com/#feat=push-api also shows support for desktop browsers.
Edit-Edit: Safari seems to not support the Push API but only the Web Notifications API so we would need to discuss whether we want to support that feature for this browser too.

[silverwind]

I guess fallback to web notification is a requirement because there are scenarios where serviceworker will be disabled (either by configuration or when the user is in private browsing mode (which may disable serviceworker in some circumstances)). Maybe there is a third-party module that can handle such a fallback.

[mohe2015]

@silverwind

I guess fallback to web notification is a requirement because there are scenarios where serviceworker will be disabled

There is still the default notification system (email, just the bell in the top right of the web interface)
Of course people may still want notifications but when using Web Notifications they need to keep the tab open and you would need to poll or use something like websockets to get updates.

(either by configuration

I think then a fallback is not intended either (or do you mean disabled in the browser?)

or when the user is in private browsing mode (which may disable serviceworker in some circumstances)).

I think then you can't even enable the push notifications and I don't think this is the way most people who want push notifications use their browser.

Maybe there is a third-party module that can handle such a fallback.

Unfortunately I don't think so as the technology is quite different (Web Notifications is just showing a Notification and Push Notification is also getting updates to the browser)

So in my personal opinion I would see Push Notifications as a progressive enhancement so I don't think a fallback is required. This would also simplify the implementation.

[silverwind]

you would need to poll or use something like websockets to get updates.

We do have SSE/Eventsource implemented for server-side push things. Currently it's only used to update the notification count. We probably will want to switch this to websockets because SSE has some quirks and limitations.

What I mean is that web notifications would still be possible even without a service worker available while push notifications require it, but I guess we don't need to handle it as it would complicate the implementation (e.g. need to handle multiple tabs racing to push the same notification etc).

[jamesorlakin]

We do have SSE/Eventsource implemented for server-side push things.

Correct me if I'm wrong here, but I thought that was handled by an AJAX timer?

I think for now we should stick to feature discovery (does the browser support SWs, push, etc) and only show the option if the service worker is enabled in the config. Still showing notifications outside of Web Push is a nice idea, but we need to make it clear this fallback mode would not provide notifications if no Gitea tab is open.

[silverwind]

See https://github.com/go-gitea/gitea/blob/master/web_src/js/features/notification.js#L30, it's using EventSource and falls back to ajax, at least that's the plan.

I think for now we should stick to feature discovery (does the browser support SWs, push, etc) and only show the option if the service worker is enabled in the config

I would make a second option and only enable push notifications if both are enabled, that way one can still benefit from SW caching while keeping notifications off if desired.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 months. Thank you for your contributions.

[stale]

This pull request has been automatically closed because of inactivity. You can re-open it if needed.

[catdevnull]

Is this ever gonna land? :#

[jamesorlakin]

Afraid it's unlikely from me - apologies to everyone for leaving this in an unfinished state.
Circumstances have changed such that I'm unfortunately no longer an active Gitea user (instead being stuck with an old Bitbucket instance 😢) and thus won't have the time or motivation to really continue with changes.

I absolutely adore all the effort put into this project and wish for it to thrive for years to come. For anybody looking to take this on feel free to copy any of the code thus far as your own. If there's any questions or a later PR feel free to tag me if you'd like. Cheers!