Still sending, in maintenance mode
Briar lists a new release while keeping its maintenance limits visible. I want enthusiasm for private messaging to leave those conditions intact.
Briar’s homepage puts “Briar 1.5.22 (October 13, 2026)” just above a news item titled “Briar is in maintenance mode.”[1] I like seeing those statements together. A release number can suggest momentum; the notice makes a much narrower promise.
In that July 9 update, the developers say the project remains active but is making only essential security updates and bug fixes for now.[2] They also describe having decided the previous year to shut it down, then changing course after supportive responses and continued interest from new users.[2] Today’s release listing is new. The maintenance decision is not. I have read the public pages, not tested this build, and I am not treating the version number as evidence that Briar’s older problems have been solved.
What interests me is the choice to keep a limited service going after abandoning the ambition to fix everything. I feel relieved by the continuing support and uneasy about how much people may expect from it. A smaller promise can be honest and still leave someone with a difficult decision about whether to rely on the software.
Keeping a conversation reachable
Briar’s manual describes messages syncing directly between users’ devices, over Tor when the internet is available and over Bluetooth or Wi-Fi when it is not.[3] Those local connections do not give a phone a magical route across a continent. I would want anyone considering Briar for an outage to understand who they can actually reach, rather than carry away the comforting phrase “works without internet.”
The manual’s ordinary messaging instructions say that a message to an offline contact arrives the next time both people are online.[3] Briar Mailbox provides a separate arrangement: its helper app receives encrypted messages while Briar is offline and passes them on when it reconnects.[6] The project’s setup instructions call for a spare Android device linked to the account and left connected to power and Wi-Fi.[6]
I find that spare phone unusually revealing. Someone has to leave it plugged in. The wish to avoid a central messaging service does not make the work of staying reachable disappear; in this arrangement, part of it moves to equipment the user maintains.
I like having that option. I dislike any sales pitch that makes the effort sound negligible. An old device, a dependable connection, and someone willing to look after them are resources. A person choosing a private messenger should be able to weigh those costs without being treated as insufficiently committed to privacy.
Kim Key’s PCMag review, updated April 6, describes successful chatting on the same Wi-Fi network but also reports having to disable battery optimization on the test phone.[4] The developers’ later maintenance notice names high battery usage and unreliable Android background operation among the longstanding problems.[2] It also lists missing account backup and file attachments, plus difficulty adding contacts and communicating offline.[2] The review is useful independent experience, not a test of today’s release. The developers’ own account is the stronger reason not to wave those problems away.
For a messenger, background reliability affects whether silence means anything. Someone waiting for a reply may not know whether their friend is busy, their connection has failed, or the phone has stopped doing the work needed to receive a message. That uncertainty can matter more than an impressive feature list. It is one reason I cannot turn “the project continues” into an unqualified recommendation.
A smaller promise, taken seriously
The July account says the team considered rebuilding Briar from scratch or splitting online and offline use into separate applications.[2] It says the project lacked funding, the developers were reluctant to seek it without a long-term plan, and they could work only in their spare time.[2] Their hope for eventual incremental progress appears alongside the current maintenance limit, not as a dated commitment to deliver those changes.[2]
I am glad they published that distinction. I would rather read a disappointing support boundary than a roadmap whose confidence exceeds the time available to the people writing it. Keeping security work going has value even when the list of missing features remains largely intact.
There is a fair objection: people relying on communication software need more than admirable candor. If a tool remains hard to use or unreliable in their circumstances, its maintainers’ good intentions cannot make it suitable. I agree. A user leaving for something their contacts can run dependably has not betrayed an open-source project.
I would still be sorry to lose this option. Existing users may get considerable value from continued security work, even while deciding how long the current application fits their lives. I would welcome funding that gives the developers more room. That wish does not mean they owe a new application to everyone who wants one.
The account boundary is especially stark. Briar’s manual warns that an account lives on the device, not in the cloud, and cannot be recovered after uninstalling the app or forgetting the password.[3] That is a substantial condition to accept, not a footnote to the appeal of decentralization.
My preference is for a conversation about Briar that leaves these conditions visible. It can respect the developers’ decision to continue, acknowledge the benefit of direct private communication, and still let a prospective user decide that the upkeep or recovery limits are too much. Enthusiasm gets less useful when it makes that refusal embarrassing.
I came to the homepage because of a new version. The July notice held my attention longer. I want the next person looking at that download button to see it too.
Sources
[2] Briar: July maintenance-mode update
[4] PCMag: Briar review, updated April 6, 2026