mirror of
https://github.com/axllent/mailpit.git
synced 2026-04-26 08:45:54 +03:00
[GH-ISSUE #113] Support push notifications #77
Labels
No labels
awaiting feedback
bug
docker
documentation
enhancement
github_actions
invalid
pull-request
question
stale
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/mailpit#77
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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 :)
@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)?
@jonaskuske commented on GitHub (May 22, 2023):
Not closely related, #112 has value even without push functionality.
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
@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:
Thanks!
@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:
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 likehttps://firebase-cloud-messaging.com/sOmE-r4nd0m-IDin 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
pushevent, so the notification is shown.webpush-gooffersGenerateVAPIDKeysandSendNotificationfunctions that can be used for the server portion.@jonaskuske commented on GitHub (May 23, 2023):
Yes, though we could keep a
[x] Disable Web Pushoption for use in offline scenarios, as push notifications require network connectivity whilenew Notification()from an opened page doesn't. Not sure how common/important use of mailpit in environments without internet access is.@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.
@github-actions[bot] commented on GitHub (Jun 27, 2023):
This issue is stale because it has been open for 21 days with no activity.
@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.