Rendered at 19:49:27 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
I_am_tiberius 23 hours ago [-]
Everytime I read GrapheneOS news I search for news related to Fairephone. It's such a shame that there's still no official plan for Fairephone to work on requirements for GrapheneOS. The combination of those 2 would be fantastic. It would also open a big new market (I assume) for Fairephone so not sure why there seems no clear sign in that direction at all (to my knowledge).
jasonvorhe 23 hours ago [-]
Everytime I see Fairphone mentioned whenever there's news about GrapheneOS I'm confused as to why people keep on conflating both when they obviously have very different goals.
Timshel 22 hours ago [-]
? Not conflating, just we want a phone with both goals ...
pyaamb 20 hours ago [-]
+1
SkiFire13 9 hours ago [-]
Both are for for different niches, but their intersection is relatively big.
t0bia_s 21 hours ago [-]
Every time Fairphone release new device I check width size. Still waiting for small device.
bl4kers 11 hours ago [-]
I believe Fairphone relies on popular off-the-shelf parts. If that stays consistent, the Fairphone will never be small. Save for a change in business model (e.g. pay more for smaller phone)
topaz0 20 hours ago [-]
I wonder if Meta pays phone manufacturers under the table to keep their size large
armadyl 20 hours ago [-]
The overwhelming majority of consumers just prefer larger screens (myself included). People seem to forget that Apple releasing the Mini was them listening to the minority and the sales numbers if it were poor versus the rest of the lineup.
And why would Meta even do that?
folkrav 8 hours ago [-]
Honestly, maybe it's a market specific thing, but from having worked for a carrier, the overwhelming majority of consumers just dont know anything about any phone but the brand. They'll come in store looking for "an iPhone" or "a Galaxy", and the employee will usually push them towards whichever phone has the best deal (and very often, incentives to be sold), which rarely happens to be these alternative models like the Mini. The minority who does buy their phones outright or know what they want does tend to gravitate towards larger phones, but the rest typically just buys the standard, base model.
topaz0 20 hours ago [-]
- facilitate the infinite scroll
- remind you that the phone is in your pocket, to initiate the infinite scroll
preisschild 19 hours ago [-]
I find reading ebooks and long texts like wikipedia a lot more enjoyable on my 6.8" AMOLED panel than on the smaller screens i've had before. You can also doomscroll on smaller screens.
armadyl 20 hours ago [-]
Sorry but this is maximum level conspiratorial thinking. Meta probably has some created some incentive for OEMs to make larger screens by way of people liking content consumption but the idea that they’d be paying for that is ridiculous lol.
topaz0 19 hours ago [-]
I forgive you I guess
wlesieutre 15 hours ago [-]
The follow-up strategy of “smaller width and height didn’t work, let’s try thickness next” reportedly not going any better.
I really think COVID shutdowns did the mini in. People couldn’t go to the store and try holding a phone where they could use it comfortably one-handed again. And then by the time they could, Apple axed it.
microtonal 14 hours ago [-]
I don't believe this at all. If people yearned for smaller phones, they would have gotten it despite COVID. My wife and I both had a Mini and I remember going to the local electronics store (most of the summer there were no closures) and the iPhone islands were well-visited, but simply nobody was looking at the Minis.
I think people get the wrong estimation about the size of the contingent that want small phones. It is a vocal minority, similar to people ranting every time about headphone jacks. Most people do not care about these things. If they want to hook a wired headphone, they'll get a 10 Euro dongle and most people use Bluetooth. My wife uses a wired headphone for listening audio books at night and I never heard her complain about the stereo jack going away.
asaddhamani 14 hours ago [-]
I bought the mini and I bought the Air so it worked on me. I think it’s crazy that Apple sold millions of devices and that’s not enough of a market. We should make devices few people use, not everything needs to be mass market, to me that’s enshittification and greed.
axelthegerman 19 hours ago [-]
Or maybe the majority of people buying a new damn phone every other week just prefer it'd be a tablet
notesinthefield 18 hours ago [-]
Just today I giggled and reminisced over the old XDA Developers Nexus 7 posts about LTE and wifi calling hacks…the many few of us worked hard to only rely on a tablet! Ironically, there is now not a second of my day in which id find a folding phone useful or logistically feasible. Alas…13 years too late.
Brian_K_White 13 hours ago [-]
50% of the population has hands that are too small to operate a typical phone with one hand. It's ridiculous that there is nothing for such a huge number of people.
Most people take what they're given. Whatever is on the shelf or the front page, that's what they buy. Manufacturers make bigger screens because it's impressive and good for delivering content and provides room for cpu & battery, and most people just go along with it. They think about products the same as the weather. Whatever is, is just what is, like it's just part of the world, not something that people made and people can make differently. If there is choice available, they buy what they were told to want.
Sales numbers are not a strong argument in an environment like that. Countless things sell in huge numbers without anyone actually liking the product or service, even when there isn't a hard monopoly like your cable/internet.
There is a whole other big perverting factor too, which is that for many years now a phone is many people's only computing device. They are preferring phones that are larger that they'd really like for a phone, because they can only have one, and need it to do every job that you and I use a laptop for.
bigstrat2003 16 hours ago [-]
> the sales numbers if it were poor versus the rest of the lineup.
For one, the sales were still perfectly respectable. "Versus the rest of the lineup" is doing a ton of work here, because the rest of the iPhone models sell like crazy. For two, it is still bizarre that manufacturers refuse to make small phones even with that in mind. If you wear very small clothes (or very large clothes) that won't sell as many units, your options are limited, you have to pay more, but you aren't forced to go naked. But there's nobody out there doing the equivalent strategy for phones.
armadyl 15 hours ago [-]
Bro the Mini was a flop for Apple, it could barely surpass 5% of all iPhone sales during its run. It would be nonsensical for a publicly traded company to leave money on the table and keep an underperforming product alive when they could put that towards the better performing bigger screen iPhones instead.
For a small company sure it could be considered a success.
I don’t think tech can be compared to the fashion industry. Also that example doesn’t really work. Because you basically have a locked in group who needs the clothes. Just also culturally there’s reasons why these clothing sizes exist. Nobody needs a small phone.
But across the board it makes no sense for any OEM to make small phones when the data all shows that bigger screens sell more. That’s just absorbing an unnecessary opportunity cost.
I think the only real way small phones will reach the market at this point in time is via a private company that’s basically run as a passion project.
Honestly in this case the consumers do share the blame. They begged for the mini and didn’t show up. If apple couldn’t do it it’s unlikely that the android oems could.
Dylan16807 13 hours ago [-]
> Bro the Mini was a flop for Apple, it could barely surpass 5% of all iPhone sales during its run.
They were making the SE at the exact same time as the mini, two years in a row, and the mini still got billions in sales. If they want a bigger percent, then do it less often and don't split the demand. It's been four and a half years since they did either mini or SE. People would buy plenty.
> leave money on the table
> opportunity cost
If it cost them that much to have extra models, they wouldn't have five iphone 16 variants that are all just different enough to need five internal layouts. And four 17 variants plus the air.
armadyl 13 hours ago [-]
Don’t know what else to say here I guess you and the others here know more than Tim Cook does.
Dylan16807 12 hours ago [-]
That's a weird statement. Do you think knowing the most about something inevitably leads you to a specific decision? It doesn't.
And this isn't something that would affect their revenue particularly much. So while it's possible I've missed an important factor, even if I'm 100% right it could make sense for most people to say "do the option that leads to more happy customers, while still making boatloads of money", while a CEO says "we have enough happy customers, go for the extra sliver of money". Or an extra payment from Meta or whatever, I wasn't really talking about that idea, I was just arguing against their abandonment of small phones. The point is, don't use CEOs to guide your intuition of what decisions are best.
bigstrat2003 15 hours ago [-]
A brief search says that iPhone sales in 225 were approximately $200 billion. 5% of that is therefore approximately $10 billion. If you call that a "massive flop", your standards are completely unrealistic. That is a massive success.
And no, the clothes analogy is not flawed. The point is that in other markets, niche tastes and needs get served even if it isn't as cheap or plentiful. It's only the phone manufacturers which refuse to try to get sales from a smaller (but still quite extant) market.
microtonal 14 hours ago [-]
A brief search says that iPhone sales in 225 were approximately $200 billion. 5% of that is therefore approximately $10 billion. If you call that a "massive flop", your standards are completely unrealistic. That is a massive success.
It's all about scale. Yes 10B is a lot for most companies, but for Apple 5% is just a blip on the radar. They probably also did their market research and found that the vast majority of Mini users would buy another iPhone model if they discontinued the Mini. Those facts combined give Apple little incentive to continue the lineup.
Another thing that further clouds the 5% discussion is that some Mini purchasers may have bought it not because of the size, but because it was $100 cheaper while still getting the same SoC. Maybe those buyers were disappointed by the worse battery life, and Apple could choose to axe it or make it the same price as the regular iPhone and it would drop way below 5%.
armadyl 14 hours ago [-]
Thanks you said it better than I would’ve
ta8903 15 hours ago [-]
But you see people talking about the mini almost every time there's a discussion about iPhones (or phones in general). Surely it would have been worth it to Apple to keep the mini alive just to avoid the negative press and pretend they care about their consumers beyond making a profit. But I guess it really isn't possible to do things like that in a publicly traded company.
microtonal 14 hours ago [-]
But you see people talking about the mini almost every time there's a discussion about iPhones (or phones in general).
...in tech forums where people hold strong opinions about tech and the people who have their pet peeves come out. IRL I have rarely heard somebody wanting Apple to bring the Mini back. Or the stereo jack for that matter.
blendergeek 9 hours ago [-]
I agree they are separate. What annoys me is that every time FairPhone has news, there are obligatory FUD comments about how people should stay away from FairPhone because they don't support Graphene.
Brian_K_White 13 hours ago [-]
The only one conflating anything is yourself.
This is no great conundrum. There is simply a large set overlap. A lot of the people who care about one one, also care about the other.
It's the same as Framework owners and Linux users.
FW is not a linux laptop company. They didn't even barely say the word Linux initially. Their selling point was the repairability and configurability. Only after they had been shipping for a while it became unavoidable that a huge fraction of their users were linux and even freebsd users. Only after some time and only gradually they started providing a little bit of official acknowledgement and support for Linux.
But repair parts and linux os don't have anything to do with each other! zomg why is everyone conflating Framework with a linux laptop company???
andrepd 22 hours ago [-]
I think it's obvious that the target audience has a huge overlap...
illiac786 12 hours ago [-]
I wouldn’t say obvious, no. It’s what I observe, yes. But I have some doubt about my observations scaling up to a valid statistics. Lots of folks out there are not techies yet do care about the environment. I can’t see them caring much about grapheneOS, but maybe I’m wrong.
gpvos 22 hours ago [-]
HN readers aren't a huge demographic.
ntnsndr 6 hours ago [-]
Poster said huge overlap, not huge audience:)
But I agree with the overlap. I use e/OS partly because I can run it on a Fairphone. I'd love to try Graphene.
foolin 21 hours ago [-]
A huge overlap in two groups would obviously be at most 100% of the smaller group.
SecretDreams 21 hours ago [-]
Is there a huge demographic for grapheneOS and/or fairphone? Let alone one that doesn't overlap with the archetypes that post here?
saligne 23 hours ago [-]
You should search for the many times where GrapheneOS has stated they won't work with Fairphone
Telaneo 23 hours ago [-]
It's because Fairphone doesn't fulfil GOS's hardware requirements. If Fairphone addresses that, there's no reason for GOS to not support a Fairphone device.
microtonal 14 hours ago [-]
I don't think they can, even if they wanted to. From the GrapheneOS device requirements:
Device support code updated to new monthly, quarterly and yearly releases of AOSP within several months to provide new security improvements (Pixels receive these in the month they're released)
Fairphone's hardware and software is developed by a Chinese ODM (T2Mobile), who even have difficulty pushing out monthly patches very timely. They don't even do QPR2s, major Android updates are very late (usually almost a year), they rarely do driver firmware or kernel updates. There is no way they could fulfill this guarantee unless they started doing software development in-house and paid Qualcomm for monthly firmware updates.
karel-3d 13 hours ago [-]
Oh for some reason I thought Fairphone does all this in-house, not that they just take Chinese ODM. It makes more sense now.
fc417fc802 21 hours ago [-]
I don't understand the issue. If Fairphone wants GOS can't they just compile it themselves with whatever unsupported hardware based security features disabled? Ditto for any given end user. It's not as though we're talking about a device with hardware specs locked behind an NDA and drivers that only support outdated kernel versions.
grapheneos 13 hours ago [-]
An incredibly incomplete port without many of the core security features and decent updates is not GrapheneOS. It isn't possible to bring GrapheneOS to Fairphone devices.
> It's not as though we're talking about a device with hardware specs locked behind an NDA and drivers that only support outdated kernel versions.
Fairphone 5 and earlier have an end-of-life Linux kernel. Fairphone 6 is approaching the same fate. None of their devices keep up with the incomplete security backports to older releases, let alone the full security updates via new major releases. All of their devices are missing important hardware security features which should be standard. They're repeatedly said they don't consider any of this a significant issue and have no plans to significantly change it.
fc417fc802 13 hours ago [-]
Yes, I realize that the official stance is that it isn't grapheneos without the security features. That doesn't change the fact that someone who won't have the security features either way (and presumably doesn't care because otherwise he would switch to a different piece of hardware) might want the option of using a build of grapheneos that isn't officially condoned by the maintainers. (That's kind of the whole point of FOSS, right?)
I didn't realize fairphone was stuck on an EoL kernel. I guess that means that even if the build can be made to work right now (far from certain given an old kernel) it would likely break in the future.
grapheneos 12 hours ago [-]
> might want the option of using a build of grapheneos
An OS without the core features and updates of GrapheneOS clearly isn't GrapheneOS. It's not permitted to refer to it as such.
> That's kind of the whole point of FOSS, right?
No, the point of FOSS is that you can take all of our code and use it for other purposes. Calling an incomplete port to another device GrapheneOS is misleading users. It isn't GrapheneOS and must have a unique name.
fc417fc802 34 minutes ago [-]
No one was suggesting that your trademark should be infringed when marketing to users. If I do my own custom build of firefox referring to it as such in casual conversation is entirely separate from marketing it under that name for others to use (see ex icecat).
Honestly while grapheneos is a useful thing that I'm glad exists you're being absolutely insufferable.
Telaneo 21 hours ago [-]
Simple. Fairphone doesn't want GOS.
Forking GOS and porting it to a new device is a huge and unreasonable ask for an individual user. Even less so when you include the fact that you'll need to keep it up to date.
fc417fc802 21 hours ago [-]
I understand that bringing AOSP to an unsupported device is a huge endeavor. But fairphone already has the driver situation sorted out. What's the complexity here? (Genuine question, I'd like to correct any misconceptions about the android ecosystem that I have.)
josephg 20 hours ago [-]
Why? Because of drivers? Don’t they already have Linux drivers for the fairphone?
I wonder if fable or astra could wire everything up.
microtonal 14 hours ago [-]
LLMs do not solve every problem.
You are dependent on Qualcomm for hardware firmware updates and apparently they charge quite a bit extra if you want continuous monthly security updates [1]. This is possibly one of the reasons that smaller OEMs like Fairphone do not update firmware regularly and instead choose to keep their customers vulnerable to many known CVEs.
They're getting remarkably good at reverse engineering. I wonder if the relevant firmware updates can be provided by the user or OEM or if they're blobs that have to be signed by qualcomm?
imkac 17 hours ago [-]
As a company that often lies, they won’t spend a single penny on this.
fsflover 6 hours ago [-]
Unsubstantiated accusations are against the HN guidelines.
Yes, they can, but they have promoted /e/OS, and they have no ability to develop Android.
mrd3v0 23 hours ago [-]
Given the state of Fairphone hardware, software and business, it is not surprising.
tcoff91 23 hours ago [-]
For those of us out of the loop, could someone summarize the situation?
bramhaag 23 hours ago [-]
> Fairphone has said they don't plan to add a secure element. It can be seen from their current devices that they don't fully keep up with privacy/security backports and lag a year behind on shipping yearly OS releases. They skip over the monthly and quarterly releases entirely. They replaced their own non-GMS Fairphone OS with a dramatically less secure /e/OS option in partnership with Murena. They clearly demonstrate that security and even privacy are not the priorities.
It should be noted that GrapheneOS had similar criticisms about almost every smartphone vendor, including Motorola before their upcoming cooperation IIRC.
Most of their criticisms are valid, but they seem to be absolutely unwilling to make any compromise at all.
Not sure if they want to protect their brand, if any of those criticised issues would increase the work needed by them significantly, or why they are like that.
But I would prefer to have a slightly less secure GrapheneOS on many phones, that helps many many more users than just Pixel owners, over the current all or nothing situation.
em-bee 23 hours ago [-]
They replaced their own non-GMS Fairphone OS with a dramatically less secure /e/OS
it sounds like they are saying that /e/OS is less secure than fairphone's own OS. with all criticism against /e/OS taken into account, i highly doubt that fairphone would have been able to make their own version of android more secure than /e/OS when they are not even interested in working on that.
microtonal 14 hours ago [-]
It starts with simply rolling major releases out earlier than /e/OS. Remember that to get security fixes for vulnerabilities not marked high/critical, you need the QPR/major updates. Those vulnerabilities may not be an immediate RCE, but they might get used in exploit chains after an RCE. Also, Fairphone and /e/OS will have many known RCEs, because they do not roll out embargoed patches like GrapheneOS and to some extend Samsung & Pixel do.
em-bee 5 hours ago [-]
as if fairphone ever did that: they don't fully keep up with privacy/security backports and lag a year behind on shipping yearly OS releases
so, again, how is /e/OS being behind on updates any worse than fairphone's own OS?
riedel 20 hours ago [-]
One of the reasons I haven't switched to Graphene is this kind of drama. I wish there was more middle ground. I don't think the post is in any way constructive and will lead to fairphone to consider adding a secure element.
IlIlI 20 hours ago [-]
I don't see their post as 'drama' or nonconstructive at all. It's simply a list of well-founded criticisms of Fairphone's extremely lax position on security that is incompatible with Graphene's. If being critiqued for it doesn't lead to them considering adding a secure element, that's a problem on Fairphone's side imo.
riedel 12 hours ago [-]
The core criticism to the vendor is the missing security element. This is a fair point.
However, calling out on e/OS in the same post, seems to me very counter-productive. We need more OS vendors and less infighting. Calling all custom ROMs insecure and claiming to be the only one is IMHO 'drama'. Particular there are contributions of me microG that are helpful if you want to de-Google ones phone. Graphene has a different approach: fair. People will use GrapheneOS if they share their goals.
Fairphone is about sustainability and a bit about not supporting major tech like Google. I don't think this hurts. In an ideal world we could have both. But sustainability seems to be a non-goal of GrapheneOS.
bramhaag 11 hours ago [-]
I think in this context it's fair to call out /e/.
In some ways /e/ and GOS are trying to achieve different things (/e/ is not hardened and does not claim to be), but /e/ is severely lacking security wise compared to AOSP.
This [0] is, in my opinion, a fair review that mentions many of the issues. That Fairphone is ok with these is telling about their position on privacy and security.
Imo i think actually naming the problems is a lot more productive than walking around them
riedel 11 hours ago [-]
To them Murena seems to be the biggest problem.
NewJazz 23 hours ago [-]
[flagged]
armadyl 20 hours ago [-]
I would imagine the cross section of people who seek out GOS but would settle for Postmarket OS is nearly non existent.
NewJazz 17 hours ago [-]
Then you have poor imagination. People seek Graphene OS for many many reasons.
Telaneo 14 hours ago [-]
I settled for /e/os and was disappointed, so in a way you're right, since I won't stick around.
gruez 22 hours ago [-]
"mfg"? They don't manufacture anything.
NewJazz 22 hours ago [-]
A distribution of software? Saas are people too!!!
AstralSerenity 19 hours ago [-]
I would throw serious money at them both if this collaboration happened.
drnick1 20 hours ago [-]
To be honest the specs of the Fairphone are middling and the device is rather expensive for what you get. The Pixels are a much better value, especially with a series. If you want something truly high end, wait for the Motorola with official GOS support.
IseardMi 12 hours ago [-]
Isn't the whole idea behind Fairphone that they are more expensive because the parts are responsibly sourced? That they pay a fair price for labour and materials? And that the phones are highly repairable?
Why would that mean it could compete with a Pixel which generally has none of those goals?
grapheneos 12 hours ago [-]
There's nearly no information available on the working conditions, pay or environmental impact of Fairphones. T2Mobile is the company designing and making Fairphones since the Fairphone 4 and little information is available on them. Fairphone provides a long list of companies involved in the supply chain without more details than their location and website.
Pixels have long term availability of official parts for repairs and also official repairs.
Unlike Fairphones, Pixels have very good updates over the long term. Fairphones do not provide anything close to decent updates and it greatly degrades over the lifetime of the device. Fairphone 5 and earlier have an end-of-life kernel without security support. The devices start out lagging months behind on partial security backports and a year or more behind on full security updates which gets worse over time.
varispeed 20 hours ago [-]
Without support of alternative OS Fairphone is basically a landfill. Why would anyone buy this apart from novelty factor.
armadyl 20 hours ago [-]
Supporting an alternative OS wouldn’t change the fate of Fairphone, imo. Most people don’t care to move away from the stock version of Android that comes with their phone or iOS.
microtonal 14 hours ago [-]
This isn't a hypothetical, Fairphone supports alternative OSes. Heck, you can even buy it with /e/OS in their store:
tbf that was just more so me insulting fairphone and kinda unnecessary from me
chaosharmonic 18 hours ago [-]
I mean, aside from /e/OS as a first-party option, there are also official Lineage builds[1]. And they're at least a target for PostmarketOS[2], even if that wiki doesn't actually describe something daily-driveable yet.
> The more an article would benefit from photos, the less likely it’ll have them.
grapheneos 12 hours ago [-]
It's not an article but rather release notes for people who already use it. The app is only available to users on GrapheneOS as the default SMS/MMS app (eventually RCS). Our users try out the new version directly instead of looking at static images of it.
cloudie78 24 hours ago [-]
How about some screenshots?
qweqwe14 24 hours ago [-]
I constantly see those projects that would benefit from a screenshot in a readme, but for some reason the thought about adding one doesn't even come to the authors' mind, even though it's pretty obvious. I'd really like to know what's going on.
sakisv 23 hours ago [-]
I think the reason is that you can get quite much of a tunnel vision while developing. Everyone involved already knows what they're building and how it looks, so it's very easy to overlook it.
Case in point, I recently wrote a CLI to show which of your AWS infra is not captured in terraform, and you can either print the result as a json to consume by a machine or generate a dashboard with some charts. It took me an embarrassing while to realise that I should have included a damned screenshot in the README, in fact I think I only realised when I wanted to show it to my brother.
IshKebab 22 hours ago [-]
It's also just quite a lot of work to generate screenshots.
sakisv 22 hours ago [-]
That's true as well, especially if you're still developing and changing things - because you tend to realise problems only after you've pushed the new screenshot :P
gbalduzzi 23 hours ago [-]
I think in many cases the authors value functionality much more then esthetics.
Which is a bummer because it is a complete different point of view from the more typical user experience
embedding-shape 23 hours ago [-]
> I think in many cases the authors value functionality much more then esthetics.
In many cases the repository isn't meant to be more than for source code too, not everyone use their git repository as also the marketing page, that'd go somewhere else.
With that said, grapheneos.org doesn't seem to have any screenshots either, which I also don't understand and think is a bummer. Even though the point of the differences with GrapheneOS might not be mainly visual, just showing what it looks like seem like a no-brainer.
xboxnolifes 23 hours ago [-]
An image is functionality, as it provides significant information to the reader.
gremlinunderway 23 hours ago [-]
Yeah but see, we're talking about a functionality that is inherently visual. Ergonomics has nothing to do with esthetics, and it's such a dumb excuse to hand wave aside interface issues as of they are just about "making things look pretty"
em-bee 23 hours ago [-]
exactly, i am looking at screenshots for apps to get an idea about their functionality.
Dig1t 23 hours ago [-]
"A picture is worth a thousand words"
It's like we've had this ancient knowledge passed down for generations but people constantly just ignore it.
grapheneos 13 hours ago [-]
A video would be needed rather than screenshots since those wouldn't show the new animations and UI flow.
GrapheneOS users can update to it via the Alpha channel and try it out rather than looking at screenshots. There's still more to improve before it will go to the Beta and Stable channels.
It's the default SMS/MMS app for GrapheneOS and isn't available for use outside GrapheneOS so we aren't trying to promote it as an option.
gib444 13 hours ago [-]
[flagged]
nicolas_ 22 hours ago [-]
I was looking for the same thing. Fine! Maybe it’s in the Readme.md. Nothing! Well, ok then
why_at 20 hours ago [-]
I just updated mine to try it out, it definitely looks nicer.
Worth raising a PR/discussion on the repo as reasonable chance the devs haven’t even considered it
mrd3v0 23 hours ago [-]
I wish they prioritised the call app. It is beyond appalling. You can't even determine when a call happened, beyond the generic low fidelity "[time] ago". It also almost feels like tapping anything makes me accidentally call people. Abhorrent UI/UX to be completely honest.
okanat 23 hours ago [-]
I'm using LineageOS so I have the AOSP Phone app. If Graphene uses the same, then you can actually determine the exact time of call, but you need to jump through a couple of hoops: Go to "Call History" from the three dots then click on the call of interest. You'll see a button called "Call Details". Then you can see the exact time.
azdle 22 hours ago [-]
Can confirm the same works on Graphene. Also works directly from the "Recents" list.
loufe 22 hours ago [-]
This is completely false. Tap the call, tap "call details" and its there. Took be 2 second to disprove. This is lazy to the point of being seemingly malicious commentary.
slumberlust 17 hours ago [-]
I agree with parent. When I tap the icon/picture on the history it should pull up the contact not call. I also find the need to click into a submenu for context bad UI.
Your comment is unnecessarily inflammatory.
j1elo 22 hours ago [-]
I'm just reading from the barrier here, and not knowing what it even looks like, but reading your description I can immediately agree that it is a bad design.
There's only a handful of critical details in a call history, and absolutely no reason for any UI to implement them as secondary or tertiary details: Whether it was in- or outbound. To/from what contact. The date and time.
2 taps for some other extra info such as call length, or further contact details, would be OK I guess, but for first-level info as these, it's 100% bad design.
>There's only a handful of critical details in a call history
And they're all there: profile pic, contact name, indicators that show incoming/outgoing + missed/connected, which SIM, a redial button, how long ago (which after about a week shows the date), Tapping the middle expands the row (no obstructive pop-up) to show Block, Message, & Details buttons.
The reason it has 'human times' is because multiple calls with the same contact are grouped, so a precise time doesn't always make sense. Tapping the Details will show all calls in that group, whether it's one or seven, with their full dates, times, durations, and further options. It's never been a difficult UX.
j1elo 10 hours ago [-]
Thanks. There's no better way to check how it is than having it on hand.
I'd argue against relative dates because that's an opinionated design that requires cognitive overhead on the user. A young person might be able to mentally translate, but older ones tend to have it more difficult. Usually, opting for relative dates tells us about the designer's lack of experience with different groups of users than the normative one.
kwarcode 14 hours ago [-]
> The reason it has 'human times' is because multiple calls with the same contact are grouped, so a precise time doesn't always make sense.
But a precise time does always make sense.
And even if "doesn't always make sense" was true, it doesn't on its own justify a different default.
So what does grouping have to do with it?
fc417fc802 21 hours ago [-]
> design-wise this was already a "Done" thing in the golden Nokia days!
I might be mistaken but I seem to recall it being a done thing for android prior to several years ago when it was "improved" with an update. Although it's possible I'm confusing the call apps from AOSP and various vendors. Either way several of my past android devices had a significantly better address book, dialer, and call history.
HybridStatAnim8 18 hours ago [-]
Good news! GrapheneOS has ported Messaging to kotlin, jetpack compose, and material you. The same is planned for the Contacts app, Dialer app, and more. Dont quote me but it seems Contacts and Dialer are up next after Messaging.
Also, GrapheneOS has very recently released automatic call recording for the Dialer.
subscribed 23 hours ago [-]
What? :)
You mean the perfectly functional (if barebones) AOSP call app? :)
HybridStatAnim8 18 hours ago [-]
It will get ported to kotlin, material 3, and jetpack compose, just like Messaging.
gpvos 22 hours ago [-]
The one with the terrible UI, yes.
Maskawanian 24 hours ago [-]
Does anyone know if this is something that we can install now, or if it will show up in the next OS release?
flexagoon 24 hours ago [-]
You can go to the GOS App Store, choose the Messaging app, click 3 dots at the top and choose the Alpha release channel to get it now
novafunc 24 hours ago [-]
They mentioned you can use the Alpha from their app installer.
Maskawanian 24 hours ago [-]
Good to know! For others: You open their app store, go into messaging, hamburger menu, select release channel, and choose alpha.
gib444 24 hours ago [-]
It's in the alpha channel. Go in to the 'App Store' app, go to Messaging, 3 dot menu and change release channel.
jcul 21 hours ago [-]
Where I live, an sms app is not very important. It's almost exclusively used for two factor authentication messages. Everyone uses WhatsApp, signal, telegram etc, even businesses and services.
So having a bare bones aosp messaging app was never an issue for me. Having said that, I find fossify messages pretty good.
Will try out the new GOS app too.
nosioptar 18 hours ago [-]
All of fossify's apps I've tried have been better than the stock apps.
Cider9986 14 hours ago [-]
Their phone app doesn't have visual voicemail.
mewse-hn 24 hours ago [-]
Does it do RCS?
grapheneos 12 hours ago [-]
We've announced our plan to add RCS with Messaging Layer Security (MLS) for E2EE compatible with Google Messages and iOS. SMS/MMS will only be a fallback once that's implemented.
ImJamal 6 hours ago [-]
I don't know enough about how RCS works, but if I have an existing conversation in Google Messages would I be able to migrate it over to when this gets implemented?
OneDeuxTriSeiGo 24 hours ago [-]
No. RCS is still quite hard to actually implement. There's an open issue for it but the effort is mildly herculean.
AFAIUI though GOS does intend on providing an RCS impl eventually even if it takes years to do.
sicktriple 23 hours ago [-]
I'm really hoping they're doing this to pave the way for an RCS implementation. If it can be done, GOS is in the best position to make it happen, and without RCS, chatting with normies is both extremely inconvenient (large group chats straight up do not work) and categorically insecure. If I could convince all my friends and family to use Signal I would, but they just think I'm on about some weird Edward Snowden shit, and they just write me off as crazy. "Why would I checks notes download software to solve a problem when I could use the one that came with my phone?"
sebastiennight 10 hours ago [-]
I'll give you the strategy that works for me.
Do NOT talk about privacy, E2EE, or any of that. To regular people, "privacy" has negative value, so even if they wanted something, your talk of private communication and not being scanned by data brokers and governments will make them want it less.
So what to do then?
I present Signal as a novelty and focus on one single feature: "hey, video calls work much better than WhatsApp! Try it out!"
Bam, instant download.
duskdozer 3 hours ago [-]
Why do you say negative? My impression is that it has zero value to them.
loufe 22 hours ago [-]
Don't give up the good fight! Took some time but I got the whole family to adopt it as we had no common shared platform before, and it's been great.
greatgib 22 hours ago [-]
I'm thinking quite the opposite. I hope RCS can die fast. We already have chat apps WhatsApp, signal, telegram, you can even create your own.
I'm quite happy that SMS for one are not something centralized by the giant US big corp. Would be the dream of Google to get all your messages as a gateway.
sva_ 21 hours ago [-]
So I looked into this because my idea of RCS was that it was pretty decentralized direct encrypted communication.
TIL that RCS was designed as a fairly decentralized protocol where every carrier could run their own RCS servers, but it didnt get adoption. So Google stepped in and built their own routing infrastructure, and now mostly all RCS is centralized on Google's servers (even if you use an iPhone, because the RCS server is mandated by your carrier)
antibarbarus 12 hours ago [-]
In my neck of the woods Google actually disabled some of that routing infra, breaking RCS, I guess wanting to force the carriers to build out parts of it? Needless to say the carriers wouldn’t have any of it, so as it stands RCS is fully broken, has been for some time, and will continue to be.
This just shows the fragility of the tech and why I wouldn’t want to rely on it for anything crucial.
sicktriple 7 hours ago [-]
RCS has been an absolutely unmitigated disaster, and it's just a black box when it breaks. There's no reason why messaging in 2026 should need to have cell carriers involved whatsoever - everyone's phone is connected to the internet, every phone should have an IP based messaging app by default.
emayljames 13 hours ago [-]
The implementations of RCS servers that were being done (here in the UK) by carriers, had many issues. A lot of the time your Google messages couldn't connect to the carrier RCS server, messages silently didn't send. I don't know if that was due to something like the carriers not updating their servers, or bad implementation though.
inquirerGeneral 21 hours ago [-]
[dead]
inquirerGeneral 21 hours ago [-]
[dead]
grapheneos 12 hours ago [-]
It may take a long time to make a fully standalone implementation and that may not be compatible with most carriers. However, we plan to provide it in the short term through support for using the Google RCS infrastructure. We can have it start out supporting using sandboxed Google Play for RCS activation in the same way Google Messages uses it to replace Google Messages.
Groxx 23 hours ago [-]
particularly if you want to support all of the message-body features, of which there are MANY. it's very business-comms oriented.
I broadly expect third-party RCS apps to drop that though, like how essentially none support all of MMS. did you know MMS supports slideshows (I built support for this once)? 3d objects (mimetype model/gltf+json)? "timed text" (mimetype text/mp4)?
sterlind 23 hours ago [-]
What's so difficult about implementing RCS from a technical perspective?
Thanks! I noticed on one of my phones that RCS breaks once the Messages app is out of date by a certain amount of revisions. I hope this is an arbitrary decision by Google to invalidate older versions, given that the RCS protocol hasn't changed. I wouldn't want the Graphene team to have to keep up with each change Google makes with their Messages app, and instead is a security oversight Google has found in their own app.
grapheneos 2 hours ago [-]
We definitely will have to keep up with the changes. We already do in order to provide support for using RCS via Google Messages on GrapheneOS. Recently, they made a change which broke it on GrapheneOS and we had to quickly fix that in under a day.
23 hours ago [-]
tcfhgj 23 hours ago [-]
also I think RCS is way to insecure for Graphene OS - they have no way of making sure the communication is actually 100% secure.
In my experience, Graphene OS doesn't make compromises.
grapheneos 12 hours ago [-]
We've announced our plan to add RCS with Messaging Layer Security (MLS) for E2EE compatible with Google Messages and iOS. SMS/MMS will only be a fallback once that's implemented.
fph 21 hours ago [-]
Why would they support SMS then?
sellmesoap 19 hours ago [-]
SMS is a defacto carrier tech that people expect to work, people also don't expect e2ee or any kind of privacy scheme on SMS but it might be a place to hand communication off to a different tech. Whereas RCS leaks meta data to the goog or worse (I don't know the ins and outs of RCS) but by default I would trust it less then signal, who may also collect meta data leaked through the goog, so I guess the real solution is to be boring and assume there is no security or privacy for anyone of reasonable means.
prophesi 15 hours ago [-]
Signal > RCS > SMS.
Just because RCS can't be done without metadata doesn't mean it's a fruitless endeavor. Why not have someone use RCS to then get on Signal? That is so much better than plaintext SMS to Signal.
And for most people, RCS between Android <-> iOS is the biggest advancement in encrypted communication for the layman that I've seen since Let's Encrypt.
grapheneos 12 hours ago [-]
We've announced our plan to add RCS with Messaging Layer Security (MLS) for E2EE compatible with Google Messages and iOS. SMS/MMS will only be a fallback once that's implemented.
Google Messages is essentially the only remaining RCS client for Android and it's the only one with end-to-end encryption. It already works on GrapheneOS via a toggle for ICC authentication extending our sandboxed Google Play compatibility layer. We want to add support for it to our own Messaging app but that's not straightforward since it's not at all an open platform even to the extent of SMS/MMS.
sellmesoap 12 hours ago [-]
That is a positive progression for sure. I guess it sounds like RCS is gatekept behind a play store API on the android side so there isn't an open source solution quite yet? Mostly I'm lamenting that even with signal there's meta-data you can infer behavior from. I know Session messenger has a bit of a network shuffle (is it garlic routing?) That blurs metadata collection a bit, but then they watered down several of Signals' security/privacy choices. I'm constantly curious and overwhelmed at the choice of text communication platforms, just so many!
RCS is way more secure than SMS what are you talking about? RCS+MLS (i.e. GSM standard RCS E2EE) is basically as secure as you can get unless you lock all users involved into a specific app (ex: signal, etc)
seany 17 hours ago [-]
RCS is really the only thing I truly am annoyed by with rooted devices. If GrapheneOS can build something open that works we should be able to rip it apart and get it to work without passing play integrity.
grapheneos 12 hours ago [-]
RCS already works on GrapheneOS via Google Messages using sandboxed Google Play. We have an ICC authentication toggle for granting the required access to Google Play services. We want to provide our own implementation within our Messaging app to replace Google Messages and then we want to provide an alternate backend not depending on sandboxed Google Play, at least for carriers with their own implementation.
phh 10 hours ago [-]
For the context, the vast majority of carriers do RCS with Google's RCS servers (https://github.com/phhusson/rcs-scanner). I'm a bit rusty, but to my knowledge the only exceptions are Jio in India, all Chinese telcos, and some Japenese telcos.
Of course it is relevant privacy-wise (Google still gather a lot of metadata about who speaks to who and when), but that's not even the reason I'm mentioning it.
In the RCS specification, there are three lines on a killer-feature: device attestation. A server can whitelist which devices are allowed to connect to it. And of course Google uses this, allowing only Google-certified devices and Apple devices.
And then, there is actually one RCS client for Google's RCS servers. Because Google Messages doesn't use RCS, it uses a custom protocol based on protobuf. My personal guess is that this protobuf is a 1-to-1 matching with actual RCS, and it's both-way compatible. But still, that means that potentially the Google device-attestation won't work with an RCS client.
Sibling comments say that GrapheneOS plan on implementing it. I think it can reasonably work. TBH I'm expecting that giving a LLM the publicly available information about RCS on microG should give a working "send message" within a day (even when using Google apps rather than microG, it's just that the microG work explains the API). And once RCS work in GrapheneOS' message app, it should be pretty straightforward to port to microG, so yay. However I have to admit I'm not optimist about how long it will keep working. I'd say we are two years away from Google enforcing RKP device integrity for RCS, and uh, good luck passing that.
Of course, I'm hoping that, in the EU, the DMA will break this Google/Apple-only device-attestation, but I'm not aware of anyone pushing that ATM.
24 hours ago [-]
HybridStatAnim8 18 hours ago [-]
Not yet, but they do plan to add support for it.
Markoff 13 hours ago [-]
RCS requires Google account and Google Play services, completely useless, I'm better off with Whatsapp not requiring any of these to function, heck I xan even download APK directly from whatsapp website without play store or aurora
DeepDyno 18 hours ago [-]
One feature I just found out about after trying it is that you can text email addresses.
Unfortunately I think that feature is shutting down.
I'm still waiting until RCS is supported before I actually use it.
Denatonium 18 hours ago [-]
It's probably for the best. As recently as 2016 (and probably more recently; that's just the last time I tested this), they weren't even validating SPF records on their email-to-SMS gateway. You could spoof the "From" address to any email address you fancied and your messages would go through, appearing to be from that sender. Back in high school, my childish self had a field day showing off my phone's SMS inbox filled up with spam Viagra ads that were "sent by" Hillary Clinton's "hacked" email server.
It's not as funny in hindsight, given the unexpected results of that election, but at the time, it felt like top-tier humor.
unlocked7565 6 hours ago [-]
juste tried it... still no search fonction ? back to QUIK app...
module1973 23 hours ago [-]
Would have been cool to have encrypted SMS messages like the SMSecure app while we wait for RCS
LoganDark 1 days ago [-]
That was really fast, they only announced it like a day or two ago IIRC? Also: no screenshots of the redesigned interface?!
getpokedagain 1 days ago [-]
If you look at the history they have been working on this for a few months. The announcement probably was tied to this public release being cut for testing.
mmooss 24 hours ago [-]
With a seemingly insurmountable workload - maintain an actually secure OS fork - for a small team, I wonder how GrapheneOS prioritizes things like messaging apps? I'm not saying it's wrong at all; I am just interested in the thinking inside a project like that.
I can imagine many reasons to devote resources to it:
* A platform is only as good as its apps. If they want to grow GOS in the general public, it requires a good SMS/MMS messaging app.
* LLM tools greatly reduce development costs, especially for well-known functions like text messaging.
* Without secure messaging (as far as SMS/MMS can be secure), the platform security is greatly reduced.
* GOS got a big donation, or has a volunteer that wants to do messaging ...
But idk what I'm talking about. What is their approach?
ravenstine 24 hours ago [-]
Well they're going to be shipping GOS on Motorola and I think some other devices, so basic things like the messaging app need to actually have some polish to them. I really like GrapheneOS overall as-is, but the messaging app felt like baby's first texting app. Not necessarily their fault since it's pretty much straight out of AOSP if I understand correctly. But any time I've installed GrapheneOS, the messaging app is one of two things I must replace every time (the other being the downright bad AOSP keyboard).
If they fix(ed) their messaging app and their keyboard, then they've really eliminated a lot of potential complaints if a less tech-savvy crowd ends up buying future Motorolas.
grapheneos 13 hours ago [-]
> as far as SMS/MMS can be secure
We've announced our plan to add RCS with Messaging Layer Security (MLS) for E2EE compatible with Google Messages and iOS.
> GOS got a big donation
We receive large donations on an ongoing basis.
> or has a volunteer that wants to do messaging
Everyone doing substantial work on the project is paid to do it full time. We hired all the people doing large amounts of high quality volunteer work. We've moved on to a process of filtering candidates based on their CV, an interview process and small test projects.
HybridStatAnim8 18 hours ago [-]
GrapheneOS has made a big push to hire a bunch of experienced, talented app devs, and they have been slowly chipping away at Messaging for a few months. They now have the resources to take on the AOSP apps and resume with the GrapheneOS apps. The rest of the AOSP apps are also planned to be overhauled.
They also plan to eventually support RCS in the Messaging app.
mmooss 17 hours ago [-]
> GrapheneOS has made a big push to hire a bunch of experienced, talented app devs
That's great. How can a FOSS project afford that? Where does GOS money come from? Did Daniel win the lottery?
Cider9986 16 hours ago [-]
They get most of their donations from cryptocurrency. Mostly small Monero donations but also Bitcoin and Ethereum.
They have 14 devs 13 are payed in ETH and 1 in CAD.
Iirc they said something like 2 million in donations in 2025. Vitalik Buterin may have donated at least some time ago.
There's estimated 500k users so if 25% donated 10 dollars a year that's 1.25 million.
mmooss 15 hours ago [-]
Thank you! Though I still wonder:
> Iirc they said something like 2 million in donations in 2025.
That's not enough for 14 devs, plus infrastructure, etc.
> There's estimated 500k users so if 25% donated 10 dollars a year that's 1.25 million.
Unfortunately, 25% would be extraordinary for any project.
They should make their financing public (and maybe they do), being a non-profit and also asking people to trust them with their security. Funding provides influence: if 50% came from adtech or public surveillance companies (e.g., Flock, Palantir, etc.), then people would have questions.
I expect the official account will give you a reply besides my speculation.
They've stated that all money comes from donations.
microtonal 14 hours ago [-]
Unfortunately, 25% would be extraordinary for any project.
Though they were stating $10 per year. You only need 2.1% of the users to donate $10 monthly to get to the same amount. I think GrapheneOS is one of those projects that is really important to their users, so I wouldn't be surprised if more than 2% of the users donated monthly.
HybridStatAnim8 15 hours ago [-]
Yeah it is. Their infrastructure costs are super tiny, the biggest percent of funding goes to pay the dev team, and many are paid a wage comparable to where they live, they dont get inflated US software dev wages or anything.
Most of what they earn is public as a result of the donation method, like crypto. And most donors are completely anonymous.
GrapheneOS does not accept any funding with strings attached.
gib444 5 hours ago [-]
> GrapheneOS does not accept any funding with strings attached.
What role do you have the project? Or where is their public commitment to that statement?
HybridStatAnim8 3 hours ago [-]
I have no role in the project and that has been stated many times on social media.
grapheneos 13 hours ago [-]
Our server infrastructure costs around $200/month. All of our dedicated servers are sponsored. If we had to replace all of the current sponsored servers then we could scale it back a bit and keep the cost around $2000/month for the bare minimum we need.
We're paying around 10 full time developers along with multiple other people. That includes someone in a CFO/COO role and several people who handle community management. Why do you think we wouldn't be able to afford this? We're paying developers around the world rather than hiring people in Silicon Valley. It doesn't cost $250k/year to pay an experienced developer in Eastern Europe.
100% of the funding for GrapheneOS comes from the donations. The vast majority of the donations come from individuals. Cape sells phones with GrapheneOS and is donating $100k/year without any formal sponsorship or deal with them. Donations from individuals are well over $1m/year and will hopefully reach $2m/year soon. We're spending around half of the funding and need to greatly expand our team.
We have a lot more funding available to significantly expand our team are in the process of doing exactly that. We recently hired 3 full time app developers who are working on overhauling our apps. We plan to hire a couple more along with more OS developers. There's also an open role for an experienced QA engineer.
> Why do you think we wouldn't be able to afford this?
Very few FOSS projects receive seven figures in donations, much less dependably enough to budget for it. Good for you; you guys do great work.
Security depends on trust, as you know: Very few users can audit GrapheneOS's code for themselves, and of those people, very few have time to do it. People must trust you to use GOS and for the world to benefit from your efforts. Everything you post on HN relies on trust - almost nobody is checking on it.
IMHO trust requires naming funders, for any organization; secretly funded organizations bringing in millions raise lots of questions. If you don't want to name exact amounts, you could follow many non-profits' practice and name them in ~ logarithmic tiers: $1-100, $101-1,000, $1,001-10,000, etc.
> Cape
Cape is part of the Thiel family (or maybe extended family) of companies. That doesn't condemn them; I'm not expressing an opinion; but realistically it's not a confidence-builder for many people (which is too bad because Cape seems like the most secure service provider I've seen).
Good luck!
HybridStatAnim8 15 hours ago [-]
GrapheneOS makes 100% of their money off of donations, and have made quite a lot of it. The bottleneck is not funding, but finding talented developers to pay with that money.
grapheneos 14 hours ago [-]
GrapheneOS is entirely funded by donations. We're not yet spending nearly enough yet relative to the amount of donations we're receiving.
microtonal 23 hours ago [-]
A bunch of the AOSP apps feel like you have to rewrite them for modern standards now and then you can basically have them in maintenance mode for years. The AOSP messaging app has also lasted for 15+ (?) years and has basically had no maintenance from Google for many years.
Modernizing these apps seems very high-impact. These are the very first things a new user sees and after the initial modernization, they should be relatively cheap to maintain.
subscribed 23 hours ago [-]
> Messaging, high impact.
Messaging can be replaced with one of the hundreds decent messaging apps.
Unlike the backup app which is utterly unusable, untrustworthy and frankly crap. And CANNOT be replaced by anything else.
As it stands it's impossible to have reliable backups in GOS.
drnick1 16 hours ago [-]
I know this isn't the solution you are looking for, but there is a fairly simple workaround and IMO it is superior: set up a Samba server or a Nextcloud instance, either at home or in the cloud, place it with behind a Wireguard tunnel, and don't store anything on the phone itself other than apps and things like maps for OsmAnd that can be redownloaded if lost. The Nextcloud app can automatically sync photos or other files too.
If my phone were lost, stolen or destroyed, I would simply revoke its Wireguard key, buy a new Pixel, flash Graphene, and provision a new Wireguard key. Essentially no data of value would be lost, and restoring my apps and settings manually would take an hour tops. Admittedly, I don't use many apps, so YMMV.
subscribed 9 hours ago [-]
You're right, this is not a solution.
And I'm syncing some of the app data already, but that is not a replacement for the OS apps.
Most of the data cannot be synced like this.
microtonal 14 hours ago [-]
Very few of them will support RCS (I think currently only Google Messages?), which GrapheneOS also wants to support.
I agree that a new backup system is also high impact, but there can be more than one high-impact thing, and the Message app is really low-hanging fruit.
grapheneos 12 hours ago [-]
GrapheneOS already supports using Google Messages with RCS. Google Messages is essentially the only RCS app for Android and it's the only one supporting end-to-end encryption. There were other apps such as a Samsung one but they died out and are nearly entirely only still around on outdated devices as a legacy app. We don't want people to need to use Google Messages for RCS and plan to add it to our Messaging app.
subscribed 9 hours ago [-]
Currently only Google Messages supports RCS indeed, so Messages is not a replacement yet.
Personally I don't need RCS so I simply use Textra since forever as it's far better than Messages, but lack of backup is impacting everyone much more - no other app can be used to back up the OS.
23 hours ago [-]
flexagoon 24 hours ago [-]
I you look at the commits of the new Messages app it's mostly made by 2 people whose Github profiles show them as employees of GrapheneOS and who are mostly committing to different system apps. So I assume they have a separate team of devs whose job it is to make the system apps.
IIRC when they started first announced their replacement for the AOSP camera they said they hired a developer specifically for it.
Markoff 13 hours ago [-]
I just wished there was some IM app supporting ordinary SMS, so I can have extra communicator where I could also receive all notifications from courier, 2FA codes, etc. Such a shame Signal removed it, it was one of the reasons why we ditched it completely with family (other would be unreliable delivery, fixing errors when US dev wakes up, half screen nag prompts about PIN, etc.).
So now I must have extra dedicated app just for SMS, which could be replaced easily with another alternative messenger if ANYONE bothered to implement simple SMS support, but seems nobody is interesting in this, so I am not interesting in your messengers if you cant be bothered to support at least SMS and use Whatsapp (and have Telegram as backup if WA would block me again, appeal took ~5 hours to resolve).
grapheneos 13 hours ago [-]
We've announced our plan to add RCS with Messaging Layer Security (MLS) for E2EE compatible with Google Messages and iOS. SMS/MMS will only be a fallback once that's implemented.
14 hours ago [-]
beepbooptheory 20 hours ago [-]
The biggest issue I have with the degoogled Androids is no RCS chats out of the box. At least for me, it stinks these days to not have it, and you're forced to do sneaky things to get it.
grapheneos 14 hours ago [-]
Providing it via the built-in Messaging app is planned but not straightforward to implement since it's not an open platform. GrapheneOS has official support for using RCS via Google Messages rather than it requiring anything sketchy. It's currently essentially the only remaining Android RCS client.
HybridStatAnim8 18 hours ago [-]
GrapheneOS wants to eventually support RCS in the default chat app. It may take a lot of time for it to work without google components/google services but it is the eventual plan.
gib444 13 hours ago [-]
[flagged]
lollobomb 24 hours ago [-]
Now, can we please get the long-awaited full system backup feature? We pay you for a reason!
(sarcasm obvious, but indeed full system backup is sorely missing. Seedvault is crap, not an option)
preisschild 23 hours ago [-]
I had a scary bug on an older version where for months the contact names didnt match the actual senders/recipients. I have received SMS from my WISP under the same contact as Github MFA codes but also send mssages to relatives that never where received...
andrepd 22 hours ago [-]
Seeing "Material 3/Material You" is a negative point for me, not a positive. It's almost comical just how atrocious the UI is. Yes let's make all phones 20% huge-er and all whitespace 40% wider, said no sane person ever.
qingcharles 20 hours ago [-]
Design is so personal. I love Material 3 Expressive personally. Each to their own :)
HybridStatAnim8 18 hours ago [-]
At least it is now consistent with the rest of the OSs UI.
tsunamifury 22 hours ago [-]
It’s amazing that you don’t think any of this is based on real HCI.
People prefer larger tap targets on touch screens.
Dylan16807 12 hours ago [-]
Larger than what? That only goes so far.
And tons of whitespace doesn't make the tap targets bigger. It exacerbates the problem of bigger targets causing less to fit on the screen.
andrepd 21 hours ago [-]
> People prefer larger tap targets on touch screens.
Uh. This HCI fact has been known for 30 plus years.
Are you this … poorly informed
mvdtnz 23 hours ago [-]
[flagged]
subscribed 22 hours ago [-]
It's maybe $250 for someone's old phone.
Other than that -- next year. And this is other companies' choice, not GrapheneOS team, to fix on releasing grossly insecure hardware or NOT releasing patches and fixes.
edent 22 hours ago [-]
Go down to literally any 2nd hand phone store and buy a refurb. None of your money will go to Google and you'll have your phone at a fraction of the new price.
mvdtnz 13 hours ago [-]
Literally any? Really? Are you sure you're not looking at this through an Americancentric lens? The Google phone was never offered in my market, so second hand options are simply not available.
noman-land 22 hours ago [-]
Set your alarm for next year when you can ship hundreds of dollars to Motorola.
jasonvorhe 23 hours ago [-]
Set an alarm for the typical Motorola flagship schedule then.
mrd3v0 23 hours ago [-]
So..next year?
mvdtnz 13 hours ago [-]
I'll believe it when I see it.
gib444 24 hours ago [-]
[flagged]
HybridStatAnim8 18 hours ago [-]
The notification the Messaging app produces should have the option to copy the one time code directly.
gib444 12 hours ago [-]
It's all 'links' (phone numbers, URLs etc) that are broken. Not just one time codes.
jasonvorhe 23 hours ago [-]
You're using software from an alpha channel.
People sometimes.
gib444 22 hours ago [-]
Alpha lowers the expected level of polish and stability - it doesn't make every regression equally acceptable. It is a reasonable criticism even when released to the alpha channel.
Further, I believe it's reasonable for users' expectations to be influenced by what the project itself communicates about the development process.
> People sometimes.
I have experienced many (relatively minor but some annoying) bugs in GrapheneOS the past few years, without complaint to the developers. And have submitted bug reports and logs. I'm "in the trenches", not just slinging mud from the outside. If I were in a better financial situation right now, I would be donating too.
jasonvorhe 10 hours ago [-]
Conflicts with the common definitions of alpha versions I'm familiar with but definitions differ, of course.
Glad you're not among the gOS haters though!
gib444 10 hours ago [-]
Pointing out regressions wouldn't make someone a hater. That would be a nonsense accusation and a childish conclusion to draw.
getpokedagain 21 hours ago [-]
This is somewhat true. I expect more regressions from released commercial software.
I suspect there are fewer regressions per release on graphenes alpha messenger than there are in googles message's app.
gib444 10 hours ago [-]
You make a good point: as a project becomes more commercialised, you can expect regressions like this.
microtonal 23 hours ago [-]
It's doubly disappointing because just 4 days ago the project wrote [1], on using AI for the new Messaging app:
Why? Using an LLM as an additional reviewer seems like a good use of LLMs? Personally I have found LLMs very useful for that and they catch issues that other experienced programmers do not always find. It’s not like they are vibecoding a messages app.
mvdtnz 23 hours ago [-]
What do you mean "why"? For the exact reason he stated in his first paragraph - a serious regression impacting his workflow.
kelnos 18 hours ago [-]
... which seems to have nothing to do with using an LLM to do extra review.
gib444 23 hours ago [-]
[flagged]
chadgpt3 24 hours ago [-]
[flagged]
bramhaag 24 hours ago [-]
I do not see Electron anywhere? It looks like a native Android app that uses Jetpack Compose.
24 hours ago [-]
gib444 23 hours ago [-]
N.B. User completely rewrote their comment - it previously claimed the app used Electron
And why would Meta even do that?
- remind you that the phone is in your pocket, to initiate the infinite scroll
I really think COVID shutdowns did the mini in. People couldn’t go to the store and try holding a phone where they could use it comfortably one-handed again. And then by the time they could, Apple axed it.
I think people get the wrong estimation about the size of the contingent that want small phones. It is a vocal minority, similar to people ranting every time about headphone jacks. Most people do not care about these things. If they want to hook a wired headphone, they'll get a 10 Euro dongle and most people use Bluetooth. My wife uses a wired headphone for listening audio books at night and I never heard her complain about the stereo jack going away.
Most people take what they're given. Whatever is on the shelf or the front page, that's what they buy. Manufacturers make bigger screens because it's impressive and good for delivering content and provides room for cpu & battery, and most people just go along with it. They think about products the same as the weather. Whatever is, is just what is, like it's just part of the world, not something that people made and people can make differently. If there is choice available, they buy what they were told to want.
Sales numbers are not a strong argument in an environment like that. Countless things sell in huge numbers without anyone actually liking the product or service, even when there isn't a hard monopoly like your cable/internet.
There is a whole other big perverting factor too, which is that for many years now a phone is many people's only computing device. They are preferring phones that are larger that they'd really like for a phone, because they can only have one, and need it to do every job that you and I use a laptop for.
For one, the sales were still perfectly respectable. "Versus the rest of the lineup" is doing a ton of work here, because the rest of the iPhone models sell like crazy. For two, it is still bizarre that manufacturers refuse to make small phones even with that in mind. If you wear very small clothes (or very large clothes) that won't sell as many units, your options are limited, you have to pay more, but you aren't forced to go naked. But there's nobody out there doing the equivalent strategy for phones.
For a small company sure it could be considered a success.
I don’t think tech can be compared to the fashion industry. Also that example doesn’t really work. Because you basically have a locked in group who needs the clothes. Just also culturally there’s reasons why these clothing sizes exist. Nobody needs a small phone.
But across the board it makes no sense for any OEM to make small phones when the data all shows that bigger screens sell more. That’s just absorbing an unnecessary opportunity cost.
I think the only real way small phones will reach the market at this point in time is via a private company that’s basically run as a passion project.
Honestly in this case the consumers do share the blame. They begged for the mini and didn’t show up. If apple couldn’t do it it’s unlikely that the android oems could.
They were making the SE at the exact same time as the mini, two years in a row, and the mini still got billions in sales. If they want a bigger percent, then do it less often and don't split the demand. It's been four and a half years since they did either mini or SE. People would buy plenty.
> leave money on the table
> opportunity cost
If it cost them that much to have extra models, they wouldn't have five iphone 16 variants that are all just different enough to need five internal layouts. And four 17 variants plus the air.
And this isn't something that would affect their revenue particularly much. So while it's possible I've missed an important factor, even if I'm 100% right it could make sense for most people to say "do the option that leads to more happy customers, while still making boatloads of money", while a CEO says "we have enough happy customers, go for the extra sliver of money". Or an extra payment from Meta or whatever, I wasn't really talking about that idea, I was just arguing against their abandonment of small phones. The point is, don't use CEOs to guide your intuition of what decisions are best.
And no, the clothes analogy is not flawed. The point is that in other markets, niche tastes and needs get served even if it isn't as cheap or plentiful. It's only the phone manufacturers which refuse to try to get sales from a smaller (but still quite extant) market.
It's all about scale. Yes 10B is a lot for most companies, but for Apple 5% is just a blip on the radar. They probably also did their market research and found that the vast majority of Mini users would buy another iPhone model if they discontinued the Mini. Those facts combined give Apple little incentive to continue the lineup.
Another thing that further clouds the 5% discussion is that some Mini purchasers may have bought it not because of the size, but because it was $100 cheaper while still getting the same SoC. Maybe those buyers were disappointed by the worse battery life, and Apple could choose to axe it or make it the same price as the regular iPhone and it would drop way below 5%.
...in tech forums where people hold strong opinions about tech and the people who have their pet peeves come out. IRL I have rarely heard somebody wanting Apple to bring the Mini back. Or the stereo jack for that matter.
This is no great conundrum. There is simply a large set overlap. A lot of the people who care about one one, also care about the other.
It's the same as Framework owners and Linux users.
FW is not a linux laptop company. They didn't even barely say the word Linux initially. Their selling point was the repairability and configurability. Only after they had been shipping for a while it became unavoidable that a huge fraction of their users were linux and even freebsd users. Only after some time and only gradually they started providing a little bit of official acknowledgement and support for Linux.
But repair parts and linux os don't have anything to do with each other! zomg why is everyone conflating Framework with a linux laptop company???
But I agree with the overlap. I use e/OS partly because I can run it on a Fairphone. I'd love to try Graphene.
Device support code updated to new monthly, quarterly and yearly releases of AOSP within several months to provide new security improvements (Pixels receive these in the month they're released)
Fairphone's hardware and software is developed by a Chinese ODM (T2Mobile), who even have difficulty pushing out monthly patches very timely. They don't even do QPR2s, major Android updates are very late (usually almost a year), they rarely do driver firmware or kernel updates. There is no way they could fulfill this guarantee unless they started doing software development in-house and paid Qualcomm for monthly firmware updates.
> It's not as though we're talking about a device with hardware specs locked behind an NDA and drivers that only support outdated kernel versions.
Fairphone 5 and earlier have an end-of-life Linux kernel. Fairphone 6 is approaching the same fate. None of their devices keep up with the incomplete security backports to older releases, let alone the full security updates via new major releases. All of their devices are missing important hardware security features which should be standard. They're repeatedly said they don't consider any of this a significant issue and have no plans to significantly change it.
I didn't realize fairphone was stuck on an EoL kernel. I guess that means that even if the build can be made to work right now (far from certain given an old kernel) it would likely break in the future.
An OS without the core features and updates of GrapheneOS clearly isn't GrapheneOS. It's not permitted to refer to it as such.
> That's kind of the whole point of FOSS, right?
No, the point of FOSS is that you can take all of our code and use it for other purposes. Calling an incomplete port to another device GrapheneOS is misleading users. It isn't GrapheneOS and must have a unique name.
Honestly while grapheneos is a useful thing that I'm glad exists you're being absolutely insufferable.
Forking GOS and porting it to a new device is a huge and unreasonable ask for an individual user. Even less so when you include the fact that you'll need to keep it up to date.
I wonder if fable or astra could wire everything up.
You are dependent on Qualcomm for hardware firmware updates and apparently they charge quite a bit extra if you want continuous monthly security updates [1]. This is possibly one of the reasons that smaller OEMs like Fairphone do not update firmware regularly and instead choose to keep their customers vulnerable to many known CVEs.
[1] https://news.ycombinator.com/item?id=48079791
Most of their criticisms are valid, but they seem to be absolutely unwilling to make any compromise at all.
Not sure if they want to protect their brand, if any of those criticised issues would increase the work needed by them significantly, or why they are like that.
But I would prefer to have a slightly less secure GrapheneOS on many phones, that helps many many more users than just Pixel owners, over the current all or nothing situation.
it sounds like they are saying that /e/OS is less secure than fairphone's own OS. with all criticism against /e/OS taken into account, i highly doubt that fairphone would have been able to make their own version of android more secure than /e/OS when they are not even interested in working on that.
so, again, how is /e/OS being behind on updates any worse than fairphone's own OS?
However, calling out on e/OS in the same post, seems to me very counter-productive. We need more OS vendors and less infighting. Calling all custom ROMs insecure and claiming to be the only one is IMHO 'drama'. Particular there are contributions of me microG that are helpful if you want to de-Google ones phone. Graphene has a different approach: fair. People will use GrapheneOS if they share their goals.
Fairphone is about sustainability and a bit about not supporting major tech like Google. I don't think this hurts. In an ideal world we could have both. But sustainability seems to be a non-goal of GrapheneOS.
In some ways /e/ and GOS are trying to achieve different things (/e/ is not hardened and does not claim to be), but /e/ is severely lacking security wise compared to AOSP.
This [0] is, in my opinion, a fair review that mentions many of the issues. That Fairphone is ok with these is telling about their position on privacy and security.
[0] https://www.kuketz-blog.de/e-datenschutzfreundlich-bedeutet-...
Why would that mean it could compete with a Pixel which generally has none of those goals?
Pixels have long term availability of official parts for repairs and also official repairs.
Unlike Fairphones, Pixels have very good updates over the long term. Fairphones do not provide anything close to decent updates and it greatly degrades over the lifetime of the device. Fairphone 5 and earlier have an end-of-life kernel without security support. The devices start out lagging months behind on partial security backports and a year or more behind on full security updates which gets worse over time.
https://www.fairphone.com/the-fairphone-gen-6-plus-e-operati...
[1] https://forum.fairphone.com/t/official-lineageos-23-for-the-...
[2] https://wiki.postmarketos.org/wiki/Fairphone_(Gen._6)_(fairp...
https://imgur.com/a/C8yV83v
> The more an article would benefit from photos, the less likely it’ll have them.
Case in point, I recently wrote a CLI to show which of your AWS infra is not captured in terraform, and you can either print the result as a json to consume by a machine or generate a dashboard with some charts. It took me an embarrassing while to realise that I should have included a damned screenshot in the README, in fact I think I only realised when I wanted to show it to my brother.
Which is a bummer because it is a complete different point of view from the more typical user experience
In many cases the repository isn't meant to be more than for source code too, not everyone use their git repository as also the marketing page, that'd go somewhere else.
With that said, grapheneos.org doesn't seem to have any screenshots either, which I also don't understand and think is a bummer. Even though the point of the differences with GrapheneOS might not be mainly visual, just showing what it looks like seem like a no-brainer.
It's like we've had this ancient knowledge passed down for generations but people constantly just ignore it.
GrapheneOS users can update to it via the Alpha channel and try it out rather than looking at screenshots. There's still more to improve before it will go to the Beta and Stable channels.
It's the default SMS/MMS app for GrapheneOS and isn't available for use outside GrapheneOS so we aren't trying to promote it as an option.
https://imgur.com/a/ZGpbqB7
Your comment is unnecessarily inflammatory.
There's only a handful of critical details in a call history, and absolutely no reason for any UI to implement them as secondary or tertiary details: Whether it was in- or outbound. To/from what contact. The date and time.
2 taps for some other extra info such as call length, or further contact details, would be OK I guess, but for first-level info as these, it's 100% bad design.
I mean come on, design-wise this was already a "Done" thing in the golden Nokia days! https://the-gadgeteer.com/2009/03/02/a-week-with-the-nokia-n...
[*] Ctrl+F to find the image below "miss a call".
Clearly.
>There's only a handful of critical details in a call history
And they're all there: profile pic, contact name, indicators that show incoming/outgoing + missed/connected, which SIM, a redial button, how long ago (which after about a week shows the date), Tapping the middle expands the row (no obstructive pop-up) to show Block, Message, & Details buttons.
The reason it has 'human times' is because multiple calls with the same contact are grouped, so a precise time doesn't always make sense. Tapping the Details will show all calls in that group, whether it's one or seven, with their full dates, times, durations, and further options. It's never been a difficult UX.
I'd argue against relative dates because that's an opinionated design that requires cognitive overhead on the user. A young person might be able to mentally translate, but older ones tend to have it more difficult. Usually, opting for relative dates tells us about the designer's lack of experience with different groups of users than the normative one.
But a precise time does always make sense.
And even if "doesn't always make sense" was true, it doesn't on its own justify a different default.
So what does grouping have to do with it?
I might be mistaken but I seem to recall it being a done thing for android prior to several years ago when it was "improved" with an update. Although it's possible I'm confusing the call apps from AOSP and various vendors. Either way several of my past android devices had a significantly better address book, dialer, and call history.
Also, GrapheneOS has very recently released automatic call recording for the Dialer.
You mean the perfectly functional (if barebones) AOSP call app? :)
So having a bare bones aosp messaging app was never an issue for me. Having said that, I find fossify messages pretty good.
Will try out the new GOS app too.
AFAIUI though GOS does intend on providing an RCS impl eventually even if it takes years to do.
Do NOT talk about privacy, E2EE, or any of that. To regular people, "privacy" has negative value, so even if they wanted something, your talk of private communication and not being scanned by data brokers and governments will make them want it less.
So what to do then?
I present Signal as a novelty and focus on one single feature: "hey, video calls work much better than WhatsApp! Try it out!"
Bam, instant download.
TIL that RCS was designed as a fairly decentralized protocol where every carrier could run their own RCS servers, but it didnt get adoption. So Google stepped in and built their own routing infrastructure, and now mostly all RCS is centralized on Google's servers (even if you use an iPhone, because the RCS server is mandated by your carrier)
This just shows the fragility of the tech and why I wouldn’t want to rely on it for anything crucial.
I broadly expect third-party RCS apps to drop that though, like how essentially none support all of MMS. did you know MMS supports slideshows (I built support for this once)? 3d objects (mimetype model/gltf+json)? "timed text" (mimetype text/mp4)?
In my experience, Graphene OS doesn't make compromises.
Just because RCS can't be done without metadata doesn't mean it's a fruitless endeavor. Why not have someone use RCS to then get on Signal? That is so much better than plaintext SMS to Signal.
And for most people, RCS between Android <-> iOS is the biggest advancement in encrypted communication for the layman that I've seen since Let's Encrypt.
Google Messages is essentially the only remaining RCS client for Android and it's the only one with end-to-end encryption. It already works on GrapheneOS via a toggle for ICC authentication extending our sandboxed Google Play compatibility layer. We want to add support for it to our own Messaging app but that's not straightforward since it's not at all an open platform even to the extent of SMS/MMS.
Of course it is relevant privacy-wise (Google still gather a lot of metadata about who speaks to who and when), but that's not even the reason I'm mentioning it.
In the RCS specification, there are three lines on a killer-feature: device attestation. A server can whitelist which devices are allowed to connect to it. And of course Google uses this, allowing only Google-certified devices and Apple devices.
And then, there is actually one RCS client for Google's RCS servers. Because Google Messages doesn't use RCS, it uses a custom protocol based on protobuf. My personal guess is that this protobuf is a 1-to-1 matching with actual RCS, and it's both-way compatible. But still, that means that potentially the Google device-attestation won't work with an RCS client.
Sibling comments say that GrapheneOS plan on implementing it. I think it can reasonably work. TBH I'm expecting that giving a LLM the publicly available information about RCS on microG should give a working "send message" within a day (even when using Google apps rather than microG, it's just that the microG work explains the API). And once RCS work in GrapheneOS' message app, it should be pretty straightforward to port to microG, so yay. However I have to admit I'm not optimist about how long it will keep working. I'd say we are two years away from Google enforcing RKP device integrity for RCS, and uh, good luck passing that.
Of course, I'm hoping that, in the EU, the DMA will break this Google/Apple-only device-attestation, but I'm not aware of anyone pushing that ATM.
Unfortunately I think that feature is shutting down.
https://www.verizon.com/support/vtext-vzwpix-shutdown/
I'm still waiting until RCS is supported before I actually use it.
It's not as funny in hindsight, given the unexpected results of that election, but at the time, it felt like top-tier humor.
I can imagine many reasons to devote resources to it:
* A platform is only as good as its apps. If they want to grow GOS in the general public, it requires a good SMS/MMS messaging app.
* LLM tools greatly reduce development costs, especially for well-known functions like text messaging.
* Without secure messaging (as far as SMS/MMS can be secure), the platform security is greatly reduced.
* GOS got a big donation, or has a volunteer that wants to do messaging ...
But idk what I'm talking about. What is their approach?
If they fix(ed) their messaging app and their keyboard, then they've really eliminated a lot of potential complaints if a less tech-savvy crowd ends up buying future Motorolas.
We've announced our plan to add RCS with Messaging Layer Security (MLS) for E2EE compatible with Google Messages and iOS.
> GOS got a big donation
We receive large donations on an ongoing basis.
> or has a volunteer that wants to do messaging
Everyone doing substantial work on the project is paid to do it full time. We hired all the people doing large amounts of high quality volunteer work. We've moved on to a process of filtering candidates based on their CV, an interview process and small test projects.
They also plan to eventually support RCS in the Messaging app.
That's great. How can a FOSS project afford that? Where does GOS money come from? Did Daniel win the lottery?
They have 14 devs 13 are payed in ETH and 1 in CAD.
Iirc they said something like 2 million in donations in 2025. Vitalik Buterin may have donated at least some time ago.
Proton donates double digits.
Cape has donated around 100k https://www.cape.co/blog/cape-supports-grapheneos and plans to donate 100k this year.
There's estimated 500k users so if 25% donated 10 dollars a year that's 1.25 million.
> Iirc they said something like 2 million in donations in 2025.
That's not enough for 14 devs, plus infrastructure, etc.
> There's estimated 500k users so if 25% donated 10 dollars a year that's 1.25 million.
Unfortunately, 25% would be extraordinary for any project.
They should make their financing public (and maybe they do), being a non-profit and also asking people to trust them with their security. Funding provides influence: if 50% came from adtech or public surveillance companies (e.g., Flock, Palantir, etc.), then people would have questions.
>plus infrastructure
A lot must be sponsored. https://xprivate.lol/GrapheneOS/status/2070298479897833725#m
I expect the official account will give you a reply besides my speculation.
They've stated that all money comes from donations.
Though they were stating $10 per year. You only need 2.1% of the users to donate $10 monthly to get to the same amount. I think GrapheneOS is one of those projects that is really important to their users, so I wouldn't be surprised if more than 2% of the users donated monthly.
Most of what they earn is public as a result of the donation method, like crypto. And most donors are completely anonymous.
GrapheneOS does not accept any funding with strings attached.
What role do you have the project? Or where is their public commitment to that statement?
We're paying around 10 full time developers along with multiple other people. That includes someone in a CFO/COO role and several people who handle community management. Why do you think we wouldn't be able to afford this? We're paying developers around the world rather than hiring people in Silicon Valley. It doesn't cost $250k/year to pay an experienced developer in Eastern Europe.
100% of the funding for GrapheneOS comes from the donations. The vast majority of the donations come from individuals. Cape sells phones with GrapheneOS and is donating $100k/year without any formal sponsorship or deal with them. Donations from individuals are well over $1m/year and will hopefully reach $2m/year soon. We're spending around half of the funding and need to greatly expand our team.
We have a lot more funding available to significantly expand our team are in the process of doing exactly that. We recently hired 3 full time app developers who are working on overhauling our apps. We plan to hire a couple more along with more OS developers. There's also an open role for an experienced QA engineer.
https://grapheneos.org/hiring
Very few FOSS projects receive seven figures in donations, much less dependably enough to budget for it. Good for you; you guys do great work.
Security depends on trust, as you know: Very few users can audit GrapheneOS's code for themselves, and of those people, very few have time to do it. People must trust you to use GOS and for the world to benefit from your efforts. Everything you post on HN relies on trust - almost nobody is checking on it.
IMHO trust requires naming funders, for any organization; secretly funded organizations bringing in millions raise lots of questions. If you don't want to name exact amounts, you could follow many non-profits' practice and name them in ~ logarithmic tiers: $1-100, $101-1,000, $1,001-10,000, etc.
> Cape
Cape is part of the Thiel family (or maybe extended family) of companies. That doesn't condemn them; I'm not expressing an opinion; but realistically it's not a confidence-builder for many people (which is too bad because Cape seems like the most secure service provider I've seen).
Good luck!
Modernizing these apps seems very high-impact. These are the very first things a new user sees and after the initial modernization, they should be relatively cheap to maintain.
Messaging can be replaced with one of the hundreds decent messaging apps.
Unlike the backup app which is utterly unusable, untrustworthy and frankly crap. And CANNOT be replaced by anything else.
As it stands it's impossible to have reliable backups in GOS.
If my phone were lost, stolen or destroyed, I would simply revoke its Wireguard key, buy a new Pixel, flash Graphene, and provision a new Wireguard key. Essentially no data of value would be lost, and restoring my apps and settings manually would take an hour tops. Admittedly, I don't use many apps, so YMMV.
And I'm syncing some of the app data already, but that is not a replacement for the OS apps.
Most of the data cannot be synced like this.
I agree that a new backup system is also high impact, but there can be more than one high-impact thing, and the Message app is really low-hanging fruit.
Personally I don't need RCS so I simply use Textra since forever as it's far better than Messages, but lack of backup is impacting everyone much more - no other app can be used to back up the OS.
IIRC when they started first announced their replacement for the AOSP camera they said they hired a developer specifically for it.
So now I must have extra dedicated app just for SMS, which could be replaced easily with another alternative messenger if ANYONE bothered to implement simple SMS support, but seems nobody is interesting in this, so I am not interesting in your messengers if you cant be bothered to support at least SMS and use Whatsapp (and have Telegram as backup if WA would block me again, appeal took ~5 hours to resolve).
(sarcasm obvious, but indeed full system backup is sorely missing. Seedvault is crap, not an option)
People prefer larger tap targets on touch screens.
And tons of whitespace doesn't make the tap targets bigger. It exacerbates the problem of bigger targets causing less to fit on the screen.
Only in a completely stupid, nonsensically A/B tested notion of "prefer". I'll refer you to this ~~excellent piece of satirical writing~~ actual post from Google design team: https://design.google/library/expressive-material-design-goo...
Are you this … poorly informed
Other than that -- next year. And this is other companies' choice, not GrapheneOS team, to fix on releasing grossly insecure hardware or NOT releasing patches and fixes.
People sometimes.
Further, I believe it's reasonable for users' expectations to be influenced by what the project itself communicates about the development process.
> People sometimes.
I have experienced many (relatively minor but some annoying) bugs in GrapheneOS the past few years, without complaint to the developers. And have submitted bug reports and logs. I'm "in the trenches", not just slinging mud from the outside. If I were in a better financial situation right now, I would be donating too.
Glad you're not among the gOS haters though!
I suspect there are fewer regressions per release on graphenes alpha messenger than there are in googles message's app.
Why? Using an LLM as an additional reviewer seems like a good use of LLMs? Personally I have found LLMs very useful for that and they catch issues that other experienced programmers do not always find. It’s not like they are vibecoding a messages app.