Ditto. Discord works great for me because it's the one app I actually have installed on across most of my devices (including desktop), and regularly check notifications for.
Yeah, a one-person Discord "server" is a great way to have e.g. RSS notifications (via MonitoRSS) as well as simple bots. It is just remarkably straightworward - you don't need to register an app, just generate a webhook token and then curl a simple json to that endpoint. Now, I was confused and thought webhooks are somehow standardized, but they're not. It's kinda like RSS in reverse, with an application defined payload.
Very nice. I use a telegram bot for doing this as telegram API also makes it a simple GET request to send such notifications to yourself (once you have created a bot).
Also it's surprisingly hard to kill telegram for some reason so it's kinda robust. My stupid mi phone is quite aggresive in killing most background apps except whatsapp and telegram.
I find telegram messages only get insta-delivered about half the time. The other half, they're delayed till I next re-open the app. Doesn't seem to happen with any other app.
I suspect it's because I'm subscribed to too many high traffic group chats, and even though they're muted, the telegram servers still send large numbers of push notifications for them, which eventually start hitting some rate limit and everything gets dropped - even for unmuted conversations.
> I find telegram messages only get insta-delivered about half the time. The other half, they're delayed till I next re-open the app. Doesn't seem to happen with any other app.
That happens to me with WhatsApp. Curiously a message to Telegram kicks it back into gear too. My fiancee first messages me 'calling' on Telegram before calling on WhatsApp, because she figured out (remotely, by experience) that otherwise it often doesn't ring.
> Also it's surprisingly hard to kill telegram for some reason so it's kinda robust. My stupid mi phone is quite aggresive in killing most background apps except whatsapp and telegram.
Part of the reason for this is hardcoded whitelisting.
Big reason is I can create groups and add people to such notifications. Super easy.
I have some scheduled ci/cd pipelines that send notifications. Just scroll up for history. This setup has been working with no changes needed for couple years, no hiccups. Love it.
I love this project. Super simple to interface with, accomplishes the task very well, reliable, good documentation. It's hard to think of better design and execution for this type of utility.
I use it to get notifications of the CI running on build.wireguard.com, which took less than a minute to get working. Sometimes I'll use it for random one-off notifications, like when a command finishes running or some shell script sleep-loop scraper finds what it was waiting for. It's the nicest thing I've had for that kind of thing since mytelephonenumber@txt.att.net.
Thank you for saying that Jason; it means a lot coming from you.
I remember when you sent me that email months ago it was super cool for me. The creator of WireGuard emailing meee? whoa! Anyway. Thanks again for the kind words.
It's not the sending the messages that has me stumped, it's the setup of the server (the hosting of it itself).
Do you know of a public service that exists i could build/test the Apprise plugin against? Would love just even temporary access to a server to perfect its design (then my account could be terminated)
Thank you! I feel silly for asking when the answer really was right there in my face. I was able to sign up with a service. Apprise will hopefully have Mastodon support next!
I love this project. I use these notifications in many of my scripts. You can send push notifications to your phone (iOS/Android) with a simple curl command. Easily one of my favorite open-source projects.
If this doesn't work for you, you can always create a ticket or make your own app or website using the subscription API: https://ntfy.sh/docs/subscribe/api/
I'm not in a position to try ATM, I thought the same question, but could you not just use the web app and have the mobile browser post notifications as happens on the desktop version? There might be different limitations wrt delivery latency between the app and sit though, particularly when your device is in low power mode to conserve battery between periods of activity.
Hey there. In Android, is there a requirement or any kind of dependency on Google Play Services? Also, do notifications work when the Ntfy app is in the background? Do I need to disable battery optimizations for it?
This is incorrect (at least in my experience). Firebase/FCM is significantly slower in delivering messages than the non-Firebase version (WebSockets or JSON stream, longstanding connection). It was actually mindboggling to me how slow Firebase is in delivering messages (especially when the phone is in doze mode).
Even if you disable battery optimization it's going to depend on your phone if it will actually honor it (and not kill the app). This site: https://dontkillmyapp.com/ shows which phones behave correctly.
We've done some battery work a couple of months ago and since then I've not really had any complaints from the thousands of users, so I think overall it's working.
Every now and then there is some oddball phone that keeps killing connections and such, but it's very very rare. I think we've optimized it to the best of what's possible at the moment.
When I was making my IoT washing machine sensor, I used Blynk.io to push notifications to my phone but of course that service became commercialised and is no longer free. I could not find any nice easy to use alternative except for Telegram which is what I use now. This service looks exactly like what I would need and I appreciate the promise to keep it open source.
I’ve been using for quite a fee years. The app is not free but once you pay the one-time fee for the app, they have a generous free tier for personal use, and it has worked quite flawlessly for me so far.
Additionally they support "Critical Alerts" on iOS for when you really need to get a notification regardless of whether or not you've muted your device. Probably something similar is possible on Android as well?
Yes, emergency priority: ignores do-not-disturb, full volume, and repeats every x minutes until acknowledged (x is configurable when sending the notification).
On Android, Pushover is able to (optionally) play notification sounds for high-priority messages through the alarm channel like an alarm app would, so it can bypass the device's mute switch.
I'm using Pushover a lot, it exists for a very long time, never changes and just works. It's also very easy to wire it up to existing tools as it can listen to webhooks.
I've used pushover for years as well. I wish they would charge me $5/y instead of a $5/lifetime. I've asked them to do that. I want this service to last.
I set up Tasker on my phone such that when a specific low-priority (no visible/audible alert) message from pushover, containing only a hash key, is received it picks it up and does an HTTPS request to my self-hosted server to retrieve the actual notification text.
I have a bash/websocat client connected 24/7 to wss://client.pushover.net/ as well that I should probably put up on git for other people.
Got any more information on what you're doing with your washing machine? I have this[1] running for the past four years with Telegram without a hitch but I'm curious on what you're doing!
It's quite cheap to run. It's just one small EC2 instance, and it's usually idling around a load average of 0.1 (though right now it's at 1, hehe). It costs me about $24/month. The Apple developer license costs $100 per year, so it's ~$400/year. As of recently, that's entirely covered by donations.
I am incredibly humbled by the sponsorships. I would have never thought ntfy would take off like that. I love open source and I promise it'll always be free and open (as long as I can reasonably fight of the abusers).
If I were to run my own personal instance of this that cost would be quite high. A free Oracle Cloud VM or $5 Digital Ocean droplet would be the way I go.
Yeah, I think that "or two" in "one or two kids" is still being litigated. My reading is that it'll stay in litigation indefinitely, as this is the price both companies agreed to pay when they decided to retain lawyers from Hell itself.
Well, of course. “$24 per month seems high for running my own personal instance that’s going to do a handful of notifications daily” vs “$24 per month seems high for running a public service that could very easily need to be scaled up quickly” are two very different statements.
I only have experience with Digital ocean and AWS. AWS free support is definitely much better than Digital Ocean. Also Digital Ocean is more quicker to delete your data than AWS in case of billing issue or anything.
You can probably cut down server cost by half. Have you tried with lower resources or have figured out a minimum requirement for the server? As an experiment I suggest - https://tinykvm.com/ - with FreeBSD or OpenBSD (Linux doesn't really do well with small amount of RAM).
Much appreciated my friend. I honestly didn't opt for the cheapest server because I wanted it to run well. I don't want to constantly fight for resources or worry about it. It was supposed to be fast and be able to handle traffic well.
And it is. It's not falling apart from the HN traffic and it has a lot of head room. Plus. It's doing 400k messages a day already easily.
Anyway. Thank you so much for your generosity. I am humbled and thankful for your support.
I think its because this is a hobby project and for a lot of people the cheaper a hobby project is the more they can keep running before the money runs out. It's also that for some people optimizing costs and making things run on as few resources as possible is fun.
But if you don't find it fun spending time performance optimizing to the extreme, and can afford it, then there's nothing quite like massively over-provisioning hardware. It makes a lot of performance and reliability problems go away.
Probably some truth to all you said. I spend way more money on my hobbies.
For this creator, his hobby is well into the realm of "could productize some component", even if just creating derivatives of this for some commercial purpose. I'd much rather spend time on that than the optimization part. My thought is HN has skewed more technical than entrepreneur over the years and the folks who are into the optimizations are more vocal in the thread. Could also just be the cohort of HN that was attracted to this article. "Send push notifications to your phone" sounds pretty technical. Or, the tech recession is changing mood about money and I'm not in tech.
I appreciate the dogged pursuit of efficiency, but spending a lot of time optimizing for the current scale and getting costs from $24 per month to $10 per month (or whatever) is likely wasted time if this grows significantly. You have to be able to recognize there’s a lower bound where your costs are low enough it doesn’t matter and even saving 75% isn’t worth thr effort. The author has obviously drawn that line somewhere above $24 per month and that’s perfectly reasonable.
That's a good point. I guess many of us were suggesting cheaper VPS because we assumed this is a new project, just launched. (Most inexperienced developers / start-ups tend to over provision). With current hosting technologies, it is quite easy to scale with need, with minimum downtime, so it makes sense to start with the minimum server requirement and then go for a powerful server as required. This give you valuable data on the bottlenecks (where you can do future optimizations), as you scale, while you temporarily fix the issue with more money (by requisitioning better servers) as you work out the cost-benefit analysis (as you did) of spending money on optimising vs server upgrade.
In terms of open connections, it varies, but right now it's 5k active connections. But there are many many self-hosters out there, and the people using Firebase (no "instant delivery") are also not counted in that.
You can subscribe to the stats above using the https://ntfy.sh/stats topic (old messages are only cached for 12h, so half the day it shows up as empty)
I love your work and admire your approach. But you should recognize a void will emerge and void get filled. Someone (probably reading this thread) will clone your idea and make it a supported for pay service.
It wont be me. But some enterprising engineer/pm/group who was recently laid off in this downturn will probably make a go of it.
Have you thought about integrating with Matrix in any way? I.E. curl ntfy.sh/matrix and put the matrix room id in the post payload. The user would have to invite your ntfy.sh matrix user to the room, and it would not offer encryption, but it might add value for use cases where you want to send to a team or the user wants their notifications in the same place.
No real lessons learned. I like Go, and I like that it lets me do no-fuzz-straight-to-the-point development. The single Go binary and server is handling the traffic just fine, and the architecture is simple and easy to extend.
I am suffering a little right now while I try to add E2E encryption, because I structured the handlePublish logic awkwardly. But other than that there have been no surprises.
I guarantee for nothing, since this is a spare time project. That said, I have had zero outages in 11 months, see https://ntfy.statuspage.io/
When it outgrows the single EC2 instance, I'll likely start building some distributed thingy to spread the load and do some HA things (sounds like fun). Probably just a load balancer and 2-3 instances with a rqlite backend instead of SQLite, nothing too fancy.
Right now that's not necessary. As you can see, it handles traffic just fine for now.
rqlite[1] author here, happy to answer any questions about it if it helps.
rqlite will give you HA, but won't help with load (rqlite replicates for reliability, not for write performance). But I like to think the it'll give you solid -- and simple to use -- HA. Replicated just replaced their use of Postgres with rqlite for this reason[2].
The lib author seems to be German.
Just an observation I made in the past: Some of the brightest German programmers I have ever met happily take 9-5 Jobs and rather do their project ideas as as hobbies. Might be a cultural thing?
As for your hypothesis: I can only speak for myself, but I just don't want to ruin my hobby by monetizing it. Plus, I've spent enough time with the community to know that as soon as money gets involved, people are suddenly not so kind anymore. I just like it more when people are kind and polite to each other and treat each other with respect...
Thank you for creating this. I was just looking for something like that to send notifications to my mobile without setting this all up and deploying my own app to the store. Using ntfy now :)
Not knowing anything about the engineer in question, no two people's experience over a given period of time is equivalent. Additionally, levels differ wildly at different organizations.
And to subscribe, either use UnifiedPush (https://unifiedpush.org/), or use intents (see link above). Or, implement your own foreground service with WebSockets (just like the ntfy app does).
I absolutely love this, and my mind's already buzzing with a bunch of ways I can use it. I love the simplicity, the docs, the pleasant experience of understanding and getting it running. (In like 10 seconds!) No logins, no user permissions management, no API keys and complicated auth creds, just a topic/password. So cool. I think it's cool for every once and awhile to push back against the trends for complication/over-engineering even if just to remind us of how simple/straightforward software can really be.
You've made a beautiful piece of software for your own enjoyment and the benefit of others. It is just what it needs to be. Bravo. In a world where projects get massively complicated and pumped full of VC funding, may efforts like this live on.
No, because your Nginx server decrypts that TLS connection so can access the plaintext data. This is typically called encrypted-in-transit.
E2EE means that it's always encrypted from the sending device to the receiving device and nothing in the middle (including the service operator) can read it.
E2E implies that the data itself gets encrypted by the sender and is only decrypted by the receiver. With https, the "pipe" is encrypted, but the data is not and the server will get the plain-text.
> Will you know what topics exist, can you spy on me?
> If you don't trust me or your messages are sensitive, run your own server.
This is the way. No pinky promises in whitepaper format[2] that leave out the most important bits, no meticulously constructed but entirely meaningless marketing statements[3][4], but unassuming and deferential logic with a mitigation path.
Why couldn't the entire system be E2E encrypted by default, though? In 2022, that's my standard expectation from any service. Even such things as Pocket / Instapaper / Raindrop should come with E2E encryption by default. It's better for the service provider, too: no issues with GDPR, or in case of a database hack.
If you run binaries compiled by the author of the software it wouldn't matter that it is open source, so play store is out of the question. So then it must be open source and you must use distributor you trust: your distro maintainers and F-Droid.
Also you must trust that people did really take a look at the code.
> Therefore, no need to trust anybody, as long as the software is open-source.
Demonstrably untrue. You must trust that the contributors are trustworthy, they have implemented a strong security posture for their project, and that the code is reviewed by people who are trustworthy. Many open-source projects have been, and continue to be, compromised on a regular basis.
That's only the case if I am unable to review the code myself, before any update, I fully understand the code, and I am smart enough that the contributors are unable to pull a fast one on me.
Given that I'm not a cryptography expert, I have a limited number of hours in the day, and open-source supply chain attacks are typically obfuscated, I don't consider that to be a trivial statement.
You have 0 guarantee that the open source code is actually the code that runs on your device.
And you have 0 guarantee that the device itself is not compromised.
And you have 0 guarantee that the OS is not storing your data.
E2E on mobile devices is a security blanket with holes the size of the solar system.
If you don’t trust a communication channel, you could always do a Diffie-Hellman key exchange in the clients which lets you create a shared encrypted channel between two parties by sharing public keys. This works even if they are trying to monitor you.
It can work with simplex channels if you have the public key of the receiver. Both parties just need to know each other's public keys to create encrypted communication. After exchanging the public keys, it can be one-way communication.
I guess it wouldn't work for a one-to-many channel though, just individual one-to-one channels.
Encryption and convenience usually don't go well together. ntfy was mainly built for simplicity. That said, I have designed and started working on E2E here: https://github.com/binwiederhier/ntfy/issues/69
Genuine question - have you ever implemented an E2E encrypted system?
Because it's not particularly easy to do, and there are a lot of caveats and drawbacks.
Let me rephrase your assumption: "Why couldn't you just mail me the letter in a 100lb safe. In 2022, that's my standard expectation from any service".
So - are you willing to pay to ship 100lbs for every letter you send? Are you meticulously managing the details of how to handle locking and unlocking that safe? Are you working out the details on recovery and storage, handling lost devices, configuring a communication channel for sharing certs/keys, managing several crypto dependencies and libraries - all so that you can go "Hey - what's up!" in a notification to your phone?
Or should you just stop whining - accept that this is free - and take the authors advice and host it yourself?
> Are you working out the details on recovery and storage, handling lost devices, configuring a communication channel for sharing certs/keys, managing several crypto dependencies and libraries - all so that you can go "Hey - what's up!" in a notification to your phone?
In 2022, there is no need to invent anything new about E2E encryption. There are many successful open-source examples, including Keybase and Firefox Sync.
There is no question that it adds development overhead, but I personally wouldn't even run a public service for others without E2E encryption.
> Or should you just stop whining - accept that this is free - and take the authors advice and host it yourself?
I am not attacking the author, nor do I currently care about this particular service he is providing.
This is Hacker News, a discussion platform, and I am raising a question about software development in general.
You solve that by forwarding/decrypting/adding noise between servers, enough to cover metadata traffic you generate. The only data you reveal is anyone listening know you might have used it at some point. See https://vuvuzela.io/ I suspect it is named so because it uses a lot of bandwidth.
>This is Hacker News, a discussion platform, and I am raising a question about software development in general.
No - no you aren't. You're complaining about a feature in a product you've admitted you won't use.
Which... is fine. At the end of the day - the feedback might be helpful or it might not, part of the journey of publishing software (or making anything, really) is figuring out what advice to listen to, and what to ignore.
But personally - I don't really find your point sensible. You have no use-case, you have no threat model, you have a very unclear understanding of what E2E encryption entails, in my opinion - since you point to apps whose entire marketing shtick is that they have E2E encryption and say "if they are doing it, it must be easy" - Ignoring that they are literally using the difficulty of doing it as the distinguishing factor for their product.
But hey - I worked for a security company that did E2E encryption for fortune 100 companies, mostly banks, for 5 years (and eventually went out of business... as an aside) so what do I know...
> But personally - I don't really find your point sensible. You have no use-case, you have no threat model [...]
My point is very clear and simple: all private communication on the internet should be E2E encrypted by default, unless there is a good reason not to.
> [...] say "if they are doing it, it must be easy" - Ignoring that they are literally using the difficulty of doing it as the distinguishing factor for their product.
I am not claiming that it's easy, but there has been plenty of open-source projects launched with E2E encryption by default in the past few years.
> My point is very clear and simple: all private communication on the internet should be E2E encrypted by default, unless there is a good reason not to.
Are you counting HTTPS as “E2E encrypted”? Because if not, consider that we do private communication over mere HTTPS all day long. Me loading the HN web page and having my own personal rendering of it with my user cookie header and all my upvote/downvote/karma/profile state is private communication, for example.
> Because if not, consider that we do private communication over mere HTTPS all day long. Me loading the HN web page and having my own personal rendering of it with my user cookie header and all my upvote/downvote/karma/profile state is private communication, for example.
Because there is a good reason for it: it wouldn't work well with E2E encryption.
Well, ok, I guess we can use that as a justification for anything then. For example, the “good reason not to” use E2E for ntfy could be “market analysis says the small and somewhat theoretical benefit isn’t worth the complexity.”
Yes, but you said all private communication should be E2E. Apparently you're defining communication in some way that excludes an awful lot of what I'd consider communication (e.g. HTTPS traffic).
My key point was "unless there is a good reason not to". And in many cases there is a good reason not to use E2E encryption, like the example you have given. But in the case of Ntfy, E2E encryption would be a perfect fit, and eliminate any need for self-hosting.
I'll be blunt - as someone who worked in the space extensively... if you really need e2e encryption, you want to be self hosting anyways.
By the time you're trusting a hosting provider to properly do e2e for you... you've basically already lost the game. At any point they can update what's running and remove any/all protections you think you have.
So again - what is your threat model here? Because it sounds like you want "super convenient" and also "super secure" and those aren't two options you just check off - they're really more like diametrically opposed sides of the same slider.
> all private communication on the internet should be E2E encrypted by default, unless there is a good reason not to.
Why? Why do you think this. What value do you imagine this is bringing you beyond simple TLS?
Because to me, this is like saying "All conversations should be whispered by default, unless there is a good reason not to." except that's obviously not reasonable, because there are many reasons not to whisper all the time. In the same way that there are many reasons wrapping all your communication into a black box is a bad idea (discoverability and search being the most obvious two, although data loss is right on up there).
I run a E2E system using public and private keys. It's really not that complex.
Sure, it's not free, but the implementation effort was 1/100 of the UI work.
Clients encrypt data in the browser, share id of the data and key (+ optional password). Some other clients receive id of the data and the key and read it.
For a notification service, you would just need a setup step to generate a key and store it in the browser + on the phone.
That said, I'm not sure I understand why would someone need to notify its own phone.
The most important bits aren't the technical aspects, but rather who controls them.
It is entirely meaningless when the keys are generated by a closed source application, when there exists no way to verify that the data isn't exfiltrated before its encryption or after its decryption, or when the only transportation method is entirely in an untrusted party's hands.
When all those things are controlled by the same entity, especially one with a history of abusive and manipulative behaviour such as the operator of WhatsApp, it's not "encryption" but a "bad joke".
Encryption by default eliminates the biggest advantage: simplicity. But as an option, it's an useful addition that will be implemented sooner or later.
Encrypting stuff in a way that can’t be trivially subverted by a malicious client app is actually pretty hard, so what have you actually gained if you’re going to trust the client app?
The pitch is that you can go `curl -d "My message" ntfy.sh/my_topic` and it just works. That's impossible if you want E2EE.
Fortunately, it's open-source, so if you really want, you can fork the app to add a decryption layer and then use `curl -d "$(echo "My Message" | openssl enc -aes-256-cbc -pbkdf2 -e -k "My Password")" ntfy.sh/my_topic` and that'll be E2E encrypted.
Or, you know, host your own ntfy server and trust in SSL.
You have perfectly captured my intention. :-) ntfy is supposed to be simple simple simple.
E2E stands in the way in many ways. I have implemented crypto formats and such in the past, and the lack of a standard in this space is really blocking wide spread adoption and interoperability IMHO. That said, I have proposed a design here (https://github.com/binwiederhier/ntfy/issues/69#issuecomment...) that I have already partially implemented, and that seems easy enough to implement in many languages. But it definitely won't be the one-liner anymore.
Why not end to end encrypt notifications with a public key?
Both iOS and Android can run a completionHandler to decrypt them using a private key that can be stolen if the app is disassembled.
But you can generate a private key per user, after install, and each mailbox publisjes a public key.
The thing I find ironic is that the actual encryption is done in JS, which is served by a webserver so anyway you have to trust the webserver. Same as you trust WhatsApp to not send your text to Facebook.
Is there a way around this having to trust an app? Seems the only way to do that would be to have a browser extension or several, that you trust not to collude with a website.
Ultimately there's no way around having the trust the client. The state of the art on that front right now is open source code with reproducible builds[1] and binary transparency[2].
Unfortunately none of that is currently implementable on the web for the reason you cited; the web server can just replace the entire application with any code it wants when you refresh the page. One possible path to fixing that is web packaging[3], but those standards are still in their infancy and don't yet have a mechanism for enforcing binary transparency.
You can enable content security policy then hash all the javascripts and assets so only prebuilt and hashed stuff is allowed to be loaded in the web browser. There is no way to easily check that some one you trust did the hashing, but it is doable with an extension in the web browser.
"Enable content security policy" is something done by the web server (via a header in the response), so that doesn't solve the problem.
In theory yes, you could probably create an extension that leverages Content Security Policy as a means of enforcing binary transparency. But at that point you'd basically just be implementing a slightly worse version of web packaging via an extension.
For me CSP is enough because the apps I need to trust only have one hash. So I do it manually. I will try to switch over to SXG trusting a signer is easier than having a list of trusted hashes, do you know if there some way to require/verify it that is visible on mobile?
Web Packaging seems to be vaporware to some extent, and I need something that works now.
> I love free software, and I'm doing this because it's fun. I have no bad intentions, and I will never monetize or sell your information, and this service and software will always stay free and open.
If you're still paranoid (which is your right), go host it yourself, or wait until I finished implementing E2E :-D
"No pinky promises in whitepaper format that leave out the most important bits"
Difference here, is that the promises are verifiable and their concequences avoidable altogether (by self compiling and hosting). The developer also acknowledges the existing holes rather than misdirecting away from them.
Edited my previous comment slightly as it was not at all my intention to accuse you of malicious intent. My apologies if it might have have come across that way.
> You should download Android Studio (or IntelliJ IDEA with the relevant Android plugins). Everything else will just be a pain for you. Do yourself a favor.
I'm not into mobile programming, and I wonder what is behind this statement.
I sometimes use my little service https://pushurl.43z.one/ If I need to notify my desktop browser or phone with a notification triggered by some code.
I just go to the website with my browser click generate. Then in my script I do `curl $pushurl?title=jobdone`. When it gets triggered a notification popups on my phone that says "jobdone".
It uses the native browser web push API so I don't need to install anything extra.
Yes, exactly. The pushurl has to be generated with the browser on the device which you want send notifications to. The pushurl is bound to that browser.
Keep in mind that ntfy works with a bunch of backends. You can send the notifications to Telegram, jabber/XMPP, IRC (using my own https://n.tkte.ch), Slack, etc, etc. So, you probably don't have to actually install anything new to receive notifications and can just use what you've already got.
305 comments
[ 3.0 ms ] story [ 221 ms ] threadAlso it's surprisingly hard to kill telegram for some reason so it's kinda robust. My stupid mi phone is quite aggresive in killing most background apps except whatsapp and telegram.
I suspect it's because I'm subscribed to too many high traffic group chats, and even though they're muted, the telegram servers still send large numbers of push notifications for them, which eventually start hitting some rate limit and everything gets dropped - even for unmuted conversations.
That happens to me with WhatsApp. Curiously a message to Telegram kicks it back into gear too. My fiancee first messages me 'calling' on Telegram before calling on WhatsApp, because she figured out (remotely, by experience) that otherwise it often doesn't ring.
Part of the reason for this is hardcoded whitelisting.
Big reason is I can create groups and add people to such notifications. Super easy.
I have some scheduled ci/cd pipelines that send notifications. Just scroll up for history. This setup has been working with no changes needed for couple years, no hiccups. Love it.
I use it to get notifications of the CI running on build.wireguard.com, which took less than a minute to get working. Sometimes I'll use it for random one-off notifications, like when a command finishes running or some shell script sleep-loop scraper finds what it was waiting for. It's the nicest thing I've had for that kind of thing since mytelephonenumber@txt.att.net.
I remember when you sent me that email months ago it was super cool for me. The creator of WireGuard emailing meee? whoa! Anyway. Thanks again for the kind words.
https://github.com/caronc/apprise
https://github.com/caronc/apprise/issues/586
https://docs.joinmastodon.org/methods/apps/oauth/ https://docs.joinmastodon.org/methods/statuses/
Do you know of a public service that exists i could build/test the Apprise plugin against? Would love just even temporary access to a server to perfect its design (then my account could be terminated)
e.g https://masto.ai/ or https://fosstodon.org
It's funny how similar the domain name is.
https://nudge.sh https://github.com/geocodio/nudge.sh
If this doesn't work for you, you can always create a ticket or make your own app or website using the subscription API: https://ntfy.sh/docs/subscribe/api/
Thanks!
There's no dependency on Google services, although the app can use them if available.
- avoid Google servers - preserve battery - show timely notifications
https://github.com/deltachat/deltachat-android/issues/82
And yes, you need to disable battery optimization if you don't want to use Firebase. On my phone it uses 1% battery in a full day (17h).
Every now and then there is some oddball phone that keeps killing connections and such, but it's very very rare. I think we've optimized it to the best of what's possible at the moment.
Here's a quick fish function for being able to call this from a shell like `alt my message`
Twilio SMS API, on the other hand, does not have that limit and you can send long SMS messages with a single 'curl' command:
That's simplified - I actually pipeline through 'tidy5' and 'source-highlight' to make the output pleasing:I’ve been using for quite a fee years. The app is not free but once you pay the one-time fee for the app, they have a generous free tier for personal use, and it has worked quite flawlessly for me so far.
In my case I just did that recently to receive webhooks and send them to my phone: https://blog.notmyhostna.me/posts/push-notifications-from-ap...
I set up Tasker on my phone such that when a specific low-priority (no visible/audible alert) message from pushover, containing only a hash key, is received it picks it up and does an HTTPS request to my self-hosted server to retrieve the actual notification text.
I have a bash/websocat client connected 24/7 to wss://client.pushover.net/ as well that I should probably put up on git for other people.
https://blog.pushover.net/posts/2022/3/ten
Any individual users wanting to support Pushover are welcome to join as a personal Team with 1 member :)
[1] https://hnn.avci.me
https://www.prowlapp.com
Personally I setup a Slack server and use webhooks to push events to a channel there. Works great :)
I'm building exactly this right now for my first hardware project. Have you published any notes anywhere?
[1]https://github.com/jebeaudet/time-to-fold-alerter
Edit: I am also looking for a new opportunity. If you need a good Staff/Principal Engineer, check out my resume here: https://heckel.io/resume.pdf
I am incredibly humbled by the sponsorships. I would have never thought ntfy would take off like that. I love open source and I promise it'll always be free and open (as long as I can reasonably fight of the abusers).
If you'd like to help me out me, you can donate via GitHub Sponsors: https://github.com/sponsors/binwiederhier
That being said, it's probably not worth migrating to another provider at this point.
And it is. It's not falling apart from the HN traffic and it has a lot of head room. Plus. It's doing 400k messages a day already easily.
Anyway. Thank you so much for your generosity. I am humbled and thankful for your support.
But if you don't find it fun spending time performance optimizing to the extreme, and can afford it, then there's nothing quite like massively over-provisioning hardware. It makes a lot of performance and reliability problems go away.
For this creator, his hobby is well into the realm of "could productize some component", even if just creating derivatives of this for some commercial purpose. I'd much rather spend time on that than the optimization part. My thought is HN has skewed more technical than entrepreneur over the years and the folks who are into the optimizations are more vocal in the thread. Could also just be the cohort of HN that was attracted to this article. "Send push notifications to your phone" sounds pretty technical. Or, the tech recession is changing mood about money and I'm not in tech.
As for the scale question: The server is already tuned for scale: https://ntfy.sh/docs/config/#tuning-for-scale
If you have any more ideas of what nobs to turn, let me know.
You can subscribe to the stats above using the https://ntfy.sh/stats topic (old messages are only cached for 12h, so half the day it shows up as empty)
It wont be me. But some enterprising engineer/pm/group who was recently laid off in this downturn will probably make a go of it.
I am suffering a little right now while I try to add E2E encryption, because I structured the handlePublish logic awkwardly. But other than that there have been no surprises.
Sorry that's such a boring answer.
I guarantee for nothing, since this is a spare time project. That said, I have had zero outages in 11 months, see https://ntfy.statuspage.io/
When it outgrows the single EC2 instance, I'll likely start building some distributed thingy to spread the load and do some HA things (sounds like fun). Probably just a load balancer and 2-3 instances with a rqlite backend instead of SQLite, nothing too fancy.
Right now that's not necessary. As you can see, it handles traffic just fine for now.
rqlite will give you HA, but won't help with load (rqlite replicates for reliability, not for write performance). But I like to think the it'll give you solid -- and simple to use -- HA. Replicated just replaced their use of Postgres with rqlite for this reason[2].
[1] https://github.com/rqlite/rqlite
[2] https://www.replicated.com/blog/app-manager-with-rqlite/
> turn it into an actual business :-) It'd be a lot more fun
Not only could it _not_ be more fun, but it might actually suck all the existing fun out of it completely. But the OP will know better about that!
As for your hypothesis: I can only speak for myself, but I just don't want to ruin my hobby by monetizing it. Plus, I've spent enough time with the community to know that as soon as money gets involved, people are suddenly not so kind anymore. I just like it more when people are kind and polite to each other and treat each other with respect...
Could you elaborate on how this differs from gotify?
And to subscribe, either use UnifiedPush (https://unifiedpush.org/), or use intents (see link above). Or, implement your own foreground service with WebSockets (just like the ntfy app does).
You've made a beautiful piece of software for your own enjoyment and the benefit of others. It is just what it needs to be. Bravo. In a world where projects get massively complicated and pumped full of VC funding, may efforts like this live on.
I decided to add Ntfy.sh support today just because it was so goddamn easy. Thanks for the cool service!
Now whenever new pull requests, issues or commits are made I get a ding on my phone!
E2EE means that it's always encrypted from the sending device to the receiving device and nothing in the middle (including the service operator) can read it.
1: https://ntfy.sh/docs/faq/#will-you-know-what-topics-exist-ca...
2: (warning: redirects with identifiers, how ironic) https://www.whatsapp.com/security/WhatsApp-Security-Whitepap...
3: https://privacy.microsoft.com/en-us/privacy-report
4: https://www.apple.com/privacy/
E2E allows both clients to talk to eachother without server having a way to snoop on
Also you must trust that people did really take a look at the code.
Demonstrably untrue. You must trust that the contributors are trustworthy, they have implemented a strong security posture for their project, and that the code is reviewed by people who are trustworthy. Many open-source projects have been, and continue to be, compromised on a regular basis.
In theory, that's only the case if you are unable to review the code yourself.
In practice, it's like saying that TLS encryption is pointless, because one needs to trust every single person who implements it.
Given that I'm not a cryptography expert, I have a limited number of hours in the day, and open-source supply chain attacks are typically obfuscated, I don't consider that to be a trivial statement.
You have 0 guarantee that the open source code is actually the code that runs on your device. And you have 0 guarantee that the device itself is not compromised. And you have 0 guarantee that the OS is not storing your data.
E2E on mobile devices is a security blanket with holes the size of the solar system.
I guess it wouldn't work for a one-to-many channel though, just individual one-to-one channels.
Because it's not particularly easy to do, and there are a lot of caveats and drawbacks.
Let me rephrase your assumption: "Why couldn't you just mail me the letter in a 100lb safe. In 2022, that's my standard expectation from any service".
So - are you willing to pay to ship 100lbs for every letter you send? Are you meticulously managing the details of how to handle locking and unlocking that safe? Are you working out the details on recovery and storage, handling lost devices, configuring a communication channel for sharing certs/keys, managing several crypto dependencies and libraries - all so that you can go "Hey - what's up!" in a notification to your phone?
Or should you just stop whining - accept that this is free - and take the authors advice and host it yourself?
In 2022, there is no need to invent anything new about E2E encryption. There are many successful open-source examples, including Keybase and Firefox Sync.
There is no question that it adds development overhead, but I personally wouldn't even run a public service for others without E2E encryption.
> Or should you just stop whining - accept that this is free - and take the authors advice and host it yourself?
I am not attacking the author, nor do I currently care about this particular service he is providing.
This is Hacker News, a discussion platform, and I am raising a question about software development in general.
So don't? seems like everyone got what they wanted.
No - no you aren't. You're complaining about a feature in a product you've admitted you won't use.
Which... is fine. At the end of the day - the feedback might be helpful or it might not, part of the journey of publishing software (or making anything, really) is figuring out what advice to listen to, and what to ignore.
But personally - I don't really find your point sensible. You have no use-case, you have no threat model, you have a very unclear understanding of what E2E encryption entails, in my opinion - since you point to apps whose entire marketing shtick is that they have E2E encryption and say "if they are doing it, it must be easy" - Ignoring that they are literally using the difficulty of doing it as the distinguishing factor for their product.
But hey - I worked for a security company that did E2E encryption for fortune 100 companies, mostly banks, for 5 years (and eventually went out of business... as an aside) so what do I know...
My point is very clear and simple: all private communication on the internet should be E2E encrypted by default, unless there is a good reason not to.
> [...] say "if they are doing it, it must be easy" - Ignoring that they are literally using the difficulty of doing it as the distinguishing factor for their product.
I am not claiming that it's easy, but there has been plenty of open-source projects launched with E2E encryption by default in the past few years.
https://standardnotes.com/ is a good example.
https://stingle.org/ is another.
https://ente.io/ is one more.
Are you counting HTTPS as “E2E encrypted”? Because if not, consider that we do private communication over mere HTTPS all day long. Me loading the HN web page and having my own personal rendering of it with my user cookie header and all my upvote/downvote/karma/profile state is private communication, for example.
No.
> Because if not, consider that we do private communication over mere HTTPS all day long. Me loading the HN web page and having my own personal rendering of it with my user cookie header and all my upvote/downvote/karma/profile state is private communication, for example.
Because there is a good reason for it: it wouldn't work well with E2E encryption.
By the time you're trusting a hosting provider to properly do e2e for you... you've basically already lost the game. At any point they can update what's running and remove any/all protections you think you have.
So again - what is your threat model here? Because it sounds like you want "super convenient" and also "super secure" and those aren't two options you just check off - they're really more like diametrically opposed sides of the same slider.
> all private communication on the internet should be E2E encrypted by default, unless there is a good reason not to.
Why? Why do you think this. What value do you imagine this is bringing you beyond simple TLS?
Because to me, this is like saying "All conversations should be whispered by default, unless there is a good reason not to." except that's obviously not reasonable, because there are many reasons not to whisper all the time. In the same way that there are many reasons wrapping all your communication into a black box is a bad idea (discoverability and search being the most obvious two, although data loss is right on up there).
Clients encrypt data in the browser, share id of the data and key (+ optional password). Some other clients receive id of the data and the key and read it.
For a notification service, you would just need a setup step to generate a key and store it in the browser + on the phone. That said, I'm not sure I understand why would someone need to notify its own phone.
It is entirely meaningless when the keys are generated by a closed source application, when there exists no way to verify that the data isn't exfiltrated before its encryption or after its decryption, or when the only transportation method is entirely in an untrusted party's hands.
When all those things are controlled by the same entity, especially one with a history of abusive and manipulative behaviour such as the operator of WhatsApp, it's not "encryption" but a "bad joke".
Encrypting stuff isn't hard.
Probably because getting the system together in its current state was enough work.
> In 2022, that's my standard expectation from any service.
You have high standards. Do you expect others to raise their standards as high as yours...?
Fortunately, it's open-source, so if you really want, you can fork the app to add a decryption layer and then use `curl -d "$(echo "My Message" | openssl enc -aes-256-cbc -pbkdf2 -e -k "My Password")" ntfy.sh/my_topic` and that'll be E2E encrypted.
Or, you know, host your own ntfy server and trust in SSL.
E2E stands in the way in many ways. I have implemented crypto formats and such in the past, and the lack of a standard in this space is really blocking wide spread adoption and interoperability IMHO. That said, I have proposed a design here (https://github.com/binwiederhier/ntfy/issues/69#issuecomment...) that I have already partially implemented, and that seems easy enough to implement in many languages. But it definitely won't be the one-liner anymore.
Why couldn't you write a patch to do that, and submit it? Or clone the code and release e2entfy.sh?
https://github.com/binwiederhier/ntfy
The next topic on the FAQ. Also install instructions are provided.
Both iOS and Android can run a completionHandler to decrypt them using a private key that can be stolen if the app is disassembled.
But you can generate a private key per user, after install, and each mailbox publisjes a public key.
The thing I find ironic is that the actual encryption is done in JS, which is served by a webserver so anyway you have to trust the webserver. Same as you trust WhatsApp to not send your text to Facebook.
Is there a way around this having to trust an app? Seems the only way to do that would be to have a browser extension or several, that you trust not to collude with a website.
Not specific to mobile. Give an app data and it can do what it wants.
Unfortunately none of that is currently implementable on the web for the reason you cited; the web server can just replace the entire application with any code it wants when you refresh the page. One possible path to fixing that is web packaging[3], but those standards are still in their infancy and don't yet have a mechanism for enforcing binary transparency.
[1]: https://reproducible-builds.org/
[2]: https://developers.google.com/android/binary_transparency
[3]: https://wicg.github.io/webpackage/draft-yasskin-wpack-use-ca...
In theory yes, you could probably create an extension that leverages Content Security Policy as a means of enforcing binary transparency. But at that point you'd basically just be implementing a slightly worse version of web packaging via an extension.
Web Packaging seems to be vaporware to some extent, and I need something that works now.
No promises so they could be selling your info more than anyone else…
> I love free software, and I'm doing this because it's fun. I have no bad intentions, and I will never monetize or sell your information, and this service and software will always stay free and open.
If you're still paranoid (which is your right), go host it yourself, or wait until I finished implementing E2E :-D
Im just wondering why anyone would feel better about an faq that really isn’t much different than anything else.
The application, I’ve no idea/ don’t assume any malicious intent or actions.
Difference here, is that the promises are verifiable and their concequences avoidable altogether (by self compiling and hosting). The developer also acknowledges the existing holes rather than misdirecting away from them.
Edited my previous comment slightly as it was not at all my intention to accuse you of malicious intent. My apologies if it might have have come across that way.
> You should download Android Studio (or IntelliJ IDEA with the relevant Android plugins). Everything else will just be a pain for you. Do yourself a favor.
I'm not into mobile programming, and I wonder what is behind this statement.
I just go to the website with my browser click generate. Then in my script I do `curl $pushurl?title=jobdone`. When it gets triggered a notification popups on my phone that says "jobdone".
It uses the native browser web push API so I don't need to install anything extra.
I'm just curious.
_edit:_ wrote a little Bash function for this; seems to work well:
It apparently never got merged. ;-)