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.
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?
Helene survivor here. I will be spreading the word about this project and keeping some APKs for if the shit hits the fan again. FDroid being able to sync between local devices means all you need is to get fdroid onto someones phone. Wish they had an iphone app though!
Anything that tries to read a "mailbox" on a smartphone is bound to run into difficulties. Smartphones manage to keep battery life high by keeping the modem inactive most of the time. The way to implement any mailbox functionality, i.e. an incoming message that needs attention, is usually done through a centralized push notification endpoint socket. Rather than wasting battery life polling multiple sockets, the OS listens to a single endpoint and farms out pushes that way. Of course to tune this precisely for battery life and for centralization of the platform, both Apple and Android have their own push notification services. Rooted or 3rd party smartphones can change the push notification service.
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.
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.)
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.
Not GP, but most of the apps I use that works without Google Play Services (specifically, FCM) have this problem too. Vendor-agnostic notification on Android, and as far as I know iOS, is still painful.
Ofc Slack and WhatsApp works fine : they use the Google notification system.
There should be a category: "Background Check" in the Android developer options. You can pretty finely tune or alter the automatically set priorities and permissions for background activity there.
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 use signal a lot (probably has 30-60 minutes screen time per day), and still notifications are extremely finicky no matter what battery optimization settings I tweak. So I'm leaning towards some apps being blessed
Briar is dead because it doesn't work on iPhones. It doesn't work on iPhones because iOS will only allow waking the app from background when there's a push notification. Push notifications have to go through Apple's servers, which defeats the purpose of a decentralized app where your messages (and metadata) can't be traced.
What about a "fake push" that does not leak message contents, sender etc.? Fuzz the time the push notification is sent by a random amount of time and you have something plausibly private given the constraints?
You're still dependent on Apple continuing to allow such a use.
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.
Briar is designed to work over 1) tor, 2) ad-hoc wifi, 3) bluetooth. None of those are going to be conducive to sending push notifications through Apple's servers.
That still exposes some metadata. Depending on your threat model, leaking the timing may or may not be a problem.
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.
Only, if they manage to improve it, so that regular photos and voice messages can be sent. I am mostly fine with texting only, but such things are an instant no-go for most people.
only insofar as it is 1. not illegal to do so or 2. the cost-benefit of violating such laws makes sense for the majority of users, who are not doing things that are actually illegal
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
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.
Plus people at the top level of the current administration just use Signal for discussing ongoing military operations and other classified stuff, so they don't see the need for solutions like Briar either...
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.
> 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.
Why? I use a similar model in a few mobile apps. Free, not logged in usage stores a restricted set of user activity data ephemerally (lost upon uninstall) in the phone. For subscribed users, this offline storage mechanism is still the primary storage mechanism, but then we add a cloud sync mechanism on top of it that enables usage across multiple devices and permanent storage in the cloud. Curious why you need to write the app twice when in my mind you are simply adding and enabling extra functionality on top of the core product.
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.
It's both sad and understandable. So many Applications would want to be running in the background for data collection reasons or just user responsiveness. While it could be a permission, after watching so many people just hand out "Sure, have my location always and forever" to any application that ask for it, the OS would get totally overwhelmed.
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.
> 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 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.
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.
> 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.
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.
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.
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.
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.
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 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).
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.
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?
Helene survivor here. I will be spreading the word about this project and keeping some APKs for if the shit hits the fan again. FDroid being able to sync between local devices means all you need is to get fdroid onto someones phone. Wish they had an iphone app though!
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.
Anyone have an idea how good https://qaul.net/ is?
I saw it shared at dweb camp and it seemed like a pretty long term serious project for P2P.
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.
Anything that tries to read a "mailbox" on a smartphone is bound to run into difficulties. Smartphones manage to keep battery life high by keeping the modem inactive most of the time. The way to implement any mailbox functionality, i.e. an incoming message that needs attention, is usually done through a centralized push notification endpoint socket. Rather than wasting battery life polling multiple sockets, the OS listens to a single endpoint and farms out pushes that way. Of course to tune this precisely for battery life and for centralization of the platform, both Apple and Android have their own push notification services. Rooted or 3rd party smartphones can change the push notification service.
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.
> 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.
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.
Not GP, but most of the apps I use that works without Google Play Services (specifically, FCM) have this problem too. Vendor-agnostic notification on Android, and as far as I know iOS, is still painful. Ofc Slack and WhatsApp works fine : they use the Google notification system.
There should be a category: "Background Check" in the Android developer options. You can pretty finely tune or alter the automatically set priorities and permissions for background activity there.
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 use signal a lot (probably has 30-60 minutes screen time per day), and still notifications are extremely finicky no matter what battery optimization settings I tweak. So I'm leaning towards some apps being blessed
I use twitch almost every day, its notifications are usually off by 10-15 minutes... /shrug
Briar will thrive once EU Chat Control 2.0 passes, P2P E2E encryption is the only way to bypass bullshit laws.
Briar is dead because it doesn't work on iPhones. It doesn't work on iPhones because iOS will only allow waking the app from background when there's a push notification. Push notifications have to go through Apple's servers, which defeats the purpose of a decentralized app where your messages (and metadata) can't be traced.
What about a "fake push" that does not leak message contents, sender etc.? Fuzz the time the push notification is sent by a random amount of time and you have something plausibly private given the constraints?
You're still dependent on Apple continuing to allow such a use.
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.
Briar is designed to work over 1) tor, 2) ad-hoc wifi, 3) bluetooth. None of those are going to be conducive to sending push notifications through Apple's servers.
That still exposes some metadata. Depending on your threat model, leaking the timing may or may not be a problem.
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.
No, because most people (not on HN) value convenience much higher than privacy.
Only, if they manage to improve it, so that regular photos and voice messages can be sent. I am mostly fine with texting only, but such things are an instant no-go for most people.
only insofar as it is 1. not illegal to do so or 2. the cost-benefit of violating such laws makes sense for the majority of users, who are not doing things that are actually illegal
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
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.
Plus people at the top level of the current administration just use Signal for discussing ongoing military operations and other classified stuff, so they don't see the need for solutions like Briar either...
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.
> 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.
Why? I use a similar model in a few mobile apps. Free, not logged in usage stores a restricted set of user activity data ephemerally (lost upon uninstall) in the phone. For subscribed users, this offline storage mechanism is still the primary storage mechanism, but then we add a cloud sync mechanism on top of it that enables usage across multiple devices and permanent storage in the cloud. Curious why you need to write the app twice when in my mind you are simply adding and enabling extra functionality on top of the core product.
Is this still relevant in the age of LLMs? They can write it 5 times without sweating.
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...
Claude is the only contributor? 100% vibed.
https://docs.cwtch.im/ has P2P Onion Service based messaging.
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.
It's both sad and understandable. So many Applications would want to be running in the background for data collection reasons or just user responsiveness. While it could be a permission, after watching so many people just hand out "Sure, have my location always and forever" to any application that ask for it, the OS would get totally overwhelmed.
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.
> 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 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.
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.
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
Briar supports sending images. Source: user
> 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.
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.
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 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).
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.