ntfy.sh v2.18.0 was written by AI
-
Read the README
-
The app itself might be fine, but you are either using the Mozilla services or the backend written by Mozilla. Sadly Mozilla has lost all the good will it had and is just another silicon valley AI company these days, and seems to prefer it that way.
Sure. All I said was that it doesn't actually seem to be run by Mozilla, like you implied it was.
-
Any AI usage immediately discredits the software for me, because it calls into question all of their past and future work.
Oh boy, do I have bad news about 90% of the internet for you...
-
the linux kernel is on that list, bro it's time to switch!
Time to switch to Plan9!
-
I think there's room for a little bit of nuance that page doesn't do a great job of describing. In my opinion there's a huge difference between volunteer maintainers using AI PR checks as a screening measure to ease their review burden and focusing their actual reviews on PRs that pass the AI checks, and AI-deranged lone developers flooding the code with "AI features" and slopping out 10kloc PRs for no obvious reason.
Just because a project is using AI code reviews or has an AGENTS.md is not necessarily a red flag. A yellow flag, maybe, but the evidence that the Linux Kernel itself is on that list should serve as an example of why you can't just kneejerk anti-AI here. If you know anything about Linus Torvalds you know he has zero tolerance for bad code, and the use of AI is not going to change that despite everyone's fears. If it doesn't work out, Linus will be the first one to throw it under the bus.
Lol my project has an AGENTS.md and its contents are basically, "Don't use AI agents on this codebase."
-
Oh boy, do I have bad news about 90% of the internet for you...
Linus sent an email recently to the Kernel Mailing List trashing AI slop and rejecting AI generated patches. The fact that he used it to play around with a script doesn't invalidate the fact that he distrusts code written by LLMs when it actually matters.
-
Classic "test in production" strategy, very solid!
Consider a donation to help people providing you the open source software you seem to depend upon.
Usage of a helper tool to perform tasks on code whether it is AI or the IDE internal features can reduce the work load of benevolent developers who has not asked you to use their softwares.
Maybe the language was not appropriate but get real. With the little revenue generated by the usage of people complaining, the use of AI agentic coding might be the only way to bring features without pushing benevolent devs to burnout.
Edit: to bring, not to being!
-
Linus sent an email recently to the Kernel Mailing List trashing AI slop and rejecting AI generated patches. The fact that he used it to play around with a script doesn't invalidate the fact that he distrusts code written by LLMs when it actually matters.
you mean this statement? https://www.theregister.com/2026/01/08/linus_versus_llms_ai_slop_docs/?td=rt-3a
If yes, your statement does not really match what Linus said.
-
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.
Testing in production is the most idiotic last 10 years or so concept, which is mainly driven by incompetence of project managers.
Imagine if you get sold a car by a company, for 100k, then it starts having major issues and the car company tells you: "we'll fix it".
While that does not necessarily apply to software or services or webapps, the logic still stands. You are selling bugs to people. Bugs that could have been cought, with some risk management and planning.
Edit: F-ing ios keyboard.
-
been using EMQX plus an MQTT client on my phone for a few months now, I like it better than gotify since the app was chewing through my battery like a vampire.
it might be better now since my issues happened three-ish years ago.
This EMQX?
Seems it's no longer FOSS?
I've been using Gotify for a few notifications from Home Assistant and it doesn't appear to be eating my battery.
It's a little more responsive than ntfy - sometimes ntfy doesn't alert for ages after the trigger (could be phone power saving the wifi...), but then I also get realerts from yesterday.... not had that with Gotify.
-
This EMQX?
Seems it's no longer FOSS?
I've been using Gotify for a few notifications from Home Assistant and it doesn't appear to be eating my battery.
It's a little more responsive than ntfy - sometimes ntfy doesn't alert for ages after the trigger (could be phone power saving the wifi...), but then I also get realerts from yesterday.... not had that with Gotify.
that's the one.
FOSS or not, it still runs just fine on my infra. I prefer it over something like rabbitmq because it has a pretty slick admin webgui.
I'll have to give gotify another try.
-
Testing in production is the most idiotic last 10 years or so concept, which is mainly driven by incompetence of project managers.
Imagine if you get sold a car by a company, for 100k, then it starts having major issues and the car company tells you: "we'll fix it".
While that does not necessarily apply to software or services or webapps, the logic still stands. You are selling bugs to people. Bugs that could have been cought, with some risk management and planning.
Edit: F-ing ios keyboard.
which is mainly driven by incompetence of project managers.
I completely agree. I work on an internal solution, which is a part of a very large product. It's not a live product, only part of a pipeline that runs on a predetermined schedule. Our bit is the only one with actual business/performance KPIs, most of the other teams measure only "user story/CR points". If the other teams screw up, it will impact our performance unless we prove it's their fault. And of it's their fault, they open a US/bug which improves their metrics (one more US closed).
Our team has to think ahead and try to do things well in one go, because our bugfixing doesn't count as work. But our speed is measured against people who benefits from half doing stuff.
When we did massive effort, we got complaints we were slow. Now we do less effort and once every blue moon we have to do a hotfix.
Most often than not when we have an production issue is due to the other teams that run before us on the pipeline, so we even had to develop checks to our input because they won't add checks to their outputs. And they won't because that's a CR that requires extra funding that's not approved, but we had to create them for our own sanity.Yes, I'm looking to move out haha
-
Do you know any? I've never really looked beyond ntfy.sh until now
I recently switched to gotify. Push notifications to iOS aren’t as good but I’m happy with it.
-
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'm so tired of that.
I'm using it for scripts notifications + unifiedpush. I don't know where to start to find the fitting alternative.
-
there is this repo that lists some slopware :
https://codeberg.org/small-hack/open-slopware
maybe someone can add itoh no. not ladybird! You were supposed to save us!
-
Consider a donation to help people providing you the open source software you seem to depend upon.
Usage of a helper tool to perform tasks on code whether it is AI or the IDE internal features can reduce the work load of benevolent developers who has not asked you to use their softwares.
Maybe the language was not appropriate but get real. With the little revenue generated by the usage of people complaining, the use of AI agentic coding might be the only way to bring features without pushing benevolent devs to burnout.
Edit: to bring, not to being!
You are completely correct, and to be honest I've tested commercial product features in prod as well on teams that have the capacity to handle it and make a living on it, unlike this maintainer.
I'm also experimenting heavily with vibe coding and I think it has many uses for a seasoned programmer while getting a lot of flak.
Of course there are issues and problems with it, but for me it had been helping out a lot.
-
I'm so tired of that.
I'm using it for scripts notifications + unifiedpush. I don't know where to start to find the fitting alternative.
If more people were contributing there wouldn't be a need for AI.
-
If more people were contributing there wouldn't be a need for AI.
Non-sense comment. The project was fine without AI. And it's so stupid: how do you expect people to contribute if there's only AI? How do you expect developers to learn to code if everything is 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?
"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."
This is the way.
-
It looks like that tool is more or less built by a single developer (you already trust their judgment anyways!), and even though the code came through in a single PR it was a merge from a branch that had 79 separate commits: https://github.com/binwiederhier/ntfy/pull/1619
Also glancing through it a bit, huge portions of that are straightforward refactors or even just formatting changes caused by adding a new backend option.
I'm not going to say it's fine, but they didn't just throw Claude at a problem and let it rewrite 25k lines of code unnecessarily.
Yeah, I mean, with or without AI, I've always only had a big pull request for releases, from a stable release branch into the main branch, the release branch would be a merge of various branches or just be worked on directly on various stages.
One big pull request doesn't really mean anything.
