Live data from Hacker News

Gotify – a self-hosted push-notifications service

github.com

31–40 of 100 posts

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

#31

Funny, I was just looking for an alternative to pushover that doesn't use google services last week. Tested this and it worked quite well. I actually wound up just using an SMS gateway provider with a simple API you can just fire a get request to.

Sending a text message uses the GET verb? Yuck.

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.

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

#33
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?

You need a way to tell the mobile device that a new message has been received. Since you don't have a fixed IP or anything there is no way to directly send the message.

An alternative is that the mobile device pulls from time to time, but that's quite power intensive or, when using a long interval, is slow.

Instead one has an idle connection open to which the server can send messages.

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

#35

Funny, I was just looking for an alternative to pushover that doesn't use google services last week. Tested this and it worked quite well. I actually wound up just using an SMS gateway provider with a simple API you can just fire a get request to.

Sending a text message uses the GET verb? Yuck.

[deleted]

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

#36
post #31

Earlier quoted context omitted.

Sending a text message uses the GET verb? Yuck.

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.

In this case maybe, but generally GET should be avoided for any creative/transactional action because many systems will replay/cache GET requests, assuming that they’re idempotent.

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

#37
post #31

Earlier quoted context omitted.

Sending a text message uses the GET verb? Yuck.

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).

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

#39

Useless without iOS support. What’s the point of an abstraction that has only a single implementation?

I'm not sure, but I don't think iOS lets apps auto-start and run in the background forever. This would be needed for any alternative push notification app, else it would be too easy to miss notifications.

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

#40

Useless without iOS support. What’s the point of an abstraction that has only a single implementation?

I'm not sure, but I don't think iOS lets apps auto-start and run in the background forever. This would be needed for any alternative push notification app, else it would be too easy to miss notifications.

As stated previously: this is useless.

What is the point of building alternative push notification services that can’t even properly rise above the bar of technical feasibility?

Post reply on HN