server
server copied to clipboard
Webpush API for offline notifications?
Hi, I'm searching for a (self hosted) webpush server, which can send offline notifications to browsers via existing vendor push server with a simple rest api.
Looks like gotify works only with websocket, but misses a offline notification to Chrome (for Android), Firefox, Edge.
There is a go lib maybe could Help to integrate webpush with service-worker client side?
The gotify android app should send messages that were received while the device was offline. I don't know yet if I want to support web push in gotify, I'll have to do some research on that topic.
I have seen a few apps that are starting to use Web Push notifications. Until recently it was not being used much at all.
Back after some time, because could be interesting to have a self hosted push service for desktop browser and mobiles...
Webpush api uses the vender push server (Firefox -> Mozilla, Chrome -> Google, ...) and could be a nice feature to use without the need of a client side app? I know you try to avoid third party services, but optional it would be "ok" for users anyway use vender browsers?
Gotify need to
- push notifications als with closed browser / app
- deliver notifications delayed if the client is offline during the notification is send / triggered
Any news on web push? I would like push notifications integrated for a website with browser notifications. Is this possible?
I've have made some tests with Gotify. It's working, but I dont know if this is a bug or limitiations on who Websockets work but... Gotify is not able to send images in the notification, the image is viewable when you open the notification but it does not show up when viewing it as a notification.
It might be possible to use push notifications without the Webpush API by self-implementing such a mechanism. You could still use service workers to display notification, while the UI is closed. Instead of pushing messages to the service worker via a vendor push server, Gotify itself can push them to the service worker.
This way no third party servers are required. We just need to implement a listener for new messages in a service worker.
I may take a look into this.
Wouldn't this also solve the issue with iOS? If you create a shortcut on your home screen you could then receive push notifications on iPhones and iPads, if I'm not mistaken
I was going to open a new issue about VAPID support and i found this one. I think the service worker route is quite more complex and is not the most efficient because you have to establish and keep a new connection from the device to the server and you have to manage the entire codebase. Some time ago I used this library github.com/SherClockHolmes/webpush-go to send VAPID notificatoins from a go backend to a react webapp.
VAPID specs doesn't require any API key for the vendor server and, as far as i know, the message on their server is keept encrypted. Anywais the message can be only a "wake up call" for the web ui to start the usual websocket.
I don't know if vapid was evaluated before and excluded for some reason.