Live data from Hacker News

Gotify – a self-hosted push-notifications service

github.com

81–90 of 100 posts

Re: Gotify – a self-hosted push-notifications service

#81
post #75

I would like to point out that there exists solutions tested in the field in the last 20 years to solve the same problem. In particular I would suggest to get to know MQTT an open protocol with several (open and close) implementation that is know for its flexibility and scalability (if nothing has changed it is used to power the Messager Facebook platform, but don't quote me on that). verneMQ is the server implementa…

MQTT is just a protocol, not a service. I don't think it was the developer's intention to provide an alternative to MQTT, but to offer a solution for push-notifications, which just happens to be built on top of WebSocket without MQTT. Also keep in mind that MQTT will usually get wrapped by WebSocket to avoid issues with firewalls or to easily get TLS via a proxy server like NGINX, or simply to add web browser support. VerneMQ is not the only server implementation for MQTT.

Re: Gotify – a self-hosted push-notifications service

#82
post #58

FCM is integrated in kernel, so it cannot be killed. And it starts a persistent TCP connection to Google server. If all apps uses FCM, then all notification would route through this connection, and this significantly reduce battery consumption than the alternative, where each app uses its own web socket server. So, assume using a degoogled android, can this notification replaced FCM if more apps use this notification…

FCM uses XMPP

https://firebase.google.com/docs/cloud-messaging/xmpp-server...

I really like the idea of Google providing a single, efficient connection for push-notifications, but having it bundled with Firebase (and therefore with Google Play Services) is an unfriendly approach.

Re: Gotify – a self-hosted push-notifications service

#83
post #81
post #75

I would like to point out that there exists solutions tested in the field in the last 20 years to solve the same problem. In particular I would suggest to get to know MQTT an open protocol with several (open and close) implementation that is know for its flexibility and scalability (if nothing has changed it is used to power the Messager Facebook platform, but don't quote me on that). verneMQ is the server implementa…

MQTT is just a protocol, not a service. I don't think it was the developer's intention to provide an alternative to MQTT, but to offer a solution for push-notifications, which just happens to be built on top of WebSocket without MQTT. Also keep in mind that MQTT will usually get wrapped by WebSocket to avoid issues with firewalls or to easily get TLS via a proxy server like NGINX, or simply to add web browser support…

Really, what your comments add to the discussion?

You just re-phrased everything I said in a more negative tone with zero value added.

I said myself that MQTT is a protocol and again I said that verneMQ is an implementation of the broker, the one that I suggest but not the only one.

And yes, it was a choice to leave aside the implementation detail of the use of websockets for MQTT because is a different level of abstraction.

Please let's try to add value to the community and not just add noise and entropy.

Before to comment I asked myself.

1) does this need to be said? And since people where finding this project interesting I decided that yes, the same people could be interested in knowing another more mature ecosystem that target a similar niche.

2) does this need to be said by me? And again, yes, none mentioned it already, the post was up for a while and I do have production experience with MQTT.

Please try to follow the same guidelines!

Re: Gotify – a self-hosted push-notifications service

#84
post #82
post #58

FCM is integrated in kernel, so it cannot be killed. And it starts a persistent TCP connection to Google server. If all apps uses FCM, then all notification would route through this connection, and this significantly reduce battery consumption than the alternative, where each app uses its own web socket server. So, assume using a degoogled android, can this notification replaced FCM if more apps use this notification…

FCM uses XMPP https://firebase.google.com/docs/cloud-messaging/xmpp-server... I really like the idea of Google providing a single, efficient connection for push-notifications, but having it bundled with Firebase (and therefore with Google Play Services) is an unfriendly approach.

XMPP is only one option for communicating with the FCM server. The most popular method is using HTTP/REST. XMPP is only needed when you have bidirectional messages - server to client app (downstream) and client app to server (upstream).

Re: Gotify – a self-hosted push-notifications service

#85
post #9

Earlier quoted context omitted.

