Gitea: Notifications using Javascript Notification API

Created on 23 Mar 2020 · 12Comments · Source: go-gitea/gitea

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

kinenhancement revieweconfirmed

Source

SpaWn2KiLl

👍2 🚀1

Most helpful comment

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.

Gitea notifications

jamesorlakin on 29 Mar 2020

❤2 👍1

All 12 comments

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

SpaWn2KiLl on 23 Mar 2020

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

jamesorlakin on 23 Mar 2020

👍3

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.

SpaWn2KiLl on 23 Mar 2020

👍2

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.

silverwind on 25 Mar 2020

👎2 😕1

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

mohe2015 on 25 Mar 2020

👍1

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 on 25 Mar 2020

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.

Gitea notifications

jamesorlakin on 29 Mar 2020

❤2 👍1

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.

jamesorlakin on 29 Mar 2020

👍1

It is looking good! 🙂

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

SpaWn2KiLl on 29 Mar 2020

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.

jamesorlakin on 29 Mar 2020

do #10961 close this?

6543 on 27 Apr 2020

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.