[GH-ISSUE #113] Support push notifications #77

Closed
opened 2026-03-15 12:25:34 +03:00 by kerem · 8 comments
Owner

Originally created by @jonaskuske on GitHub (May 22, 2023).
Original GitHub issue: https://github.com/axllent/mailpit/issues/113

Would be super cool if mailpit would support push (background) notifications using service workers, so that you don't have to keep it open in a tab in order to check if mailing works.

Would be happy to contribute the feature if you agree to adding this functionality :)

Originally created by @jonaskuske on GitHub (May 22, 2023). Original GitHub issue: https://github.com/axllent/mailpit/issues/113 Would be super cool if mailpit would support push (background) notifications using service workers, so that you don't have to keep it open in a tab in order to check if mailing works. Would be happy to contribute the feature if you agree to adding this functionality :)
kerem 2026-03-15 12:25:34 +03:00
  • closed this issue
  • added the
    stale
    label
Author
Owner

@axllent commented on GitHub (May 22, 2023):

I believe this relates to your other question #112. I'm interested, but before you start trying to implement anything, could you please provide me a link regarding this type approach, as I thought it was now a redundant browser feature which had long been removed (due to abuse)?

<!-- gh-comment-id:1557869265 --> @axllent commented on GitHub (May 22, 2023): I believe this relates to your other question #112. I'm interested, but before you start trying to implement anything, could you please provide me a link regarding this type approach, as I thought it was now a redundant browser feature which had long been removed (due to abuse)?
Author
Owner

@jonaskuske commented on GitHub (May 22, 2023):

Not closely related, #112 has value even without push functionality.

as I thought it was now a redundant browser feature which had long been removed (due to abuse)

No, it's very much alive! Browser vendors did a lot of work on the permissions model, prompt UI and heuristics to discover spam over the last years so the API is less prone to abuse. In fact, Apple shipped support for the Web Push API to desktop Safari last year with Safari 16 and to iPhones and iPads two months ago with 16.4. (but only allowed for websites that are added to the homescreen there) Also related APIs like the Badging API to show e.g. the unread count badge on the app icon of a web app.

It's not removed and also not redundant or deprecated. https://developer.mozilla.org/en-US/docs/Web/API/Push_API

<!-- gh-comment-id:1558088929 --> @jonaskuske commented on GitHub (May 22, 2023): Not closely related, #112 has value even without push functionality. > as I thought it was now a redundant browser feature which had long been removed (due to abuse) No, it's very much alive! Browser vendors did a lot of work on the permissions model, prompt UI and heuristics to discover spam over the last years so the API is less prone to abuse. In fact, Apple shipped support for the Web Push API [to desktop Safari last year with Safari 16](https://webkit.org/blog/12945/meet-web-push/) and [to iPhones and iPads two months ago with 16.4](https://webkit.org/blog/13966/webkit-features-in-safari-16-4/). (but only allowed for websites that are added to the homescreen there) Also related APIs like the Badging API to show e.g. the unread count badge on the app icon of a web app. It's not removed and also not redundant or deprecated. https://developer.mozilla.org/en-US/docs/Web/API/Push_API
Author
Owner

@axllent commented on GitHub (May 23, 2023):

Thanks for the info. Unfortunately I don't have enough time at the moment to investigate this properly. I would really appreciate if you could tell me:

  1. What changes would need to happen to allow a browser to connect to Mailpit for push notifications? This would replace the existing browser notifications I assume?
  2. What changes may be needed in Mailpit (HTTPD) in order to communicate with the browser? I assume it's not just a matter of using the existing websocket.

Thanks!

<!-- gh-comment-id:1558504869 --> @axllent commented on GitHub (May 23, 2023): Thanks for the info. Unfortunately I don't have enough time at the moment to investigate this properly. I would really appreciate if you could tell me: 1. What changes would need to happen to allow a browser to connect to Mailpit for push notifications? This would replace the existing browser notifications I assume? 2. What changes may be needed in Mailpit (HTTPD) in order to communicate with the browser? I assume it's not just a matter of using the existing websocket. Thanks!
Author
Owner

@jonaskuske commented on GitHub (May 23, 2023):

Sure! The flow is as follows:

On first server start, create a public/private key pair for use with the Voluntary Application Server Identification for Web Push (VAPID) Protocol. Pass the public key to the frontend, could be a member of appInfo.

On first frontend start, register a service worker (small JS background script that is run for specific events) that listens for push events:

self.addEventListener('push', (data) => {
  self.showNotification(data)
}) 