From what I can tell it appears to be a replacement FCM/APNS. The client subscribes directly via websocket to a self-hosted server (Go binary). New messages in the queue are then notified (gotified) via the websocket. https://gotify.net/api-docs#/message/streamMessages The payload can be picked up and managed via REST API as well. I'm building a similar solution for a slightly different usecase, so wanted to have a l…

Thanks for clarifying. This could be a good solution for a non Google play type phone, or just someone who doesnt want t rely on Google servers. It would just mean in the latter case there would always be 2 open connections listening for messages...

Those open connections would be very hard to keep open indefinitely in an Android app that gets optimized or goes into sleep / doze mode.

Re: Gotify – a self-hosted push-notifications service

#86
post #23

I'm not up to date with Android, but why does displaying notifications require an entire server or a paid service? Is it not just a matter of installing a client program and sending a curl to an endpoint?

Google's solution - Firebase Cloud Messaging is for the most part free and fairly easy to setup. Yes you can use curl to call their HTTP/REST endpoint to send a notification I believe.

If you get to the stage of sending millions of notifications per day then you'll need to start paying,

Re: Gotify – a self-hosted push-notifications service

#87
post #83
post #81

Earlier quoted context omitted.

MQTT is just a protocol, not a service. I don't think it was the developer's intention to provide an alternative to MQTT, but to offer a solution for push-notifications, which just happens to be built on top of WebSocket without MQTT. Also keep in mind that MQTT will usually get wrapped by WebSocket to avoid issues with firewalls or to easily get TLS via a proxy server like NGINX, or simply to add web browser support…

Really, what your comments add to the discussion? You just re-phrased everything I said in a more negative tone with zero value added. I said myself that MQTT is a protocol and again I said that verneMQ is an implementation of the broker, the one that I suggest but not the only one. And yes, it was a choice to leave aside the implementation detail of the use of websockets for MQTT because is a different level of abst…

Blah bleh bluh

Re: Gotify – a self-hosted push-notifications service

#88
post #55

Earlier quoted context omitted.

I had exactly the same problem, and ended up using Signal. I like it more than normal push notifications because you can reply and have a full chatbot running. I liked it so much that I even wrote a small Python library for it: https://gitlab.com/stavros/pysignald/

That's pretty neat, but could you add an Open Source license to it? It's gonna make folks hesitant to use it.

Thanks for reminding me, I forgot to add the file. The license is actually MIT, as you can see on the PyPI page (https://pypi.org/project/pysignald/).

Re: Gotify – a self-hosted push-notifications service

#89
post #37
post #31

Earlier quoted context omitted.

I get why that's "yuck" but if I'd hedge a bet...it's probably done because it's easier to make a GET than it is a POST or PUT request and the length of a text message will never exceed the query string uri length limits. Not saying I disagree, but i don't know it changes a whole lot in this case.

just to point out: there are no uri length limits. browsers typically have one (I haven't checked lately tho), but other tools generally don't (except by mistake / size-capped buffers).

Not sure why you believe this so strongly, but every single HTTP client impose some limit.

Modern browsers are typically around 100-200k limit, command line tools such as curl and wget also has their limits.

IE was famously limiting GET requests to about 2k bytes.

Re: Gotify – a self-hosted push-notifications service

#90

I like the idea of the project, but I'm curious. Why would you need a self-hosted (or really, any other push-notif service) other than the official one from Apple/Goggle? They're optimized (for each respective platform), no need to maintain a server, and free. If you need "cross-platform", you can use Firebase(?) that abstracts that away.

Is it true that GCM is centralized and battery efficient, one push service per app will drain phones quickly? Or is that less of a concern nowadays?

It's still a concern and this service will increase battery drain - this is why all the users of apps using this service will have to explicitly exclude the apps from battery optimizations.

I don't see Google Play allowing these kind of apps in massive numbers though - applications abusing background processing to poll for messages were one of the main reasons why Android got blamed for being worse than iOS in standby battery consumption. Warranted or not, Google/Android gets blamed for abuse of power saving at the end.

Post reply on HN