Hacker News new | past | comments | ask | show | jobs | submit

Briar is in maintenance mode

https://briarproject.org/news/2026-maintenance-mode/
I've been attempting to build something similar and every time I take an honest look at the state of affairs on mobile phones I'm end up leaning towards running the way meshtastic users do: either strictly on dedicated hardware, or over a bluetooth link from my phone to dedicated hardware which I'll keep in my backpack or glovebox.
Sounds like it's basically dead. The issue with messenger apps is that they're a dime a dozen, there are so many of them and they offer so much variability in security, privacy, but most importantly usability and uptime. If your friends won't switch to them, there's almost no point in having them or using them.
loading story #48921238
> unreliable background operation on android

Pretty much every app I have has delayed notifications, and no matter of battery optimization settings can fix it.

Some time back, I had a similar problem: the LineageOS Messaging app was frequently late with SMS notifications when the phone was in idle state. Adding the package to Android's deviceidle whitelist fixed it right up. (This had to be done with the dumpsys shell command, since the setting for com.android.messaging was not exposed in the GUI.)

https://source.android.com/docs/core/power/app_mgmt#testing-...

I wonder if this setting could help Briar, and if so, whether an equivalent could be built in to their app packaging so users wouldn't have to fiddle with it.

Do you use VPN? This is a common misconfiguration of a server-side NAT related to too long or too short NAT timeouts combined with "act like a blackhole if we don't know anything about this connection".
It seems to me this only happens if you don't use the app much. Or maybe some apps are "allowlisted", I've never had delayed WhatsApp/Slack notifications.
loading story #48922918
loading story #48922547
loading story #48922614
loading story #48922490
loading story #48925718
Briar will thrive once EU Chat Control 2.0 passes, P2P E2E encryption is the only way to bypass bullshit laws.
loading story #48922240
loading story #48923271
loading story #48922409
loading story #48922129
loading story #48924198
CIA funding dried up. Briar had already started development when Starlink wasn't even a concept. Nowadays every CIA goat herder has their own Starlink terminal.
loading story #48922295
loading story #48923556
> We considered completely rebuilding the application from the ground up, or even splitting it into separate applications for online and offline use

This is actually non-trivial. There's an app I was working on where I wanted to have a local first mode that allowed people to use the app for free without an account and there was also a cloud hosted version that allowed for team collaboration, etc.

For this kind of thing to work chunks of the app essentially need to be written twice. So, not fun.

loading story #48921736
loading story #48922254
That's too bad. Anyone know of a fork or similar project? Maybe Meshtastic/MeshCore/BitChat. Berty Messenger's last update on iOS was in January 2025.
loading story #48921605
loading story #48922504
It's really sad that both Apple and Google make it so difficult for background processes to run with user consent. The app wasn't even available for iOS because they don't allow apps to listen for messages outside the walled garden's polling service.

Briar is a messenger app that worked on local networks, over Bluetooth, and over Tor if traveling the Internet. Fully encrypted and the purpose was decentralized, serverless messaging.

I liked the concept, and tested it out a little on my Android devices. But it looked straight out of 2009, and it had the issues described in the post. Still. Thanks for the work. I hope it can get revived or inspire others some day.

P.S. feature request! If Alice, Bob and Charlie are all contacts with each other, and Alice writes an offline message to Charlie, Alice should be able to opportunisticly hand the encrypted message to Bob on their shared network, and Bob can deliver it to Charlie.

loading story #48921657
loading story #48922442
loading story #48921925
This is what happens when no-one pays for their tools and I expect this to happen when more software becomes AI assisted.

The truth is donations do not work for tiny open source projects in the long term and even when Briar was quietly building for many years, it is clear that it is not enough.

I doubt that Briar saw much usage at all.
So?

Does that negate any of the points?

I don't think "That's what happens if Users don't pay for Software" is a good point, when talking about a messenger who had almost no regular users
> no regular users

Source?

TIL Briar is text-only, per https://eylenburg.github.io/im_comparison.htm
loading story #48922326
> Last year, we decided that we wouldn’t realistically be able to solve these issues and so we reluctantly decided to shut down the project.

