> In the longer term, we plan to add support for RCS including support for the standard end-to-end encryption (E2EE) via Messaging Layer Security (MLS). Currently, RCS including E2EE is available on GrapheneOS via Google Messages. We want to avoid the need to use Google Messages for RCS eventually.
Hell yeah. Google Messages has worked reasonably well for RCS so far (after a long and frustrating period where it didn't on T-Mobile), but having a non-Google option will be huge.
Ctrl+f clipboard, no results. What does "Secure Clipboard" in the title refer to?
The release seems to be only the SMS/RCS app, rest is future:
> We're also going to be overhauling or fully replacing the rest of the AOSP apps in the near future. AOSP Gallery is incredibly outdated and is being entirely replaced. AOSP Keyboard may be similar. We recently hired a bunch of new people and will be hiring more so our progress will be accelerating.
I hope they replace the AOSP keyboard with FUTO keyboard. I'm mostly fine with the other stock apps, but that keyboard was the one thing I absolutely had to end up replacing due to its jenky behavior.
AFAIK everything FUTO makes is open source? I haven't seen a counter-example (I have not looked hard though!), and https://futo.tech/about claims the following:
>All FUTO-funded projects are expected to be open source or develop a plan to eventually become so. No effort will ever be taken to hide from the people what their computers are doing, to limit how they use them, or to modify their behavior through their software.
I use Gboard with the network permission disabled. It works well but I hope they have a better stock keyboard, I haven't found any others that don't annoy me in one way or another.
Google can shuttle network requests to any of their other apps (or play services, if that's running) via IPC, even with the network permission disabled in Gboard.
So if you're using Graphene for privacy from Google specifically, it's not safe to install things like Gboard even with the network permission disabled. Even if they don't use IPC in this way today, there's no telling what the Google-of-tomorrow will do.
fyi disabling network permission doesn't protect against deliberate and coordinated data exfiltration. Apps can still communicate with other apps, for example with Google Play Services or any other app.
The latest FUTO works just as well as Gboard for me. Their somewhat recent update to their swiping library really changed the game, and their voice recognition is also pretty decent.
I wish Futo had the ability to use a typing heat map for more accurate predictions like SwiftKey. It constantly suggests "AMD" when I am trying to type "and". I have fat thumbs OK! I don't even have the caps on and I RARELY talk about AMD. It's just the one thing I miss. I do find the predictions generally less accurate as well, but perfectly usable.
I like Heliboard a lot, but its autocorrect gets stuck in the mud all the time.
It completely falls apart and starts injecting nonsense phrases made up of nonsense misspelled words moment you miss a space ('v' or 'b') or type a really long word it doesn't know.
It also stubbornly incorrects other things like 'a' into "and" if it thinks it knows a phrase fragment. It's always wrong. It just happened to me now twice. Above, "or type a" became "or type and". Also, "it's" became "IRS".
Heliboard would be perfect if it stuck to word-only spellcheck and never split words. Just now again, it tried correcting "heliboard" into "hellenized" and "he lib oars".
This is not a matter of just lowering how aggressive the spellcheck is. It will still generate slop every time. The only real option is to completely turn it off. Futo can have similar problems, but there are a lot more options to tweak and the defaults aren't so bad.
As someone who uses and loves Unexpected Keyboard: the higher learning curve compared to other keyboards would be the main reason I can think of. The reliance on swipes in particular is something that's likely alien to a lot of smartphone users.
Our plan is to fork ReFra and drastically change it. We have a different scope and requirements for it. ReFra will still be useful for people who want features we don't plan to provide. We've considered trying to do it as an ongoing fork and making upstream contributions which we started on but it likely isn't practical. We haven't fully decided on this.
"RCS isn't an open platform in practice. It isn't even as open as SMS/MMS. It heavily depends on proprietary Google and carrier infrastructure in practice. We can start by replicating Google's approach and then we can work on only using carrier services for carriers where it's actually supported."
Except... what carriers still remain using their own RCS carrier services and haven't been pressured by Google to adopt Jive?
Certainly, with Opus 5 and GPT-6, modernizing or even completely rewriting self-contained, non-critical tools seems like a Friday afternoon job now. I wonder however how important this is, in the grand scheme of things. I use GrapheneOS and the bundled messaging app is serviceable. It isn't pretty, but it gets the job done.
We're definitely not churning out code with AI models. There's no vibe coding going on in GrapheneOS. We're carefully writing and reviewing code as we've always done. We now have additional tools to assist with it. The main way we're using AI models is for code review and helping to write a lot more tests than we used to. It's helping to improve our code quality, not reducing it. We're not trying to get things done substantially faster.
The code generated by even the bleeding edge publicly available frontier models is rarely good enough to meet our standards. AI models are creating a lot of additional work for us because of how many more security issues are being discovered in upstream projects. 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. There's no vibe coding going on for our apps. Why not look at the actual process of porting Messaging to Compose and our code review for each incremental part of the process?
Our port of Messaging to Compose was clearly not vibe coded as both the parent comment and yours are wrongly portraying it. Experienced developers have been working on overhauling the app for months with a lot of back and forth code review to get the pull requests into shape. We don't have a policy against using AI for assistance as long as the resulting code meets our high standards.
We definitely use frontier AI models with cybersecurity access unlocked for code review. Those often find problems we didn't catch via multiple rounds of human review. The output is filled with hallucinations and incorrect details but an experienced developer can sift through it, identify the real issues it uncovered and get those fixed.
Their license is invalid due to being GPLv3. GPLv3 cannot be included in GrapheneOS as that would necessitate GrapheneOS give up their permissive licensing.
Refra Gallery is licensed as Apache 2.0, which is a permissive license GrapheneOS can bundle in the OS.
We're going to be forking one of them (ReFra). We want to make extensive changes and have a different vision for it than the upstream project. For example, we don't want it to have integration into services. There's plenty of room for both an increasingly different fork of it in GrapheneOS and the original project which our users will continue to use who want features we don't consider inside the scope of what we want from a local gallery app.
> RCS isn't an open platform in practice. It isn't even as open as SMS/MMS. It heavily depends on proprietary Google and carrier infrastructure in practice. We can start by replicating Google's approach and then we can work on only using carrier services for carriers where it's actually supported.
What is the point of RCS though? It seems to be strictly inferior to Signal. It seems a Google product meant to serve Google. I wouldn't hate it if GrapheneOS would totally ignore RCS. I fail to see any value in it, but maybe I am lacking information(?)
RCS was DOA from day one as far as I'm concerned. The carriers being involved in any capacity deeper than providing dumb pipes alone was enough to make it pointless, but no E2E in the base spec makes it extra pointless. They may as well have just extended SMS to be more capable, because that's what they've effectively created.
Agreed. Google used a standard that virtually nobody (except some carriers) cared about to get a foot in the door for better interoperability with iPhones, to try to solve an issue that is mostly US-only (green bubble anxiety),
In most of the rest of the world nobody gives a shit about RCS since we have adopted other messengers (than iMessage or SMS/MMS) ages ago, most of which are already end-to-end encrypted.
I understand why GrapheneOS has to spend time on this (the US is a large user base), but it's sad nonetheless.
RCS is an extension of SMS and has quite literally been "SMS but more capable" from the start. The protocol on the wire looks a lot like MMS over LTE. Registration and communication mostly happens over SIP and RTP like in the latest MMS specs.
The early versions of RCS were barely implemented. Android and iOS didn't bother including clients, carriers didn't bother hosting servers because the spec was optional, and third party applications made by carriers were launched and then died because carriers couldn't explain to customers why their app was better than WhatsApp e.a. for those in the market for alternative messengers.
I think it's safe to say that RCS would've died a quiet death had Google not used it as a basis for their own Hangouts alternative built into their SMS client.
When RCS was first (soft) launched back in 2008, E2EE messaging practically didn't exist. Google slapped E2EE on top when they hosted their own iMessage alternative to bring it into the modern era but the base spec was still "what if MMS wasn't so outdated and restricted".
I don't know much about RCS other than that carriers need to be involved, but there's a way to not involve them, which Google did for a while using some kind of compat-service (jibe or something?), and then they stopped doing it.
Never seen RCS working on any carrier ever since. I don't understand why Google couldn't just continue doing what it was doing. Why require carriers?
From [0], it seems that RCS can use the cellular signal instead of LTE or 5G:
> In cases where RCS is able to operate over cellular networks without data, it supports messaging as well as file transfer, enriched calling, and more.
In LTE and 5G there exists no cellular signal without data. That was a 2G/3G thing. Since 4G everything is data. The separate sms and voice services are gone. And 3G is rapidly being deprecated.
The point of the exercise is for Google and Apple to maintain control over the ecosystem.
RCS is technically superior (protocol, transport, security, all of it) but is captured from the start on the technical level by design by the big players. From the perspective of the vast majority of users who have very limited technical awareness, it was silently slipped in as an upgrade at one point or another. This means that those not adopting the proprietary BigTech solution are perceived as being difficult by insisting on using software that's now perceived as outdated or as otherwise mildly incompatible.
GrapheneOS does not want to adopt RCS for public perception. It is still a better option than SMS/MMS and providing it is beneficial. GrapheneOS will still recommend using better platforms and protocols but RCS being bundled and cross platform are great reasons to implement it.
Eh, I don’t think you have to include Apple here. If it were up to them, the iPhone would still have zero RCS support right now. The current implementation of RCS, even in iOS 27 beta, is clunky.
To me, the only they’re trying to maintain control of is AppleOS-to-AppleOS text communication.
The point is to access an e2ee protocol bundled by default on many devices, and is cross-platform.
GrapheneOS does recommend using superior platforms like Signal, but that is 3rd party, and thus has adoptability issues in convincing people to use it. Just because better platforms exist does not mean RCS should be ignored.
Thanks for clarification. Anything first party from Big Tech is a lost cause privacy wise. At the same time, nobody uses it (maybe that is different in the USA, don't know). So for me this would be ultra-low prio as I (and I expect almost every other GOS user) will never use it. But I believe GOS knows what it is doing.
RCS's point is to deliver ads. It is its first purpose.
The way I see the situation, the point for Graphene to implement RCS is to prepare for the foreseeable deprecation of SMS. Who knows when it will happen, but better start working now than wait and get stranded when it'll happen. I'm pretty sure RCS implementation will take a long while.
I believe it was meant to be federated, like SMS, and then in practice it wasn't. With Signal you depend on your carrier and on Signal - with SMS you only depend on your carrier.
All carriers I've tried in my country have even disabled MMS entirely. They're not running RCS servers either, though, everyone is on WhatsApp anyway.
In theory carriers could increase the max resolution for MMS now that 3G is essentially dead, but I doubt they will now the slow move to RCS has started.
RCS provides far better support for group chats, many small feature improvements and end-to-end encryption (E2EE) via Messaging Layer Security (MLS). E2EE for talking to GMS Android and iOS users without them needing to install another app is the main reason we care about it, but far better group chat support matters too. iPhone users very often don't want to have SMS/MMS users in their group chats.
Perhaps it's different in other countries, but I've never seen anyone use MMS. (Everyone uses WhatsApp nowadays, but even before WhatsApp existed, I never saw anyone use MMS.)
“We'll be making a new release later today with a completely overhauled user interface written in ‹whatever›” is something developers love, and users fear.
Saying it's going to be released later today means to the Alpha channel. GrapheneOS and each of our apps have Alpha, Beta and Stable channels. Every Stable channel release made it through Alpha and Beta channel testing. We don't expect the initial Messaging app release to reach the Stable channel. AOSP Messaging hasn't been actively developed since around Android 5.x and nearly no one is going to be unhappy with the changes.
We're changing very little about the overall layout and structure of the app in this initial phase of the overhaul. Over the past couple months, it was carefully ported to Compose with a lot of code review and added tests. It was a lot of work and is going to look a lot more modern. It's also now possible to greatly improve the user interface in much more substantial ways than making it look modern.
If you have used GrapheneOS, you know Messaging is positively ancient and bitrotting. The overhaul makes it look like the rest of the OS and uses standard material 3. Its not something to fear.
Indeed. I don't use most of the stock AOSP apps on Graphene because the UI is so awful, but there are decent alternatives so it hasn't been a bother. I'm looking forward to seeing their work.
We spent months working on this and certainly didn't vibe code it. We do use LLMs but primarily for code review and boilerplate. We're now including a lot more tests partly thanks to it being less of a pain.
Our quality standards are too high for current frontier LLMs to generate much we could use directly. On the other hand, their code review output is extremely useful. It can find many issues we wouldn't catch even with multiple rounds of human review. It's helping us a lot with catching issues we've repeatedly overlooked.
Yeah, I know you guys are using LLMs responsibly. I just found those anti-LLM crusaders funny they way they were calling it an unethical and fascist technology.
As long as the code is being held to the same standards (which have been very high), it's only going to help the developers.
Btw, please save yourself some energy and mental peace by ignoring these people who haven't written a single line of serious code and are only there for bandwagoning and pushing their political agendas. Love the work that you guys do that's why I'd love for you guys to be able to focus on the mission and not get distracted by them. Thanks for all the hard work!
I don't really get why so many Americans want RCS to succeed though. Do you guys not remember when carriers charged 10p/text? Why on earth would you want to give any power at all back to those people?
After getting several family group chats finally converted over to RCS, one day my phone just started absolutely refusing to verify my connection to the RCS servers. Instead of any kind of notification, I was just silently not sending or receiving messages for nearly an entire day. I had to disable RCS on my phone, which created a several day long issue where some chats would just fall back to SMS and others absolutely refused to work, or strange interactions with Apple devices where certain messages would not be displayed. After enough trouble with it I convinced everyone to switch to a third party messaging app. I'll never turn RCS on again, I can't trust that it won't just start silently failing.
Americans have had unlimited texting plans for much longer than Europeans. I'm pretty sure most Americans had unlimited texts before Whatsapp existed, so there was never the move to it for economic reasons.
Yes I think this is the main reason for WhatsApp's popularity in Europe. Our providers were hanging on to sms as a cash cow and they were pretty much the most expensive bits you could send.
Malicious providers like kpn in the Netherlands even sought to charge extra for WhatsApp traffic because they lost so much revenue. However the EU shot that down hard under net neutrality.
But I remember it well and this is why I always disable RCS. I don't ever want to give my provider the chance to do that again. And I don't trust Google either. SMS is completely dead here too. It's been years since anyone sent me a personal message. It's just spam and poorly implemented 2FA shit.
It's not an issue here in Spain anyway. The only phone with iPhones are rich expats. Most of the people I know use cheap budget androids.
The main benefit of RCS is the fact it is available by default on other platforms like certified android and IOS. 3rd party messaging apps hit adoptability issues. A bundled, cross platform E2EE protocol is a huge step above SMS and MMS.
Text messages in iMessage or SMS are a fairly US-centric relic.
That's not to say overseas is better - Europe depends on Whatsapp - but outside the US the whole 'blue box' thing isn't even a thing.
It makes group messaging work a lot better, too. Previously, group chats with a mixture of ios and android users were really buggy leading to iPhone users significantly preferring group chats with all ios, which led to some social exclusion for android users in the US, leading to market dominance for iPhones. Now, with RCS, you can make a functional group chat across platforms and you don't have to convince anybody to install something new.
RCS provides properly working group chats and end-to-end encryption with iOS and GMS Android users without having to succeed at convincing people to use Signal instead.
Maybe they'll work on the backup now, this *** seedvault is worse than nothing (consistently broken on both my GOS phones, never giving the same results with 2 backups, never giving out as much as the status I could trust)
One of the parties involved in a call recording it is not surveillance. It's comparable to having chat logs for text messaging. Contrary to what you've claimed, vast majority of US states have one party consent for call recording. GrapheneOS Foundation is based in Canada where one party consent is the law.
Our feature is designed for people to comply with the law in jurisdictions requiring two party consent. It shows a notice for every inbound and outbound call where call recording will be enabled. It also has a per-contact toggle for enabling it instead of simply being either enabled or disabled. We also plan to offer the option to have it automatically disclose the call is being recorded.
Apps are written for android. Graphene can run all the apps because it's android. If it couldn't run apps, you wouldn't use it. Are you posting today from a pinephone?
Their post history has several posts related to PostmarketOS on the Fairphone, so kind of, possibly? pmOS does have Waydroid to run Android apps, though, which also relies on AOSP.
What's the concern? They are working with Motorola as a manufacturer. It'll probably be a hard fork eventually but why not make it work in the meantime.
If they hard fork, a lot of apps that are generally "necessary for the average person" (e.g. Uber, banking apps, Gmail, Whatsapp/Wechat/Line) might stop working.
Seriously, I don't see a mediocre android provider like Motorola running and maintaining a hard fork.
Forking is all easy, keeping it up to date year after year as codebases diverge is a whole different story.
I could see Samsung doing it. But they won't, they're too good buddies with Google. But they have the resources. A Motorola no. The grapheneos team won't either, maintaining a disparate fork and introducing new features independently from aosp would just be beyond their scope. You're not just hardening at that point. You're basically doing everything.
Don't forget when Huawei didn't fork. Well they started with that but then replaced every component with their own design. It's easier because if you fork you're still bound by decisions made by the original party. Better to greenfield the whole thing then.
And look at how many people made a soft fork of chrome with some ui changes. There's tons of those. There's no hard fork that no longer follows Google. Even a large company like Microsoft didn't.
So what should they do instead? Just give up? Assume that it's simply inevitable that Google will cancel AOSP entirely and so Graphene should hurry up and die?
Apple isn't going to let them build on top of iOS, and anything except those two is dead in the water because it'll never have users because it is missing a bunch of critical apps, and will never have those apps because it doesn't have users.
Yes RCS is a pig with lipstick. Invented by the carriers to recoup some control over instant messaging, then abandoned and picked up by Google for the same reason. They're the ones that added encryption to it.
It was always meant to be a walled garden. Exactly what an open system shouldn't be.
It's important for us to provide out-of-the-box end-to-end encrypted (E2EE) messaging for contacts on Google Messages and iOS. Both Google Messages and iOS provide RCS with end-to-end encryption via Messaging Layer Security (MLS). Google Messages is the standard text messaging app on Google Mobile Services Android and iOS now also supports RCS with MLS. The vast majority of people have an E2EE messaging app on their smartphone and it's important for us to provide compatibility with it. Currently, a growing number of our users are installing Google Messages to have better usability and privacy for texting with contacts on Google Messages and iOS.
People can already install the messaging apps of their choice on GrapheneOS. It would go against our approach to choose specific messaging apps and protocols to bundle with the OS beyond SMS/MMS/RCS. We shouldn't be the ones choosing Signal vs. SimpleX vs. Element or other options but rather that's up to users to decide. We need a messaging app to handle carrier-based messaging in the OS including providing end-to-end encryption for it and the rest is up to other open source developers.
Unless one wants interoperability with other people who use Apple and "Samsung" (because they don't know the word Android refers to an OS). It's a de facto standard now, whether you like it or not.
Android and IOS encrypt your device. Most modern phones do, that is not specific to GrapheneOS and is an important, generic part of data safety that has been used for decades.
GrapheneOS offers a duress PIN/password, not button, that is solely up to the user to use as they see fit. The threat model for its use is on the user to determine, and the example you are referring to was a judgement that person made. That decision is independent of GrapheneOS.
Whether or not it was a blunder can only be known by the person who used it. Maybe it was a miscalculation, or maybe they were trying to hide something of importance, like protected contacts in an authoritarian country. We cannot know.
Duress PIN is for when the consequences of having the data are worse than erasing the data. This is very important for journalists or citizens of an authoritarian government. The judgements these people make are not a reflection of GrapheneOS.
We've done months of work on overhauling the Messaging app. It has been done in incremental portions with code review for each. It often goes back and forth several times before it gets merged. Why not look at the quite open development and code review process on GitHub?
Every release of GrapheneOS and GrapheneOS apps goes through internal testing followed by public Alpha channel testing and then public Beta channel testing before reaching the Stable channel. No update goes to Stable without internal, Alpha and Beta channel testing phases.
We've been heavily testing our Messaging overhaul as we've been doing it and we've been making a lot more tests than we used to. It's already in quite good shape and is ready for Alpha channel testing. That's what we're referring to.
What? The Messages overhaul has been going on in the background for months. They announced it near the end of the port rather than the start. What is wrong with that? It has nothing to do with AI.
You can check github and see this development has been going on for awhile.
> In the longer term, we plan to add support for RCS including support for the standard end-to-end encryption (E2EE) via Messaging Layer Security (MLS). Currently, RCS including E2EE is available on GrapheneOS via Google Messages. We want to avoid the need to use Google Messages for RCS eventually.
Hell yeah. Google Messages has worked reasonably well for RCS so far (after a long and frustrating period where it didn't on T-Mobile), but having a non-Google option will be huge.
Ctrl+f clipboard, no results. What does "Secure Clipboard" in the title refer to?
The release seems to be only the SMS/RCS app, rest is future:
> We're also going to be overhauling or fully replacing the rest of the AOSP apps in the near future. AOSP Gallery is incredibly outdated and is being entirely replaced. AOSP Keyboard may be similar. We recently hired a bunch of new people and will be hiring more so our progress will be accelerating.
There's a separate thread about our secure clipboard feature:
https://bsky.app/profile/grapheneos.org/post/3muupuvlfbs2v
We posted it right after the Messaging app thread but they're separate topics.
https://grapheneos.social/@GrapheneOS/117225731764489295
https://bsky.app/profile/grapheneos.org/post/3muupuvlfbs2v
[dead]
I hope they replace the AOSP keyboard with FUTO keyboard. I'm mostly fine with the other stock apps, but that keyboard was the one thing I absolutely had to end up replacing due to its jenky behavior.
I agree FUTO is the best right now but it's not open source so they won't.
The source is here: https://gitlab.futo.org/keyboard/latinime
Featured prominently in the "Source Code" container on https://keyboard.futo.tech/
AFAIK everything FUTO makes is open source? I haven't seen a counter-example (I have not looked hard though!), and https://futo.tech/about claims the following:
>All FUTO-funded projects are expected to be open source or develop a plan to eventually become so. No effort will ever be taken to hide from the people what their computers are doing, to limit how they use them, or to modify their behavior through their software.
7 replies →
[dead]
I use Gboard with the network permission disabled. It works well but I hope they have a better stock keyboard, I haven't found any others that don't annoy me in one way or another.
Google can shuttle network requests to any of their other apps (or play services, if that's running) via IPC, even with the network permission disabled in Gboard.
So if you're using Graphene for privacy from Google specifically, it's not safe to install things like Gboard even with the network permission disabled. Even if they don't use IPC in this way today, there's no telling what the Google-of-tomorrow will do.
fyi disabling network permission doesn't protect against deliberate and coordinated data exfiltration. Apps can still communicate with other apps, for example with Google Play Services or any other app.
The latest FUTO works just as well as Gboard for me. Their somewhat recent update to their swiping library really changed the game, and their voice recognition is also pretty decent.
1 reply →
I wish Futo had the ability to use a typing heat map for more accurate predictions like SwiftKey. It constantly suggests "AMD" when I am trying to type "and". I have fat thumbs OK! I don't even have the caps on and I RARELY talk about AMD. It's just the one thing I miss. I do find the predictions generally less accurate as well, but perfectly usable.
Heliboard is good, customizable, and actually open source - GPL3.
If you are referring to Heliboard as an AOSP board replacement, that cannot work, GrapheneOS cannot use GPLv3 projects.
If you mean it as a user installed app, please disregard.
I like Heliboard a lot, but its autocorrect gets stuck in the mud all the time.
It completely falls apart and starts injecting nonsense phrases made up of nonsense misspelled words moment you miss a space ('v' or 'b') or type a really long word it doesn't know.
It also stubbornly incorrects other things like 'a' into "and" if it thinks it knows a phrase fragment. It's always wrong. It just happened to me now twice. Above, "or type a" became "or type and". Also, "it's" became "IRS".
Heliboard would be perfect if it stuck to word-only spellcheck and never split words. Just now again, it tried correcting "heliboard" into "hellenized" and "he lib oars".
This is not a matter of just lowering how aggressive the spellcheck is. It will still generate slop every time. The only real option is to completely turn it off. Futo can have similar problems, but there are a lot more options to tweak and the defaults aren't so bad.
3 replies →
They cannot. The license FUTO uses is not open source and is incompatible with being bundled with GrapheneOS.
Why not Unexpected Keyboard?
As someone who uses and loves Unexpected Keyboard: the higher learning curve compared to other keyboards would be the main reason I can think of. The reliance on swipes in particular is something that's likely alien to a lot of smartphone users.
I believe this is the planned gallery app. I've already been using it: https://github.com/IacobIonut01/ReFra
Our plan is to fork ReFra and drastically change it. We have a different scope and requirements for it. ReFra will still be useful for people who want features we don't plan to provide. We've considered trying to do it as an ongoing fork and making upstream contributions which we started on but it likely isn't practical. We haven't fully decided on this.
Just tried this out. I may soon be cancelling by Google Photos subscription...
While you're doing that check out Immich - https://immich.app
One of the best solutions I've ever used for photos, backups, enrichment, etc
twitter versions have paragraphs not threads
https://xcancel.com/GrapheneOS/status/2096677808424788256#m
https://nitter.click/GrapheneOS/status/2096677808424788256#m
https://bsky.app/profile/grapheneos.org/post/3muun5c4fdc2o
Secure paste:
https://xcancel.com/GrapheneOS/status/2096685327020933355#m
https://nitter.click/GrapheneOS/status/2096685327020933355#m
https://grapheneos.social/@GrapheneOS/117225731764489295
https://bsky.app/profile/grapheneos.org/post/3muupuvlfbs2v
"RCS isn't an open platform in practice. It isn't even as open as SMS/MMS. It heavily depends on proprietary Google and carrier infrastructure in practice. We can start by replicating Google's approach and then we can work on only using carrier services for carriers where it's actually supported."
Except... what carriers still remain using their own RCS carrier services and haven't been pressured by Google to adopt Jive?
None except Jio in India and various carriers in China
Certainly, with Opus 5 and GPT-6, modernizing or even completely rewriting self-contained, non-critical tools seems like a Friday afternoon job now. I wonder however how important this is, in the grand scheme of things. I use GrapheneOS and the bundled messaging app is serviceable. It isn't pretty, but it gets the job done.
We're definitely not churning out code with AI models. There's no vibe coding going on in GrapheneOS. We're carefully writing and reviewing code as we've always done. We now have additional tools to assist with it. The main way we're using AI models is for code review and helping to write a lot more tests than we used to. It's helping to improve our code quality, not reducing it. We're not trying to get things done substantially faster.
The code generated by even the bleeding edge publicly available frontier models is rarely good enough to meet our standards. AI models are creating a lot of additional work for us because of how many more security issues are being discovered in upstream projects. 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. There's no vibe coding going on for our apps. Why not look at the actual process of porting Messaging to Compose and our code review for each incremental part of the process?
https://github.com/GrapheneOS/Messaging/pulls?q=is%3Apr+is%3...
I'm really glad to read this. Thanks for putting in the effort to make quality software, far too few people are willing to do that these days.
[flagged]
Our port of Messaging to Compose was clearly not vibe coded as both the parent comment and yours are wrongly portraying it. Experienced developers have been working on overhauling the app for months with a lot of back and forth code review to get the pull requests into shape. We don't have a policy against using AI for assistance as long as the resulting code meets our high standards.
We definitely use frontier AI models with cybersecurity access unlocked for code review. Those often find problems we didn't catch via multiple rounds of human review. The output is filled with hallucinations and incorrect details but an experienced developer can sift through it, identify the real issues it uncovered and get those fixed.
2 replies →
I dunno. If they're using AI, it's well controlled. I don't see a lot of artifacts you usually get from full-on vibe-coding.
1 reply →
There are excellent FOSS gallery apps already, like the Fossify suite. Why not use them I wonder?
Their license is invalid due to being GPLv3. GPLv3 cannot be included in GrapheneOS as that would necessitate GrapheneOS give up their permissive licensing.
Refra Gallery is licensed as Apache 2.0, which is a permissive license GrapheneOS can bundle in the OS.
Its not part of the OS so why would it affect the Graphene OS license? Its an app, not a library.
12 replies →
Can the Linux kernel be included in the OS?
4 replies →
We're going to be forking one of them (ReFra). We want to make extensive changes and have a different vision for it than the upstream project. For example, we don't want it to have integration into services. There's plenty of room for both an increasingly different fork of it in GrapheneOS and the original project which our users will continue to use who want features we don't consider inside the scope of what we want from a local gallery app.
Media handlers are a security nightmare, might lead you to the right answer if it isn’t it.
What is the point of RCS though? It seems to be strictly inferior to Signal. It seems a Google product meant to serve Google. I wouldn't hate it if GrapheneOS would totally ignore RCS. I fail to see any value in it, but maybe I am lacking information(?)
RCS was DOA from day one as far as I'm concerned. The carriers being involved in any capacity deeper than providing dumb pipes alone was enough to make it pointless, but no E2E in the base spec makes it extra pointless. They may as well have just extended SMS to be more capable, because that's what they've effectively created.
RCS was DOA from day one as far as I'm concerned.
Agreed. Google used a standard that virtually nobody (except some carriers) cared about to get a foot in the door for better interoperability with iPhones, to try to solve an issue that is mostly US-only (green bubble anxiety),
In most of the rest of the world nobody gives a shit about RCS since we have adopted other messengers (than iMessage or SMS/MMS) ages ago, most of which are already end-to-end encrypted.
I understand why GrapheneOS has to spend time on this (the US is a large user base), but it's sad nonetheless.
RCS is an extension of SMS and has quite literally been "SMS but more capable" from the start. The protocol on the wire looks a lot like MMS over LTE. Registration and communication mostly happens over SIP and RTP like in the latest MMS specs.
The early versions of RCS were barely implemented. Android and iOS didn't bother including clients, carriers didn't bother hosting servers because the spec was optional, and third party applications made by carriers were launched and then died because carriers couldn't explain to customers why their app was better than WhatsApp e.a. for those in the market for alternative messengers.
I think it's safe to say that RCS would've died a quiet death had Google not used it as a basis for their own Hangouts alternative built into their SMS client.
When RCS was first (soft) launched back in 2008, E2EE messaging practically didn't exist. Google slapped E2EE on top when they hosted their own iMessage alternative to bring it into the modern era but the base spec was still "what if MMS wasn't so outdated and restricted".
The RCS spec has encryption in its documentation. I think the current spec version is 4.0?
3 replies →
I don't know much about RCS other than that carriers need to be involved, but there's a way to not involve them, which Google did for a while using some kind of compat-service (jibe or something?), and then they stopped doing it.
Never seen RCS working on any carrier ever since. I don't understand why Google couldn't just continue doing what it was doing. Why require carriers?
3 replies →
From [0], it seems that RCS can use the cellular signal instead of LTE or 5G:
> In cases where RCS is able to operate over cellular networks without data, it supports messaging as well as file transfer, enriched calling, and more.
[0]: https://en.wikipedia.org/wiki/Rich_Communication_Services
In LTE and 5G there exists no cellular signal without data. That was a 2G/3G thing. Since 4G everything is data. The separate sms and voice services are gone. And 3G is rapidly being deprecated.
4 replies →
The point of the exercise is for Google and Apple to maintain control over the ecosystem.
RCS is technically superior (protocol, transport, security, all of it) but is captured from the start on the technical level by design by the big players. From the perspective of the vast majority of users who have very limited technical awareness, it was silently slipped in as an upgrade at one point or another. This means that those not adopting the proprietary BigTech solution are perceived as being difficult by insisting on using software that's now perceived as outdated or as otherwise mildly incompatible.
GrapheneOS does not want to adopt RCS for public perception. It is still a better option than SMS/MMS and providing it is beneficial. GrapheneOS will still recommend using better platforms and protocols but RCS being bundled and cross platform are great reasons to implement it.
Eh, I don’t think you have to include Apple here. If it were up to them, the iPhone would still have zero RCS support right now. The current implementation of RCS, even in iOS 27 beta, is clunky.
To me, the only they’re trying to maintain control of is AppleOS-to-AppleOS text communication.
3 replies →
It's nice to be able to send/receive photos with more than 13 pixels in them.
The point is to access an e2ee protocol bundled by default on many devices, and is cross-platform.
GrapheneOS does recommend using superior platforms like Signal, but that is 3rd party, and thus has adoptability issues in convincing people to use it. Just because better platforms exist does not mean RCS should be ignored.
Thanks for clarification. Anything first party from Big Tech is a lost cause privacy wise. At the same time, nobody uses it (maybe that is different in the USA, don't know). So for me this would be ultra-low prio as I (and I expect almost every other GOS user) will never use it. But I believe GOS knows what it is doing.
7 replies →
RCS's point is to deliver ads. It is its first purpose. The way I see the situation, the point for Graphene to implement RCS is to prepare for the foreseeable deprecation of SMS. Who knows when it will happen, but better start working now than wait and get stranded when it'll happen. I'm pretty sure RCS implementation will take a long while.
I believe it was meant to be federated, like SMS, and then in practice it wasn't. With Signal you depend on your carrier and on Signal - with SMS you only depend on your carrier.
RCS allows higher resolution pictures than MMS.
All carriers I've tried in my country have even disabled MMS entirely. They're not running RCS servers either, though, everyone is on WhatsApp anyway.
In theory carriers could increase the max resolution for MMS now that 3G is essentially dead, but I doubt they will now the slow move to RCS has started.
RCS provides far better support for group chats, many small feature improvements and end-to-end encryption (E2EE) via Messaging Layer Security (MLS). E2EE for talking to GMS Android and iOS users without them needing to install another app is the main reason we care about it, but far better group chat support matters too. iPhone users very often don't want to have SMS/MMS users in their group chats.
Perhaps it's different in other countries, but I've never seen anyone use MMS. (Everyone uses WhatsApp nowadays, but even before WhatsApp existed, I never saw anyone use MMS.)
3 replies →
“We'll be making a new release later today with a completely overhauled user interface written in ‹whatever›” is something developers love, and users fear.
Saying it's going to be released later today means to the Alpha channel. GrapheneOS and each of our apps have Alpha, Beta and Stable channels. Every Stable channel release made it through Alpha and Beta channel testing. We don't expect the initial Messaging app release to reach the Stable channel. AOSP Messaging hasn't been actively developed since around Android 5.x and nearly no one is going to be unhappy with the changes.
We're changing very little about the overall layout and structure of the app in this initial phase of the overhaul. Over the past couple months, it was carefully ported to Compose with a lot of code review and added tests. It was a lot of work and is going to look a lot more modern. It's also now possible to greatly improve the user interface in much more substantial ways than making it look modern.
If you have used GrapheneOS, you know Messaging is positively ancient and bitrotting. The overhaul makes it look like the rest of the OS and uses standard material 3. Its not something to fear.
Indeed. I don't use most of the stock AOSP apps on Graphene because the UI is so awful, but there are decent alternatives so it hasn't been a bother. I'm looking forward to seeing their work.
LineageOS keyboard and the Trebuchet launcher would be most helpful.
I do miss keyboard symbols without shifting and icon packs.
FUTO Keyboard or Heliboard (both FOSS) will give you key symbols without shifting, as will likely several other FOSS keyboards.
Funny reading those anti-LLM comments, lol
We spent months working on this and certainly didn't vibe code it. We do use LLMs but primarily for code review and boilerplate. We're now including a lot more tests partly thanks to it being less of a pain.
Our quality standards are too high for current frontier LLMs to generate much we could use directly. On the other hand, their code review output is extremely useful. It can find many issues we wouldn't catch even with multiple rounds of human review. It's helping us a lot with catching issues we've repeatedly overlooked.
Yeah, I know you guys are using LLMs responsibly. I just found those anti-LLM crusaders funny they way they were calling it an unethical and fascist technology.
As long as the code is being held to the same standards (which have been very high), it's only going to help the developers.
Btw, please save yourself some energy and mental peace by ignoring these people who haven't written a single line of serious code and are only there for bandwagoning and pushing their political agendas. Love the work that you guys do that's why I'd love for you guys to be able to focus on the mission and not get distracted by them. Thanks for all the hard work!
Very good idea! Google abandoned these long ago.
I don't really get why so many Americans want RCS to succeed though. Do you guys not remember when carriers charged 10p/text? Why on earth would you want to give any power at all back to those people?
After getting several family group chats finally converted over to RCS, one day my phone just started absolutely refusing to verify my connection to the RCS servers. Instead of any kind of notification, I was just silently not sending or receiving messages for nearly an entire day. I had to disable RCS on my phone, which created a several day long issue where some chats would just fall back to SMS and others absolutely refused to work, or strange interactions with Apple devices where certain messages would not be displayed. After enough trouble with it I convinced everyone to switch to a third party messaging app. I'll never turn RCS on again, I can't trust that it won't just start silently failing.
Americans have had unlimited texting plans for much longer than Europeans. I'm pretty sure most Americans had unlimited texts before Whatsapp existed, so there was never the move to it for economic reasons.
Yes I think this is the main reason for WhatsApp's popularity in Europe. Our providers were hanging on to sms as a cash cow and they were pretty much the most expensive bits you could send.
Malicious providers like kpn in the Netherlands even sought to charge extra for WhatsApp traffic because they lost so much revenue. However the EU shot that down hard under net neutrality.
But I remember it well and this is why I always disable RCS. I don't ever want to give my provider the chance to do that again. And I don't trust Google either. SMS is completely dead here too. It's been years since anyone sent me a personal message. It's just spam and poorly implemented 2FA shit.
It's not an issue here in Spain anyway. The only phone with iPhones are rich expats. Most of the people I know use cheap budget androids.
The main benefit of RCS is the fact it is available by default on other platforms like certified android and IOS. 3rd party messaging apps hit adoptability issues. A bundled, cross platform E2EE protocol is a huge step above SMS and MMS.
Many 3rd party platforms are still better though.
It's a bandaid over iMessage's dominance among iOS users.
Text messages in iMessage or SMS are a fairly US-centric relic. That's not to say overseas is better - Europe depends on Whatsapp - but outside the US the whole 'blue box' thing isn't even a thing.
The only benefit is sending higher DPI pictures between android and ios
It makes group messaging work a lot better, too. Previously, group chats with a mixture of ios and android users were really buggy leading to iPhone users significantly preferring group chats with all ios, which led to some social exclusion for android users in the US, leading to market dominance for iPhones. Now, with RCS, you can make a functional group chat across platforms and you don't have to convince anybody to install something new.
3 replies →
RCS provides properly working group chats and end-to-end encryption with iOS and GMS Android users without having to succeed at convincing people to use Signal instead.
I'm happy todays update shipped auto call recording.
Yay! Finally, been waiting for it for ages.
Maybe they'll work on the backup now, this *** seedvault is worse than nothing (consistently broken on both my GOS phones, never giving the same results with 2 backups, never giving out as much as the status I could trust)
[flagged]
One of the parties involved in a call recording it is not surveillance. It's comparable to having chat logs for text messaging. Contrary to what you've claimed, vast majority of US states have one party consent for call recording. GrapheneOS Foundation is based in Canada where one party consent is the law.
Our feature is designed for people to comply with the law in jurisdictions requiring two party consent. It shows a notice for every inbound and outbound call where call recording will be enabled. It also has a per-contact toggle for enabling it instead of simply being either enabled or disabled. We also plan to offer the option to have it automatically disclose the call is being recorded.
2 replies →
Graphene is clearly bullish on Android, but I have no idea why. The writing is on the wall, Google is slowly asphyxiating AOSP.
Apps are written for android. Graphene can run all the apps because it's android. If it couldn't run apps, you wouldn't use it. Are you posting today from a pinephone?
Their post history has several posts related to PostmarketOS on the Fairphone, so kind of, possibly? pmOS does have Waydroid to run Android apps, though, which also relies on AOSP.
1 reply →
What's the concern? They are working with Motorola as a manufacturer. It'll probably be a hard fork eventually but why not make it work in the meantime.
If they hard fork, a lot of apps that are generally "necessary for the average person" (e.g. Uber, banking apps, Gmail, Whatsapp/Wechat/Line) might stop working.
5 replies →
Seriously, I don't see a mediocre android provider like Motorola running and maintaining a hard fork.
Forking is all easy, keeping it up to date year after year as codebases diverge is a whole different story.
I could see Samsung doing it. But they won't, they're too good buddies with Google. But they have the resources. A Motorola no. The grapheneos team won't either, maintaining a disparate fork and introducing new features independently from aosp would just be beyond their scope. You're not just hardening at that point. You're basically doing everything.
Don't forget when Huawei didn't fork. Well they started with that but then replaced every component with their own design. It's easier because if you fork you're still bound by decisions made by the original party. Better to greenfield the whole thing then.
And look at how many people made a soft fork of chrome with some ui changes. There's tons of those. There's no hard fork that no longer follows Google. Even a large company like Microsoft didn't.
4 replies →
[flagged]
5 replies →
So what should they do instead? Just give up? Assume that it's simply inevitable that Google will cancel AOSP entirely and so Graphene should hurry up and die?
There is no alternative.
Apple isn't going to let them build on top of iOS, and anything except those two is dead in the water because it'll never have users because it is missing a bunch of critical apps, and will never have those apps because it doesn't have users.
Remember when we thought IE's monopoly could never be broken? Or windows?
Anything can and will go down. Nothing is forever.
5 replies →
> There is no alternative.
There have been several projects like Ubuntu Touch to create an open Linux for smartphones.
That would be an open alternative.
Android is not open.
6 replies →
[flagged]
3 replies →
A scratch built mobile operating system have zero chances unless it would be straight up adopted by a cellular carrier, or at least blessed by one.
There's quite a list of mobile operating systems on Wikipedia[1]. Most of them are long dead.
1: https://en.wikipedia.org/wiki/Mobile_operating_system
Yes RCS is barely a standard worth implementing, let alone the best one. Make SMS/MMS and XMPP work together seamlessly in one app, forget RCS.
Yes RCS is a pig with lipstick. Invented by the carriers to recoup some control over instant messaging, then abandoned and picked up by Google for the same reason. They're the ones that added encryption to it.
It was always meant to be a walled garden. Exactly what an open system shouldn't be.
1 reply →
It's important for us to provide out-of-the-box end-to-end encrypted (E2EE) messaging for contacts on Google Messages and iOS. Both Google Messages and iOS provide RCS with end-to-end encryption via Messaging Layer Security (MLS). Google Messages is the standard text messaging app on Google Mobile Services Android and iOS now also supports RCS with MLS. The vast majority of people have an E2EE messaging app on their smartphone and it's important for us to provide compatibility with it. Currently, a growing number of our users are installing Google Messages to have better usability and privacy for texting with contacts on Google Messages and iOS.
People can already install the messaging apps of their choice on GrapheneOS. It would go against our approach to choose specific messaging apps and protocols to bundle with the OS beyond SMS/MMS/RCS. We shouldn't be the ones choosing Signal vs. SimpleX vs. Element or other options but rather that's up to users to decide. We need a messaging app to handle carrier-based messaging in the OS including providing end-to-end encryption for it and the rest is up to other open source developers.
5 replies →
Unless one wants interoperability with other people who use Apple and "Samsung" (because they don't know the word Android refers to an OS). It's a de facto standard now, whether you like it or not.
Remember Pidgin and Trillium?
2 replies →
They may as well get ready for an eventual hard fork, then?
Have you used GrapheneOS? It's fantastic UX[1] and while probably being one of if not the most secure and private OS available.
[1] thanks to Android (once you replace some of the worse default apps, but they are doing that as we can see)
> Graphene is clearly bullish on Android, but I have no idea why.
Their resources are historically better spent hardening vs literally reinventing the wheel.
Multiple variables in that equation have changed - so it could be interesting where we end up.
Someone (else!) may yet arise chasing their stated model without Android, as well.
Perhaps they're hoping to get significant market share before they lose the opportunity for good?
[flagged]
Android and IOS encrypt your device. Most modern phones do, that is not specific to GrapheneOS and is an important, generic part of data safety that has been used for decades.
GrapheneOS offers a duress PIN/password, not button, that is solely up to the user to use as they see fit. The threat model for its use is on the user to determine, and the example you are referring to was a judgement that person made. That decision is independent of GrapheneOS.
Whether or not it was a blunder can only be known by the person who used it. Maybe it was a miscalculation, or maybe they were trying to hide something of importance, like protected contacts in an authoritarian country. We cannot know.
Duress PIN is for when the consequences of having the data are worse than erasing the data. This is very important for journalists or citizens of an authoritarian government. The judgements these people make are not a reflection of GrapheneOS.
????????????
[flagged]
We've done months of work on overhauling the Messaging app. It has been done in incremental portions with code review for each. It often goes back and forth several times before it gets merged. Why not look at the quite open development and code review process on GitHub?
https://github.com/GrapheneOS/Messaging/pulls?q=is%3Apr+is%3...
Every release of GrapheneOS and GrapheneOS apps goes through internal testing followed by public Alpha channel testing and then public Beta channel testing before reaching the Stable channel. No update goes to Stable without internal, Alpha and Beta channel testing phases.
We've been heavily testing our Messaging overhaul as we've been doing it and we've been making a lot more tests than we used to. It's already in quite good shape and is ready for Alpha channel testing. That's what we're referring to.
What? The Messages overhaul has been going on in the background for months. They announced it near the end of the port rather than the start. What is wrong with that? It has nothing to do with AI.
You can check github and see this development has been going on for awhile.