Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gotify – a self-hosted push-notifications service

github.com

Post reply on HN
Print view View original

91–100 of 100 posts

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

#91

Post by izacus »

npmn2 wrote: post #27
nukeop wrote: 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?

It is not needed for displaying the notification but specifically targeting users. You would usually call an FCM function to get a token, which can be used to specifically target that user and is stored in the database. To send a notification to your customised target audience based on user-generated events, it becomes essential to use web-service that does it for you. For example- Let's say you wish to send a notifi…

Of course FCM also has notion of channels where you can broadcast to certain topics (which apps listen to) without having to track tokens on application server side.

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

#92

Post by there »

noahster11 wrote: post #19

Although 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

Just to clarify, Pushover is not a "paid service" in that you need to pay for a subscription. You only have to pay once to use it past the 7-day free trial.

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

#93

Post by there »

wybiral wrote: post #66
wiradikusuma wrote: post #65

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.

Privacy? Keep in mind that not everyone intends to build a user-supporting platform on this tech. I like the concept because it's an easy way for me to push notifications from my homebrew IoT stuff and news streams without it flowing through ad companies.

You can encrypt notifications that go through Google's FCM and Apple's APNS push notification servers. This is how Pushover works - each notification is encrypted with a device-specific key, sent through the notification servers as an encrypted blob, then the app on the device is woken up and receives the blob, decrypts it, and posts it as a normal notification.

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

#94

Post by wybiral »

there wrote: post #93
wybiral wrote: post #66

Earlier quoted context omitted.

Privacy? Keep in mind that not everyone intends to build a user-supporting platform on this tech. I like the concept because it's an easy way for me to push notifications from my homebrew IoT stuff and news streams without it flowing through ad companies.

You can encrypt notifications that go through Google's FCM and Apple's APNS push notification servers. This is how Pushover works - each notification is encrypted with a device-specific key, sent through the notification servers as an encrypted blob, then the app on the device is woken up and receives the blob, decrypts it, and posts it as a normal notification.

You could. But if you don't need that kind of added complexity and scale (and I don't for personal news updates or IoT device alerts) then why jump through those hoops?

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

#95

Post by Groxx »

asddgsgsaxg wrote: post #89
Groxx wrote: post #37

Earlier quoted context omitted.

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.

the spec does not define a limit, and the widely varying implementation-specific limits are soft evidence of that.

even wget and curl are probably more limited by your CLI arg length limits than the bins themselves. e.g. I can craft a multi-megabyte GET request in a file and pass it to `curl -K` and it works just fine (I just did so to verify, a bit over 3MB. google complained a bit, but it responded). even if I screwed that up somehow / it silently truncated, I can absolutely do something with netcat and know it won't truncate.

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

#96

Post by qwertox »

siscia wrote: post #83
qwertox wrote: 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…

My apologies on the VerneMQ comment. I misread the sentence, not realizing it being a specific suggestion by you.

Regarding the topic of MQTT in general, to me it sounded as if you were not adding information but criticizing the choice of WebSocket instead of MQTT in this project. It was a misunderstanding.

To add to the discussion, maybe you could help me a bit with an issue I'm having. I'm currently working on a service which is starting to make use of MQTT for microservices communication. Initially I was using a WebSocket server for this, then moved over to RabbitMQ a couple of years ago, and now I have added a Mosquitto server which is working, but has not yet replaced RabbitMQ. This service also has one public NodeJS websocket server for web browser clients to connect to it, this WebSocket server receives the messages via RabbitMQ and dispatches it to the clients. I also want to replace that WebSocket server by another Mosquitto instance, so that MQTT will basically become the main way for communication between servers and also with clients.

I chose Mosquitto because it have been using it at home without any problems for a while now and have a custom authentication plug-in for it which I wanted to reuse.

VerneMQ is a candidate, but Mosquitto is working just fine, so I haven't looked into it again. I like how lean Mosquitto is and how it's configured inside a container. Plus I can understand the source code and eventually modify it.

Would you advise me against using Mosquitto in a production system? Which benefit would I have by using VerneMQ?

My apologies, again.

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

#97

Post by lmorchard »

siscia wrote: 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…

Depends on the exact problem definition. This is a small, single-binary server, offering a built-in web UI & API, requiring very little configuration, working with a mobile app for Android phones. Took me 5 minutes to start getting some notifications from things around my house.

Sometimes you don't need a cargo van or a jumbo jet to get the job done when a skateboard will do.

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

#98

Post by siscia »

qwertox wrote: post #96
siscia wrote: post #83

Earlier quoted context omitted.

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…

My apologies on the VerneMQ comment. I misread the sentence, not realizing it being a specific suggestion by you. Regarding the topic of MQTT in general, to me it sounded as if you were not adding information but criticizing the choice of WebSocket instead of MQTT in this project. It was a misunderstanding. To add to the discussion, maybe you could help me a bit with an issue I'm having. I'm currently working on a se…

Don't worry! We are all busy and sometimes is normal to read too quickly a message on internet.

My advice would be to have one single broker no matter what, so don't replace the websockets server with another instace of mosquitto, but just use the same old instance.

Then, the ice thing of working with a protocol is that you don't care of the implementation, hence just keep using mosquitto until it support the load and the, eventually swap verneMQ if necessary.

Be careful with your custom authentication logic, that if you want to migrate will require you to port it over.

Verne provide plugins for Auth so it is not an huge deal but you need to think a little bit ahead.

But again, if mosquitto is working fine just keep it!

Cheers!

Post reply on HN