ntfy.sh v2.18.0 was written by AI
-
According to the release:
Adds experimental PostgreSQL support
The code was written by Cursor and Claude
14,997 added lines of code, and 10,202 lines removed
reviewed and heavily tested over 2-3 weeks
This makes me uneasy, especially as ntfy is an internet facing service. I am now looking for alternatives.
Am I overreacting or do you all share the same concern?
They are not even trusting it themselves. This is from the release notes
I'll not instantly switch ntfy.sh over. Instead, I'm kindly asking the community to test the Postgres support and report back to me if things are working
Fuck that.
-
I was also using it for notifications but I'll probably switch to E-Mail for that and find an alternative UP distributor.
Conversations is working very well on my phone as UP distributor.
-
According to the release:
Adds experimental PostgreSQL support
The code was written by Cursor and Claude
14,997 added lines of code, and 10,202 lines removed
reviewed and heavily tested over 2-3 weeks
This makes me uneasy, especially as ntfy is an internet facing service. I am now looking for alternatives.
Am I overreacting or do you all share the same concern?
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
Fewer Letters More Letters DNS Domain Name Service/System Git Popular version control system, primarily for code IP Internet Protocol MQTT Message Queue Telemetry Transport point-to-point networking NAT Network Address Translation XMPP Extensible Messaging and Presence Protocol ('Jabber') for open instant messaging
6 acronyms in this thread; the most compressed thread commented on today has 8 acronyms.
[Thread #146 for this comm, first seen 8th Mar 2026, 10:40]
[FAQ] [Full list] [Contact] [Source code] -
Definitely share your initial concern. Without strong review processes to ensure that every line of code follows the intent of the human developer, there’s no way of knowing what exactly is in there and the implications for the human users. And I’m not just talking about bugs.
They say it’s reviewed, but the temptation to blindly trust is there. In this case, developer appears to have taken some care.
The code was written by Cursor and Claude, but reviewed and heavily tested over 2-3 weeks by me. I created comparison documents, went through all queries multiple times and reviewed the logic over and over again. I also did load tests and manual regression tests, which took lots of evenings.
Let us hope so. Handle with care to ensure responsibility is not offloaded to a machine instead of a person.
The size of that changeset means that it’s inherently unreviewable.
The commit history is something I’ve seen only in the PRs that even the most dysfunctional companies would demand a rewrite for.
Also, 2-3 weeks review? PostgreSQL support could be added in that time without the need for a damn „vibe check”. Hell, it would probably take less time than that.
-
Send push notifications to your phone or desktop using PUT/POST
I'm sorry, how many lines of code for that?
if you want to send one notification from your desktop to your phone, it's easy. but from any device to (m)any other, with guaranteed delivery and no doubles? shit gets complicated.
-
The size of that changeset means that it’s inherently unreviewable.
The commit history is something I’ve seen only in the PRs that even the most dysfunctional companies would demand a rewrite for.
Also, 2-3 weeks review? PostgreSQL support could be added in that time without the need for a damn „vibe check”. Hell, it would probably take less time than that.
To be fair they would have needed to spend time testing the manual implementation as well.
The problem I see mainly is that even if this rolls out perfectly, the erratic and changing nature if llms still make it pointless as a proof of concept. Next time Claude might fuck up in a fringe way that's not covered by unit tests and is missed by manual tests.
On the other hand I guess I've been guilty myself on numerous occasions to implement fringe bugs into production code, but at least I learn from it.
-
They are not even trusting it themselves. This is from the release notes
I'll not instantly switch ntfy.sh over. Instead, I'm kindly asking the community to test the Postgres support and report back to me if things are working
Fuck that.
Classic "test in production" strategy, very solid!
-
if you want to send one notification from your desktop to your phone, it's easy. but from any device to (m)any other, with guaranteed delivery and no doubles? shit gets complicated.
So it's a little more than just sending notifications, then.
-
So it's a little more than just sending notifications, then.
no, it's literally all in service of sending notifications. but there's a lot involved. android doesn't have a way to receive them natively for example, you need to go through google's services. so ntfy has to emulate the firebase api. then there's the "exactly once" requirement, which is basically the two generals problem turned up to eleven because every platform syncs differently and you need some way to store messages that are in the process of transmitting. then there's the matter of punching through NAT, so you need a STUN/TURN setup on the server.
and that's on top of the fact that every platform requires different build options, manifests, certificates, etc.
-
To be fair they would have needed to spend time testing the manual implementation as well.
The problem I see mainly is that even if this rolls out perfectly, the erratic and changing nature if llms still make it pointless as a proof of concept. Next time Claude might fuck up in a fringe way that's not covered by unit tests and is missed by manual tests.
On the other hand I guess I've been guilty myself on numerous occasions to implement fringe bugs into production code, but at least I learn from it.
I made my statement as a BDD/TDD practitioner.
The code goal of software engineering is not to deliver said code, but to deliver it in a framework that lets others—and consequently me in a week’s time—to contribute easily. This makes both future improvements and bug fixes easier.
Dumping a ~25000 lines changeset with a git history that’s almost designed to confuse is antithetical to both engineering and open source.
-
According to the release:
Adds experimental PostgreSQL support
The code was written by Cursor and Claude
14,997 added lines of code, and 10,202 lines removed
reviewed and heavily tested over 2-3 weeks
This makes me uneasy, especially as ntfy is an internet facing service. I am now looking for alternatives.
Am I overreacting or do you all share the same concern?
I just set up a ntfy server for Unified Push earlier this week to use with Matrix. Now I have to turn around and immediately replace it...
-
Yeah, this is now inherently untrustworthy. Better to switch to an alternative.
Do you know any? I've never really looked beyond ntfy.sh until now
-
According to the release:
Adds experimental PostgreSQL support
The code was written by Cursor and Claude
14,997 added lines of code, and 10,202 lines removed
reviewed and heavily tested over 2-3 weeks
This makes me uneasy, especially as ntfy is an internet facing service. I am now looking for alternatives.
Am I overreacting or do you all share the same concern?
Definitely time to find an alternative. What the actual fuck is this
-
According to the release:
Adds experimental PostgreSQL support
The code was written by Cursor and Claude
14,997 added lines of code, and 10,202 lines removed
reviewed and heavily tested over 2-3 weeks
This makes me uneasy, especially as ntfy is an internet facing service. I am now looking for alternatives.
Am I overreacting or do you all share the same concern?
NOOOOOOOOO
-
According to the release:
Adds experimental PostgreSQL support
The code was written by Cursor and Claude
14,997 added lines of code, and 10,202 lines removed
reviewed and heavily tested over 2-3 weeks
This makes me uneasy, especially as ntfy is an internet facing service. I am now looking for alternatives.
Am I overreacting or do you all share the same concern?
Oh ffs..
Thanks for the heads-up
-
Do you know any? I've never really looked beyond ntfy.sh until now
I only know NextPush (Nextcloud App), but there is also something called Autopush I think?
-
Classic "test in production" strategy, very solid!
Test in production is the best. We spent months warning from data bugs and nobody bat an eye (upstream bug, not our responsibility but we noticed)
When it was d launched in prod we just pointed out the bug that nobody fixed was still there and immediately a war room was formed and the bug fixed within an hour.It honestly seems more efficient to let shit hit the fan than to fight everybody to do their job.
-
I just set up a ntfy server for Unified Push earlier this week to use with Matrix. Now I have to turn around and immediately replace it...
Same here. Literally just set it up and now this.
I hope the author will roll this back or someone else makes a fork. I don't want to immediately switch technology to XMPP/Matrix/... and have to do it all over again.
-
Test in production is the best. We spent months warning from data bugs and nobody bat an eye (upstream bug, not our responsibility but we noticed)
When it was d launched in prod we just pointed out the bug that nobody fixed was still there and immediately a war room was formed and the bug fixed within an hour.It honestly seems more efficient to let shit hit the fan than to fight everybody to do their job.
You're implying a shitty capitalist company that nobody cares for if it burns down. A tool like this though that is self-hosted by a lot of people (29.1k stars on GH!) and that is internet-facing is very different.
-
Test in production is the best. We spent months warning from data bugs and nobody bat an eye (upstream bug, not our responsibility but we noticed)
When it was d launched in prod we just pointed out the bug that nobody fixed was still there and immediately a war room was formed and the bug fixed within an hour.It honestly seems more efficient to let shit hit the fan than to fight everybody to do their job.
For sure, the song of the hero who fixed the production bug is oft sang at meetings but the loser who prevented the bug to begin with gets no credit.
