[timcobb]

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

[klibertp]

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.

[timcobb]

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

[klibertp]

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.

[phoronixrly]

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.

[fg137]

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.

[timcobb]

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.

[fg137]

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

[timcobb]

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?

[fg137]

It seems that you still haven't realized the gigantic hole in your arguments even after I already pointed them out.

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.

[palata]

> It seems that you still haven't realized the gigantic hole in your arguments

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

[prmoustache]

Spending money on AI would not remove any blocker from Android and iOS side.

This is crazy how people can have become so delusionnal to think AI is a magic wand that can solve all their problems. News flash: spending $200 on AI won't make your hair grow back if you are balding.

[Kiro]

I agree. These are classic problems where LLMs really shine. I would be very surprised if GPT-5.6 couldn't fix them.

[timcobb]

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.

[Kiro]

Yes, it's demoralizing for a human. Which is why it's good for an LLM. They have no problem implementing these soul crushing workarounds.

[timcobb]

I meant working around the big tech hegemony, working around code just takes patience and is nice.

[palata]

On the contrary, I think those are fundamental problems that cannot be solved by LLMs.

[no_wizard]

Claude, Copilot or JetBrains AI could also do it

[klibertp]

Emacs with `M-x make-android-bg-app-responsive-dwim` too!

[faefox]

Give that a try and let us all know how it goes. :)

[timcobb]

I would imagine pretty good if it's actually just a code issue

[klibertp]

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?

[timcobb]

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.

[palata]

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

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.

[klibertp]

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

[palata]

I don't get why you're being downvoted for that. It's a fair question.

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.

[specproc]

It's a privacy-focused application for secure communication, last place you want slop.

[timcobb]

To me I seems like it was an attempt at a privacy focused application for communication, but it's now in maintenance mode.