I saw it shared at dweb camp and it seemed like a pretty long term serious project for P2P.
Unfortunately the security/usability tradeoffs mean it never was going to hit Whatsapp levels of use, but it certainly fills an important niche.
Pretty much every app I have has delayed notifications, and no matter of battery optimization settings can fix it.
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.
I don't know exactly what the option is called but since Android 8 there is at least a toggle there per app. Later versions have lots more settings.
Unused apps also indeed go in different App Standby buckets, which while it shouldn't affect FCM notifications, it does on some older android versions (https://developer.android.com/topic/performance/power/power-...)
If you're not using FCM, well you're limited to having to check for notifications yourself, either within doze windows, or by registering a foreground service that keeps your app alive and checking.
If the goal is messaging that avoids government spying or censorship its a lost cause - the government would simply compel Apple to pull the app in their jurisdiction.
Also, how do you avoid leaking the sender? You can avoid giving Apple that information by routing the notification through a server, but then that server would know the sender and recipient.
because without such a critical mass of normal users you get something like tor or grapheneos that the state begins to associate with people engaging in unsavoury activity
Can the Starlink radio be sniffed? If so, it might act like a beacon, a tell-tale sign (especially, in countries where Starlink is illegal).
Any service like Briar that wants to sit atop base smartphones will need to deal with this tension. A fallback is to poll intermittently for new messages, which when tuned correctly can indeed be fairly battery life forward. Of course then your messaging experience is lower bounded by your refresh interval. Modern smartphone OSes also will ruthlessly cut long-running connections in the face of power-save events on device.
In general I think an external radio that you connect your smartphone to via Bluetooth, like Meshcore or Meshtastic, is a better experience overall than simply using a smartphone. Dedicated radios keep smartphone batteries topped up, and having the option to setup an antenna means that if you happen to be in an area where permanent radio setup is plausible, you can lean on good site characteristics, antennas, and filters. It’s hard for a government to ban radios altogether and ISM-ish band devices have a variety of uses in pretty much any developing or developed country (often used in small things like meters or monitors.) And for folks who just some off-grid data capabilities, this approach offers high flexibility without the burden of licensing.
For folks considering going into this, I suggest joining Meshtastic or Amateur Radio communities. I find the further you get from amateur radio or networking communities (mesh* communities have a mix of folks and some can have pretty poor understanding of how radios work), the more the information becomes unreliable and more suffuse with political/social goals than matters like understanding signal propagation or congestion. If you’re in a developed country, Amazon likely has all you need to get started with the Mesh* world of LoRa UHF radios.
It could if we’d never broken the full end to end principle and put stateful firewalls and NAT in front of everything, but that ship has sailed. All net connections require keepalive or a firewall will close them. This is even true these days in the cloud for the most part unless your machines are “naked” VMs directly on the globally routed Internet.
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.
BLE/LoRa/radio/internet mesh with reticulum that combines chat, social and torrents over NOSTR (decentralized protoocol).
Still beta, around August should be stable.
I'm a dinosaur but you remind those complaining in the 90s that Turbo Pascal wasn't real programming because it was too easy to copy code and compile.
I don't have a team of developers nor funding to hire them. AI amplifies by 26 times what I can do in a year. It was never about the code, what matters is what you do with it.
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.
This P2P system would probably only work if implemented by Google/Apple themselves and they have zero desire to do so since it's a feature almost no one would want.
This is intentionally only included in Forum-mode chats in Briar. Over direct message, leaking contacts is considered a breach of security. (Your definition of "leak" may differ.) In group messages, only the group admin is considered trusted, and every message must go directly to or come from them.
In every security tradeoff, Briar chose the option that maximizes security, even considering how the airwave transmission times might be fingerprintable as Briar traffic.
Not saying any of this is a good way to make a useable app for wide adoption, but it is intentional and highly opinionated.
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.
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.
Does that negate any of the points?
Source?
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?
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.
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.
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.
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.
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.
And I would like if someone could please confirm is this related to literal code problems or systemic problems with Apple and Google?
If you don't know what open source software is or how projects are typically run (including where the funding, if any, comes from), educate yourself before posting meaningless texts in a forum.
> educate yourself before posting meaningless texts
Sorry, but you are being a jerk.
They just ask why someone putting so much effort into a project would not want to spend 200$ on saving it. That is a totally fair question. And you seem to be completely missing why spending 200$ on AI wouldn't solve the problem. Which is okay. But being a jerk while being wrong is not a good combination IMO.
In my opinion, the answer is that it's just a lot more complicated than it may sound. Using an AI may make them more productive, sure, but it will still be a lot of work.
It feels like they just haven't reached critical mass. Briar is a great idea, but if not enough people are willing to use it (and donate to it), then it cannot succeed, right? And the fact that they considered rewriting it from scratch means that it's not only a question of user base: there are fundamental problems that aren't easily solved.
P2P is just hard, as proven by the fact that there is almost no example of successful P2P system in the wild.
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 would, but I would argue that it wouldn't solve Briar's problem here.
The problem on Android is not that Google doesn't want P2P to work. It's that Android optimises aggressively for the battery. You can install a mobile Linux and run a P2P service on it, that's not a problem at all. But you will have to charge it multiple times a day, and nobody wants that from a phone.
Have you ever tried running an Android-based system without the Play Services (and without migroG)? Try running e.g. Signal without FCM, and see the impact on your battery life. You want to fork the OS to solve that? You will probably end up rebuilding something as centralised as FCM.
There is a fundamental question there: does it work, without major downsides, to have a P2P system where the nodes are mobile phones? Until now it has always been a tradeoff, and people clearly choose battery life. Also you don't need P2P for privacy.
> There's no reason to remain cautious because, well, right now we have _nothing_
Android is open source. There are big alternatives like LineageOS and GrapheneOS. I don't think we have nothing. There is a lot of great technical stuff in Android/iOS. While iOS is out of bounds because proprietary, Android is open source, so we have all that great stuff. We don't have nothing.
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).