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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.)
> 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.
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.
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.
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.
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.
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.
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.
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
> 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.
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"
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.
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.
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.
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.
> 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.
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.
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.
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?"
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.
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)
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)?
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.
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.
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.
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.
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 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.
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?
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 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.
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.
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.
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...
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.
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.
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.
Looks prettier but a shame an obvious regression happened for one of my primary use-cases: copying one-time codes. Long pressing on a link selects the entire SMS instead of bringing up a menu for the link. [0]
Makes me wonder about all the testing now
And the issue worded/tagged as a feature instead of a regression. Are the devs aware the feature existed before?
later:
It's doubly disappointing because just 4 days ago the project wrote [1], on using AI for the new Messaging app:
"it's also helping us raise our standards for our own work by pointing it at that to get extremely pedantic criticism catching many things we would miss...We've hired multiple experienced app developers who have spent months working on modernizing the Messaging app and carefully reviewing it"
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.
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.
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).
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.
? Not conflating, just we want a phone with both goals ...
+1
Every time Fairphone release new device I check width size. Still waiting for small device.
I wonder if Meta pays phone manufacturers under the table to keep their size large
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?
Or maybe the majority of people buying a new damn phone every other week just prefer it'd be a tablet
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.
- facilitate the infinite scroll
- remind you that the phone is in your pocket, to initiate the infinite scroll
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.
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.
I forgive you I guess
I think it's obvious that the target audience has a huge overlap...
HN readers aren't a huge demographic.
A huge overlap in two groups would obviously be at most 100% of the smaller group.
Is there a huge demographic for grapheneOS and/or fairphone? Let alone one that doesn't overlap with the archetypes that post here?
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.
Without support of alternative OS Fairphone is basically a landfill. Why would anyone buy this apart from novelty factor.
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.
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.
[1] https://forum.fairphone.com/t/official-lineageos-23-for-the-...
[2] https://wiki.postmarketos.org/wiki/Fairphone_(Gen._6)_(fairp...
You should search for the many times where GrapheneOS has stated they won't work with Fairphone
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.
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.
Yes, they can, but they have promoted /e/OS, and they have no ability to develop Android.
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.
Why? Because of drivers? Don’t they already have Linux drivers for the fairphone?
I wonder if fable or astra could wire everything up.
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.)
Yep. Gos isn't the only mfg in town if you have or want a fairphone.
https://wiki.postmarketos.org/wiki/Fairphone_(Gen._6)_(fairp...
I would imagine the cross section of people who seek out GOS but would settle for Postmarket OS is nearly non existent.
Then you have poor imagination. People seek Graphene OS for many many reasons.
"mfg"? They don't manufacture anything.
A distribution of software? Saas are people too!!!
Given the state of Fairphone hardware, software and business, it is not surprising.
For those of us out of the loop, could someone summarize the situation?
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.
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.
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.
Imo i think actually naming the problems is a lot more productive than walking around them
I would throw serious money at them both if this collaboration happened.
Every fairphone I've seen to far the camera was kinda ass. Did it improve? Pixel phones usually have old Samsung sensors which are pretty damn decent.
The sensor of the Fairphone camera is good enough, the software processing is what's lacking. Imo, owner of an FP4.
Some screenshots since the repo doesn't have any for whatever reason:
https://imgur.com/a/C8yV83v
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.
https://www.verizon.com/support/vtext-vzwpix-shutdown/
I'm still waiting until RCS is supported before I actually use it.
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.
How about some screenshots?
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.
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.
It's also just quite a lot of work to generate screenshots.
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
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
> 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.
An image is functionality, as it provides significant information to the reader.
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"
exactly, i am looking at screenshots for apps to get an idea about their functionality.
"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.
I was looking for the same thing. Fine! Maybe it’s in the Readme.md. Nothing! Well, ok then
I just updated mine to try it out, it definitely looks nicer.
https://imgur.com/a/ZGpbqB7
Worth raising a PR/discussion on the repo as reasonable chance the devs haven’t even considered it
Does anyone know if this is something that we can install now, or if it will show up in the next OS release?
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
They mentioned you can use the Alpha from their app installer.
Good to know! For others: You open their app store, go into messaging, hamburger menu, select release channel, and choose alpha.
It's in the alpha channel. Go in to the 'App Store' app, go to Messaging, 3 dot menu and change release channel.
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.
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.
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.
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.
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".
>not knowing what it even looks like
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.
> 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.
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.
Can confirm the same works on Graphene. Also works directly from the "Recents" list.
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.
What? :)
You mean the perfectly functional (if barebones) AOSP call app? :)
It will get ported to kotlin, material 3, and jetpack compose, just like Messaging.
The one with the terrible UI, yes.
Does it do RCS?
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.
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?"
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.
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.
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)
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)?
What's so difficult about implementing RCS from a technical perspective?
https://grapheneos.social/@GrapheneOS/117225561294973728
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.
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.
Why would they support SMS then?
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.
The world unfortunately uses SMS for 2FA.
Not yet, but they do plan to add support for it.
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.
All of fossify's apps I've tried have been better than the stock apps.
Would have been cool to have encrypted SMS messages like the SMSecure app while we wait for RCS
That was really fast, they only announced it like a day or two ago IIRC? Also: no screenshots of the redesigned interface?!
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.
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)
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 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.
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?
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 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.
> 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?
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.
> 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.
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.
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...
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.
At least it is now consistent with the rest of the OSs UI.
Design is so personal. I love Material 3 Expressive personally. Each to their own :)
It’s amazing that you don’t think any of this is based on real HCI.
People prefer larger tap targets on touch screens.
> People prefer larger tap targets on touch screens.
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...
Uh. This HCI fact has been known for 30 plus years.
Are you this … poorly informed
Wake me up when I don't need to ship hundreds of dollars to Google to use this OS.
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.
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.
Set your alarm for next year when you can ship hundreds of dollars to Motorola.
Set an alarm for the typical Motorola flagship schedule then.
So..next year?
Looks prettier but a shame an obvious regression happened for one of my primary use-cases: copying one-time codes. Long pressing on a link selects the entire SMS instead of bringing up a menu for the link. [0]
Makes me wonder about all the testing now
And the issue worded/tagged as a feature instead of a regression. Are the devs aware the feature existed before?
later:
It's doubly disappointing because just 4 days ago the project wrote [1], on using AI for the new Messaging app:
"it's also helping us raise our standards for our own work by pointing it at that to get extremely pedantic criticism catching many things we would miss...We've hired multiple experienced app developers who have spent months working on modernizing the Messaging app and carefully reviewing it"
[0] https://github.com/GrapheneOS/Messaging/issues/292
[1] https://news.ycombinator.com/item?id=49592770
The notification the Messaging app produces should have the option to copy the one time code directly.
You're using software from an alpha channel.
People sometimes.
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.
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.
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.
What do you mean "why"? For the exact reason he stated in his first paragraph - a serious regression impacting his workflow.
... which seems to have nothing to do with using an LLM to do extra review.
My comment makes it pretty clear what the disappointment is:
> shame an obvious regression happened for one of my primary use-cases: copying one-time codes
Then the "later" is that even with frontier AI review tools, it was still missed
I am not alleging vibe coding - that's a strawman.