When a user turns on notifications, call pushManager.subscribe() on the frontend, passing in the public key. This returns a subscription object containing a unique endpoint for the respective browser's messaging service. (e.g. something like https://firebase-cloud-messaging.com/sOmE-r4nd0m-ID in Chrome) Pass the endpoint to the server and store it.

Now when the server receives a new mail, create a JSON object for the notification, sign it with the private key created in step one and send it to the stored endpoint via POST request. Even with the site not opened, this makes the browser run the service worker script and trigger the push event, so the notification is shown.

webpush-go offers GenerateVAPIDKeys and SendNotification functions that can be used for the server portion.

<!-- gh-comment-id:1559222052 --> @jonaskuske commented on GitHub (May 23, 2023): Sure! The flow is as follows: On first server start, create a public/private key pair for use with the Voluntary Application Server Identification for Web Push (VAPID) Protocol. Pass the public key to the frontend, could be a member of `appInfo`. On first frontend start, register a service worker (small JS background script that is run for specific events) that listens for push events: ```js self.addEventListener('push', (data) => { self.showNotification(data) }) ``` When a user turns on notifications, call `pushManager.subscribe()` on the frontend, passing in the public key. This returns a subscription object containing a unique endpoint for the respective browser's messaging service. (e.g. something like `https://firebase-cloud-messaging.com/sOmE-r4nd0m-ID` in Chrome) Pass the endpoint to the server and store it. Now when the server receives a new mail, create a JSON object for the notification, sign it with the private key created in step one and send it to the stored endpoint via POST request. Even with the site not opened, this makes the browser run the service worker script and trigger the `push` event, so the notification is shown. [`webpush-go`](https://github.com/SherClockHolmes/webpush-go) offers `GenerateVAPIDKeys` and `SendNotification` functions that can be used for the server portion.
Author
Owner

@jonaskuske commented on GitHub (May 23, 2023):

This would replace the existing browser notifications I assume?

Yes, though we could keep a [x] Disable Web Push option for use in offline scenarios, as push notifications require network connectivity while new Notification() from an opened page doesn't. Not sure how common/important use of mailpit in environments without internet access is.

<!-- gh-comment-id:1559242469 --> @jonaskuske commented on GitHub (May 23, 2023): > This would replace the existing browser notifications I assume? Yes, though we could keep a `[x] Disable Web Push` option for use in offline scenarios, as push notifications require network connectivity while `new Notification()` from an opened page doesn't. Not sure how common/important use of mailpit in environments without internet access is.
Author
Owner

@axllent commented on GitHub (Jun 5, 2023):

@jonaskuske Sorry to keep you waiting. I currently have a lot on my plate, which is taking preference over me looking further into this. Unfortunately this feature just keeps getting pushed to the back of the queue as it's a nice-to-have, which I believe requires quite a bit of work to implement properly. At this stage all I can say is "not planned", although I'm not saying "no". If you wanted to have a crack at this then I'd be open to a PR, but I'm cautious about this feature becoming more of a hindrance to users who may not want this at all (you're the first to request it). There is a good change that I do not understand the requirements properly, but it comes back to the "I don't have enough time right now to look at this" comment.

<!-- gh-comment-id:1576521182 --> @axllent commented on GitHub (Jun 5, 2023): @jonaskuske Sorry to keep you waiting. I currently have a lot on my plate, which is taking preference over me looking further into this. Unfortunately this feature just keeps getting pushed to the back of the queue as it's a nice-to-have, which I believe requires quite a bit of work to implement properly. At this stage all I can say is "not planned", although I'm not saying "no". If you wanted to have a crack at this then I'd be open to a PR, but I'm cautious about this feature becoming more of a hindrance to users who may not want this at all (you're the first to request it). There is a good change that I do not understand the requirements properly, but it comes back to the "I don't have enough time right now to look at this" comment.
Author
Owner

@github-actions[bot] commented on GitHub (Jun 27, 2023):

This issue is stale because it has been open for 21 days with no activity.

<!-- gh-comment-id:1608649965 --> @github-actions[bot] commented on GitHub (Jun 27, 2023): This issue is stale because it has been open for 21 days with no activity.
Author
Owner

@github-actions[bot] commented on GitHub (Jul 5, 2023):

This issue was closed because it has been inactive for 7 days since being marked as stale.

<!-- gh-comment-id:1620938574 --> @github-actions[bot] commented on GitHub (Jul 5, 2023): This issue was closed because it has been inactive for 7 days since being marked as stale.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/mailpit#77
No description provided.