3 ms·

There is https://bubu1.eu/openpush/ https://bubu1.eu/openpush/ but I am not sure what the current status is.

kevincox 6y ago
I've seen it but it seems to be mostly idle. And they are defining a new server-to-server API instead of using Web Push which seems like unnecessary duplicated work and requires new server-side client libraries and server implementations. Furthermore they don't support e2e encryption yet.
- Hitton 6y ago
  Aren't web push notifications ineffective (especially battery-wise) compared to google's?
  - kevincox 6y ago
    No. Web Push Notifications are basically a protocol. They define three main things 1. A JavaScript API for retrieving a notification endpoint and configuration 2. A JavaScript API for receiving notifications 3. An HTTP API for sending notifications. Notably absent is a method for connecting that HTTP API to the JavaScript receiver. This is independent of the Web Push protocol and how it is implemented will affect the performance. For example Chrome on Android will use Google's regular push infrastructure (or at least a wrapper around it) and will have the same performance. You could implement this part via polling but the performance will be terrible. So to make a replacement for Google's push system on Android you would need to rewrite 1 and 2 (possibly just translating the JavaScript browser API to Java) and you would need a push server implementation as well as a client to run on the phone. This client is where you take care. But as long as you run one client per device it should perform similarly to Google's solution. The main problem would be if every app ran their own client, but that isn't what is expected. The phone should provide the push server information to the app (which hands it over to the server) so that all apps on the device use the same server. Sure, you are still implementing a lot, but the thing is that websites and services already have ways to store these push endpoints in the DB as well as encrypting the messages and sending them. It would be a lot less work to get them to do a little client-side work so that they app uses the same codepath as their webapp than making changes to their whole stack to support a new protocol.
    - Hitton 6y ago
      Thanks for detailed explanation. It's much clearer to me now.

I've seen it but it seems to be mostly idle. And they are defining a new server-to-server API instead of using Web Push which seems like unnecessary duplicated work and requires new server-side client libraries and server implementations. Furthermore they don't support e2e encryption yet.

Hitton 6y ago
Aren't web push notifications ineffective (especially battery-wise) compared to google's?
- kevincox 6y ago
  No. Web Push Notifications are basically a protocol. They define three main things 1. A JavaScript API for retrieving a notification endpoint and configuration 2. A JavaScript API for receiving notifications 3. An HTTP API for sending notifications. Notably absent is a method for connecting that HTTP API to the JavaScript receiver. This is independent of the Web Push protocol and how it is implemented will affect the performance. For example Chrome on Android will use Google's regular push infrastructure (or at least a wrapper around it) and will have the same performance. You could implement this part via polling but the performance will be terrible. So to make a replacement for Google's push system on Android you would need to rewrite 1 and 2 (possibly just translating the JavaScript browser API to Java) and you would need a push server implementation as well as a client to run on the phone. This client is where you take care. But as long as you run one client per device it should perform similarly to Google's solution. The main problem would be if every app ran their own client, but that isn't what is expected. The phone should provide the push server information to the app (which hands it over to the server) so that all apps on the device use the same server. Sure, you are still implementing a lot, but the thing is that websites and services already have ways to store these push endpoints in the DB as well as encrypting the messages and sending them. It would be a lot less work to get them to do a little client-side work so that they app uses the same codepath as their webapp than making changes to their whole stack to support a new protocol.
  - Hitton 6y ago
    Thanks for detailed explanation. It's much clearer to me now.