Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Briar is in maintenance mode

briarproject.org

Post reply on HN
Print view View original

61–70 of 114 posts

Re: Briar is in maintenance mode

#61

Post by fwip »

rglullis wrote: post #51
embedding-shape wrote: post #8

Earlier quoted context omitted.

For most IMs I agree, Briar is/was slightly different though, being P2P and E2E encrypted. There isn't many IMs out there supporting Bluetooth connections between users for example.

Being p2p, network effects are even larger: you have to convince not only your own friends to install and use, but also rely on enough density in your area?

You only need to rely on density in your area if you have no other network - it will happily use mobile data or Wifi connections if you have them.

Re: Briar is in maintenance mode

#62

Post by monkaiju »

nunobrito wrote: post #13
HelloUsername wrote: post #5

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.

Instead of a fork, there is completely new development going on here: https://github.com/geograms/aurora BLE/LoRa/radio/internet mesh with reticulum that combines chat, social and torrents over NOSTR (decentralized protoocol). Still beta, around August should be stable.

No way am I going to trust a heavily LLM-generated app as a replacement to Briar...

Re: Briar is in maintenance mode

#63

Post by dewey »

copperx wrote: post #38
embedding-shape wrote: post #8

Earlier quoted context omitted.

For most IMs I agree, Briar is/was slightly different though, being P2P and E2E encrypted. There isn't many IMs out there supporting Bluetooth connections between users for example.

Bitchat is great, but I don't understand why it's Bluetooth only. I would think Wifi reaches further.

Because Bluetooth has a low energy mode which it uses.

Re: Briar is in maintenance mode

#64

Post by foresto »

nubinetwork wrote: post #3

> 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 was 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.

Re: Briar is in maintenance mode

#66

Post by unethical_ban »

Evanito wrote: post #40
unethical_ban wrote: post #6

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, server…

> 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. This is intentionally only included in Forum-mode chats in Briar. Over direct message, leaking contacts is considered a breach of security. (Your definiti…

That's a fair point.

The use case for allowing 1:1 DMs to be exchanged via courier is to maximize OpSec for whatever messages are being exchanged - I may trust Bob to deliver a message, but Bob may not need to know the message content.

The feature could include marking "approved couriers" per contact, perhaps? Both Alice and Charlie would have to set Bob as an approved courier for message exchange to each other.

Re: Briar is in maintenance mode

#67

Post by davexunit »

I sympathize with the developers. Mobile OS push notifications are a big impediment to the adoption of p2p technology and it's hard to do anything novel in the chat space because there's a million chat apps.

Re: Briar is in maintenance mode

#68

Post by klibertp »

timcobb wrote: post #58
klibertp wrote: post #48

Earlier quoted context omitted.

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;…

Thank you! So in your mind, it would be a big investment of human time/tokens and the big obstacle, ultimately, is Big Tech?

Well, I really don't want to put the blame on anyone. Misbehaving apps on casual users' phones are a legitimate problem, and the OS is expected to mitigate that. Moreover, there are not many proven models for that, and they all entail compromising someone's convenience (either users', devs', or both). You can't have your cake and eat it, too.

In this specific case, though - especially given that the project had no iPhone version due to technological constraints - Android as a platform moving in that direction is probably the biggest reason why it became too hard to develop the project further. And the direction of Android development is set by BigTech, so you probably could justify calling them "the big obstacle".

It's important to note that the movement towards security-by-default is larger than just some subset of BigTech. It's how the whole industry tries to cope with computing becoming ubiquitous and trusted at the same time. It's Eternal September, but now the new users have banking apps on their phones. It's a hard problem, and every attempt to date has always resulted in users and developers losing some freedom. This OP just highlights the consequences of this movement for a particular project.

Re: Briar is in maintenance mode

#69

Post by fwip »

monkaiju wrote: post #62
nunobrito wrote: post #13

Earlier quoted context omitted.

Instead of a fork, there is completely new development going on here: https://github.com/geograms/aurora BLE/LoRa/radio/internet mesh with reticulum that combines chat, social and torrents over NOSTR (decentralized protoocol). Still beta, around August should be stable.

No way am I going to trust a heavily LLM-generated app as a replacement to Briar...

Claude is the only contributor? 100% vibed.

Re: Briar is in maintenance mode

#70

Post by klibertp »

timcobb wrote: post #60
klibertp wrote: post #50

Earlier quoted context omitted.

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 ma…

> It would be good, IMO, if people could come together and build out an open mobile platform not subject to SV hegemony

From what I understand (based on pretty basic research into using old smartphones (which I already have a full drawer of) as home appliances), the main problem is that device manufacturers only provide binary blobs for drivers and firmware, and they are not too happy to share them with non-Google parties. And it's non-trivial to handle those blobs, even if you get them (they weren't written for your tech stack, so you need infrastructure around them to make them useful).

> Because building out AOSP and or just something forked/from scratch is... actually... accessible now in my opinion.

Starting such a project, and even getting to 0.0.1 release, is now simpler than any time in the past.

Getting from 0.0.1 to 1.0-alpha did not get any easier at all. The current AI requires both a great harness and a skilled operator to add meaningful code to a large project without going nuclear on code quality.

It'll be quite a few years until things like "make me a custom ROM with AOSP modified to do X" result in anything other than absolute tragedy.

> 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.

That's true, especially the "not fun" part. However, I expect the vast majority of users don't want any fun on their devices, aside from games (and even then, only with kernel-level anti-cheat). Normally, this is solved by companies offering one product for "casuals" and another for devs or power-users. This works, but breaks down for social things: a messaging app that won't run unless you buy a Pixel and flash a custom ROM is DOA as an app (it might function as a solution in case of people who are really desperate for the features the app provides, but that's probably too small a population to keep the project afloat).

Post reply on HN