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.
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.
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 :)
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.
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)
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.
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.
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.
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).
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.
Disclaimer: I know the developer of Ntfy and have worked with them in the past.
I love this tool because it sits in a very convenient place in the alerting and monitoring stack.
At work the kind of alerting pipelines and frameworks needed can by necessity end up being nontrivial and somewhat sophisticated. If you run some stuff at home or in the cloud or whatever, I have often wanted some kind of simple alerting but never want to deal with mocking out similar systems that I've built at work.
Ntfy sits perfectly in this space, and I've used to to frame out my own kind of micro-alerting frameworks for a bunch of stuff that I run. It's incredibly easy to encapsulate in something like a bash TRAP or even || conditionals on random cronjobs, and just makes getting some kind of alerting so trivial. As such, it's spiraled out into a lot of different stuff that I run.
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.
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.
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.
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 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.
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.
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 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!
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.
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?
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.
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).
I use this service all the time to notify me when some long running scripts are finished. Also goes very well together with '''tail -f --pid XXXX /dev/null && curl -d "process is done" https://ntfy.sh/XXXXXXX'''
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.
Note that messages are only cached for 12h server-side, so you'll not see any messages in there mostly. I suggest to just subscribe and see if you like getting these messages.
@binwiederhier I have heard wonderful things about ntfy.sh; kudos!
Quick question: if my team and I already "subscribe" to a private matrix room to receive alerts from our automated scripts (which auto-send alerts into said private matrix room)...is there a need for also leveraging ntfy.sh into this type of workflow? Again, much love and respect to this project...I'm just trying to learn. Thanks!
I love your project @binwiederhier. Lately I have migrated my daily driver from LineageOS to e-os (https://e.foundation/e-os/). Both use microG, but for some Reason I have massive Lag receiving the Push Notifcations on e-os. Seems like it's not really receiving Notifications via Push, but rather via Pull. I'm running my own Instance, however I can rule out that it's a problem on the Server side, as it used to work without any Problems with LineageOS. Do you maybe have any ideas how I could debug that Problem? I've checked the microG app and allowed Push Notifications for ntfy. I've also made sure that Android's Battery Optimization Feature doesn't interfere with ntfy and I got the permanent Notification open (which keeps the ntfy Process running). Of course I've also built my own Android App and I use my own Google Firebase Credentials. I'm kinda lost at the moment, honestly. Would be great if you'd have some ideas how I could figure out what's wrong.
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.
Honorable mention: I've been a happy pushover customer (not affiliated)
All I did was pay $5 several years ago and I still have 10k messages/mo which is good enough for all my automation so far.
I did this 10 years ago by installing Tor on the phone and using a hidden service. It didn't need to be hidden, but it's much more convenient to set up than this while offering superior security with no effort. Actually I2P or something like that is a better way of doing it, just I only had Tor on the phone at the time and I2P is kind of script kiddie tier.
On a side note, I'm noticing a lot of apps I install via Fdroid don't work on my phone, they crash immediately, while the play store version works (same for this app). I suspect this is a side effect of me using Lineage OS - does anyone have a clue what might fail there on my phone?
I use this with unified push for Element and Fedilab on LineageOS. It's pretty reliable about pushing new notifications out, but I wish Element used it better for dismissing notifications when I real a message on another client.
Been using ntfy.sh for a while now, ever since I saw it on HN a couple of years ago or so. It's great for automated server notifications and the like. I even tied it to a web form as an ersatz on-call system.
This is great! I used to just use XMPP for this (so send an XMPP message to myself), but I guess having a push notification can mean you can do more powerful things with it.
Yeah, that's why I used it. It was simple and awesome!
What I meant is that by supporting push notifications directly, you can do things like supporting action buttons, open a link when clicking the notification, etc, rather than just XMPP which was what my solution did.
I'm not a hater, I am genuinely curious, how does something like this get to 800 votes on HN and 4.4K stars on GitHub?
I mean, it's just... a pub/sub server... using HTTP? With a thin UI for web/mobile? I'm obviously missing something, so what is it?
Again, not a hater, even though it may come off like I am, I'm just honestly wondering what makes this special. From first glance it seems like something most devs can hack in an hour or two.
I think the allure comes from solving a very sharp pain point if you're a hobbyist developer or new to mobile dev: push notifications.
I don't know about others, but the first time I looked into apps, I could make sense of everything until I got to push notifications. Then it became this insanely complicated rabbit hole with a bunch of companies saying they'd solve it for you for 20 bucks a month or whatever. For something that on the surface sounds like it should be dead simple.
So a simple, clean, free way to send a push notification to your phone, that you can use with a web request from anywhere? I can definitely see the mass appeal of that to the millions of people with small projects who don't want to become experts on google/apple's ecosystems just to make some words pop up on their phone.
There is hacking the functionality together in an hour or two and then there is polishing it to the point where it doesn't have rough edges and can easily be used by anyone with terminal experience.
Personally, the chosen feature set resonates a lot with me. I like services that don't need accounts f.e. because they are so easy to use.
This needs account syncing from the backend. You need to describe to every topic in every browser/app/device you use and message deletions are not synced.
Indeed it does. That is the most requested feature after E2E encryption and publishing messages from the app itself. See https://github.com/binwiederhier/ntfy/issues/159 and +1 it if you want it too.
Suuuuper cool thanks for sharing this. Gonna see if I can use this to push notify when my DNS fails to reach my hobby server cause my ISP has changed my IP.
I was adding a new application (i.e. a topic) to on my own instance today. Gotify is Go binary to run with very little configuration. It has an Android app to get somewhat realtime notifications on the phone. Probably an iOS one too. It also has a pretty extensive REST API to manage the instance and a management web app.
Oh dang, just last week I started working on my own version of this [0]. Quite fun to hack on! Been thinking about what could be done to really differentiate.
Anyways, it's amazing that this is free! Very clean, very well done... bravo :)
I use textbelt.com to send text from my various test processes. It isn't free; it isn't even the cheapest. But, I can send 700 texts for $10, or about 1.5 cents per text. That is less than a second of my salary. Not worth my time to cut the cost further.
I use Twilio SMS API for the same purpose.
Great concept but I can't stand cluttering my phone (used to have PushBullet before). I also find SMS more reliable since iOS can throttle push delivery depending on your interactions.
> 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.
It is an UnifiedPush distributor, so it can replace FCM for applications supporting it. Here are most of the applications supporting UnifiedPush right now: https://unifiedpush.org/users/apps/
This is the way. UnifiedPush is sllooowly becoming more popular. Element (Matrix chat app) just added official support for it, which is super cool. And you can use ntfy as a distributor.
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.
Another alternative: you can send notifications to your phone through text messages. Text messages are compatible with email, usually in the form of <number>@<special-provider-url>.
Not OP but, for a while you could email a message to 5559991212@verizon.net and it would send a text to the phone number 555-999-1212. Not sure if it still works that way though.
I've been using a personal slack instance essentially to do this (leveraging it as a notification centre is actually kind of trivial). I absolutely be looking at this however.
Keep at it... it's important to have multiple options, and I know the OP would likely encourage you to keep at it. Of course, make it open source as they did, if you can. :-)
I made a simple virtual assistant app that does most of this stuff for me (i.e. notifications, two-way communications), with an API that can tie into other small projects - I've always assumed most developers have something like this of their own, i.e. some sort of Jarvis
not sure why "phone" is in the title of this post, but it appears to work well.... I would rather use a E2EE messenger for things like this though (chatting with myself)
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.
> 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.
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.
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.
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?
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.
> 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.
>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.
> 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).
> 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.
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.
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
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.
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".
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?
Encryption by default eliminates the biggest advantage: simplicity. But as an option, it's an useful addition that will be implemented sooner or later.
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.
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.
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