Notifications using Javascript Notification API

[hilariocoelho]

Description

Current Gitea's notification system is kinda useless in my opinion. I get a lot of spam of notifications (new issues, closed issues, new issues comments, merged PRs (in a micro service project this becomes an huge spam of notifications), etc). When I actually see my notifications, there are usually dozens of them so I just click to mark them all as seen without actually seeing them.

Gitea should use Notifications API so I can see System Notifications while I use my IDE or something.

Gitea should also support the user to setup which events he wants to get notifications from on the settings page, ie I want to get notifictions only for new issues, comments on issues and comments on PRs.

Maybe gitea should use something like Onesignal so it can send push notifications even if the user doesn't have any gitea's tab opened.

This issue is an improvement of #9327

[hilariocoelho]

I think this is also an improvement of #10198 @6543

[jamesorlakin]

Remember a big goal of Gitea is being self-hosted, so using external options like Onesignal causes a form of vendor lock-in and a dependency on a user setting this service up correctly.

The Web Push API exists for this purpose, where the browser vendor gives you a URL to post messages to. This will mean Gitea needs to keep a track of these URLs when a user has opted in and post notifications to it as they are generated. The service worker can receive these and use the normal notifications API you linked above. This avoids the need to poll for messages and should work when a tab isn't open. I have questions over how we would know to remove older entries over time however. This guide proves quite useful in giving an overview.

We would also need to come up with a 'notification reason', if that doesn't exist already. "Why am I being notified by this PR?": x commented 4 hours ago...

[hilariocoelho]

Didn't know about the Web Push API! Thanks for the information!

I did some more research and found another good article that explains better the Subscription ID and the server side integration here. There is also an easy to use Golang library called webpush-go.

PS: I totally agree with you @jamesorlakin about the 3rd party dependencies.

[silverwind]

Agree, Notifications should be more configurable e.g. more than just watch/unwatch.

I don't think Push/Web Notifications are desirable. These APIs are finicky and they would likely need web sockets which can be hard to configure and they can also be a source of security issues.

[mohe2015]

I don't think they need websockets. As far as I know you simply send the subscription json to the server using a POST request and it can then use it to send push messages to you. See e.g. https://developers.google.com/web/fundamentals/push-notifications

[jamesorlakin]

I would disagree - push notifications would potentially supplant notifications by webhook in some way. In our team we have a Slack channel dedicated for notifications from Gitea and Drone. These are a mix of projects and therefore there's a lot of 'noise'. Since Slack doesn't have custom notifications for channels it often gets muted and then new PRs, etc aren't necessarily picked up by people.

Having a push notification from the browser direct would negate the need for an external system for this workflow. No websockets needed! We already have a service worker too. The APIs don't seem great no, but it's definitely doable I think.

I might have a play over the weekend. 😃

[jamesorlakin]

Update: I've had a bit of a play and am actually making some progress :tada:

The big bit of what's left to do is storing the web subscriptions in a database (and therefore making the model, tiny API, etc). Also localisation and linking direct to the comment would be nice.

As for giving more context to the notification I'm not too sure - This is a separate issue and PR I feel, as overhauling notifications is a big task in its own right. I can see some similarities in logic to activities and webhooks a little though.

[jamesorlakin]

I'm also considering the possible future enhancements having a live server to client push technology will bring. By getting the service worker to trigger events on open webpages we could:

• Automatically increment the bell icon
• On open issues and PRs, pop a message up saying there's new content.

[hilariocoelho]

It is looking good! 🙂

Are you using Notifications API? Is that creating system notifications or is it a custom notification box?

[jamesorlakin]

It's a mixture of the Web Push API to get JSON messages to the service worker in the background and then the normal Notfications API to display it. It's the default look for Firefox - I don't think there's much customisability though.

[6543]

do #10961 close this?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

[catdevnull]

No, this is not fixed by #10961 as it doesn't do webpush notifications. #10884 does.

[karmanyaahm]

Hi, If I were to submit a PR implementing just the backend/API part of this, would it be accepted?

Setting up the backend would let Android apps such as GitNex receive WebPush notifications using the UnifiedPush standard (they're compatible) (https://codeberg.org/gitnex/GitNex/issues/1086). Additionally, someone who is better at JS than me could implement browser notifications in the future.

This was originally suggested by @6543 in https://github.com/UnifiedPush/wishlist/issues/23