If these are actually the problems, then why not throw 200 dollars of GPT 5.6 at these instead of shutting it down? Were these systematic problems (Apple/Google hegemony, for example) that couldn't be beat with code?

Try it. The AI will probably tell you that it's, of course, doable. You would have to start by making your own AOSP distribution and require an unlocked bootloader to even attempt to install it. You definitely can throw an AI agent at the problem, but a) it'll be significantly more than $200, no matter how you cut it; b) you'll end up with tens to hundreds of kloc of AI-generated code in a security-conscious context; and c) you can forget about having more than a handful of the most desperate users[1]. Both b) and c) are fatal for a project like this.

The locking down of the Android platform, IME, is a massive, decade-long process[2] with "full speed ahead" corporate backing. Even just a few years ago, you could maybe code around some of the restrictions (if supported by users going into settings and tapping some checkboxes); today it's impossible even with root. To get working "push notifications" outside of the official channel, you need to hack the support into the OS - or accept that you probably will get the notification, but it can be anytime from a few minutes to a quarter hour before your app receives it.

[1] In which case, making them use tens of thousands of AI-generated code "for security" is a clear moral hazard you probably don't want to walk into.

[2] I don't want to judge whether it's a move in the right direction or not - that's a separate matter. But it is happening.

loading story #48923040
Fighting complex technical and non-technical issues "with code" may be the most programmer way of thinking about things.

To begin with, that 200 dollars need to come from somewhere. Are you going to personally contribute to that 200 dollars? If not, someone needs to find money from somewhere. Then, I can assure you it's going to be much more than 200 dollars before you realize it.

Who spent the time to make this? If those people spent countless hours doing it by hand, maybe they would be willing to spend an analogous resource? It seems reasonable to me if you've already invested so much and paid in time.

But yeah that's why I was asking if this was a non-code issue? Because they're presenting it as hey, we couldn't figure out the battery life in this post.

$200 mean very different things to different people.

I would never say it's "reasonable" to expect anyone (including maintainers) to contribute money or code to an open source project.

Must be easy for you to type these things from your comfortable armchair.

So what's the point of spending months and months and months of your time just to shut down your project when it could possibly be worked out for several $100? Is the situation that the authors have a lot of time and no money? Could we get the project some money if that's the case? Apps like this are so important. Every year they become more critical.

And I would like if someone could please confirm is this related to literal code problems or systemic problems with Apple and Google?

Because it is security-critical code. Throwing 200 dollars at anything that isn't a competent human developer is not only a waste of money, but will tarnish a very reputable project.
I agree. These are classic problems where LLMs really shine. I would be very surprised if GPT-5.6 couldn't fix them.
From the minimal context I got, it seems like there are underlying platform access problems in the way. In my experience, attempting to work around these issues is demoralizing.
Claude, Copilot or JetBrains AI could also do it
Emacs with `M-x make-android-bg-app-responsive-dwim` too!
Give that a try and let us all know how it goes. :)
I would imagine pretty good if it's actually just a code issue
It's not. Modern Android is increasingly limiting what apps can do. It's a "code issue" in the sense that you can clone the Android sources, overhaul security and power management systems, and build your app to run on that. It'll work. It's doable. Would that be a solution for this project, though?
Well, no. If the project is being shut down because its target(s) went away, then that seems unavoidable.

It would be good, IMO, if people could come together and build out an open mobile platform not subject to SV hegemony, so I think what you're saying is the way to go, actually. Because building out AOSP and or just something forked/from scratch is... actually... accessible now in my opinion. I think it doesn't make sense _not_ to be oriented in this direction anymore. There's no reason to remain cautious because, well, right now we have _nothing_ :(. We are subject to the fancies of the behemoths that exist to self perpetuate. Working around them and depending on them is demoralizing and not fun.

It's a privacy-focused application for secure communication, last place you want slop.
To me I seems like it was an attempt at a privacy focused application for communication, but it's now in maintenance mode.