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.
Pretty much every app I have has delayed notifications, and no matter of battery optimization settings can fix it.
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.
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.
Unfortunately the security/usability tradeoffs mean it never was going to hit Whatsapp levels of use, but it certainly fills an important niche.
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
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.
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?
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.
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.
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).
BLE/LoRa/radio/internet mesh with reticulum that combines chat, social and torrents over NOSTR (decentralized protoocol).
Still beta, around August should be stable.
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.
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.
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.
I saw it shared at dweb camp and it seemed like a pretty long term serious project for P2P.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Source?
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.
And I would like if someone could please confirm is this related to literal code problems or systemic problems with Apple and Google?
This is a quick update about the status of Briar. Short version: the project is still active but we’re only making essential security updates and bugfixes for now.
Long version:
For several years we’ve been trying to find solutions to some of the longstanding issues with Briar, such as high battery usage and unreliable background operation on Android, missing features like account backup and file attachments, and a difficult user experience for adding contacts and communicating offline.
We considered completely rebuilding the application from the ground up, or even splitting it into separate applications for online and offline use. Meanwhile, the project didn’t have funding, we were reluctant to look for funding without having a long-term plan, and so we could only work on Briar in our spare time.
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. We worked on releasing a final update for Android and desktop to allow the app to remain functional for as long as possible. In the meantime we were hearing a lot of supportive words from people we had told about our decision, and the app continued to attract new users. So finally we decided to continue the project in maintenance mode. We’re only making essential security updates and bugfixes for now, but eventually we hope to make some incremental progress on those longstanding issues.
We’re sending out this update because some rumours have been circulating that the project is shutting down, based on conversations we had with people in the internet freedom and privacy community last year. Those rumours are out of date: the project is continuing.
Briar has received funding from the Small Media Foundation, the Open Internet Tools Project, Access Now, the Open Technology Fund, the Prototype Fund, Internews, the NLnet Foundation, the Next Generation Internet programme, the ISC Project and eQualit.ie.
Nico Alt <nico@briarproject.org> [PGP key]
Torsten Grote <torsten@briarproject.org> [PGP key]
Michael Rogers <contact@briarproject.org> [PGP key]
Mastodon: @Briar
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).
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.
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.
The 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.