Logo reminds me of traefik. Is it related ?
That's the Go Gopher: https://blog.golang.org/gopher
Gotify – a self-hosted push-notifications service
11–20 of 100 posts
Re: Gotify – a self-hosted push-notifications service
#12It is worth noting that this will use a noticeable amount of power more than Google cloud messaging. The basic idea of how is works is about the same, but the devil is in the details. If you look at an idle connection over LTE, you will notice that after a while your carrier will close it. You need keepalives. If you look at the connection for Google cloud messaging, you might notice that it needs much fewer keep ali…
Is that because carriers have put GCM/FCM on some sort of white-list?
Re: Gotify – a self-hosted push-notifications service
#13Logo reminds me of traefik. Is it related ?
I cannot tell is this is a sarcasm.
It’s the go gopher... gophing about.
Re: Gotify – a self-hosted push-notifications service
#14Neat. I could definitely use this for some home infrastructure I'm playing around with at the moment - will definitely give it a shot!
Re: Gotify – a self-hosted push-notifications service
#15It is worth noting that this will use a noticeable amount of power more than Google cloud messaging. The basic idea of how is works is about the same, but the devil is in the details. If you look at an idle connection over LTE, you will notice that after a while your carrier will close it. You need keepalives. If you look at the connection for Google cloud messaging, you might notice that it needs much fewer keep ali…
Is that because carriers have put GCM/FCM on some sort of white-list?
Probably because GCM/FCM has been very well optimized.
Re: Gotify – a self-hosted push-notifications service
#16Bah... no linux 32 bit binary for my old home-automation server.
Re: Gotify – a self-hosted push-notifications service
#17It is worth noting that this will use a noticeable amount of power more than Google cloud messaging. The basic idea of how is works is about the same, but the devil is in the details. If you look at an idle connection over LTE, you will notice that after a while your carrier will close it. You need keepalives. If you look at the connection for Google cloud messaging, you might notice that it needs much fewer keep ali…
Not only that, but for many manufacturers this will straight up either not work after the app has been in the background for some (not long) time, or will deliver (that is, app will be able to connect and receive) push notifications with significant delay. Sadly, most reliable way I know to trigger push notifications when app is closed is using FCM - I'd love hear if there's an alternative, though.
Re: Gotify – a self-hosted push-notifications service
#18The documentation states that End2End tests are included. I didn't find them in the repository. I want to learn from the tests - Can somebody please help me and point me to the End2End tests?
Re: Gotify – a self-hosted push-notifications service
#19Although I've been using Pushover[0], a paid service, instead of Gotify, I found a really cool project to pair a push-notification service with is huginn[1], which allows you to program bots to do things on cron jobs, among other really powerful actions.
[0] https://pushover.net/ [1] https://github.com/huginn/huginn
Re: Gotify – a self-hosted push-notifications service
#20Earlier quoted context omitted.
Is that because carriers have put GCM/FCM on some sort of white-list?
Probably because GCM/FCM has been very well optimized.
While it's likely true, GCM/FCM is handled by Google Play Services, which is whitelisted and has I believe system-level permissions. It has less restrictions than a regular app exempt from battery optimisations, as it's supposed to be the only app that needs to run in order to coordinate things like push messages or location updates across all apps on the device
edit: I missed that the original post was talking about keep-alives and you were probably referring to them. But how app-level optimisations can help with keep-alives?