HI version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
67% Positive
Analyzed from 4112 words in the discussion.
Trending Topics
#rcs#app#google#grapheneos#messaging#fairphone#support#sms#apps#call
Discussion (216 Comments)Read Original on HackerNews
This is no great conundrum. There is simply a large set overlap. A lot of the people who care about one one, also care about the other.
It's the same as Framework owners and Linux users.
FW is not a linux laptop company. They didn't even barely say the word Linux initially. Their selling point was the repairability and configurability. Only after they had been shipping for a while it became unavoidable that a huge fraction of their users were linux and even freebsd users. Only after some time and only gradually they started providing a little bit of official acknowledgement and support for Linux.
But repair parts and linux os don't have anything to do with each other! zomg why is everyone conflating Framework with a linux laptop company???
Device support code updated to new monthly, quarterly and yearly releases of AOSP within several months to provide new security improvements (Pixels receive these in the month they're released)
Fairphone's hardware and software is developed by a Chinese ODM (T2Mobile), who even have difficulty pushing out monthly patches very timely. They don't even do QPR2s, major Android updates are very late (usually almost a year), they rarely do driver firmware or kernel updates. There is no way they could fulfill this guarantee unless they started doing software development in-house and paid Qualcomm for monthly firmware updates.
Why would that mean it could compete with a Pixel which generally has none of those goals?
Pixels have long term availability of official parts for repairs and also official repairs.
Unlike Fairphones, Pixels have very good updates over the long term. Fairphones do not provide anything close to decent updates and it greatly degrades over the lifetime of the device. Fairphone 5 and earlier have an end-of-life kernel without security support. The devices start out lagging months behind on partial security backports and a year or more behind on full security updates which gets worse over time.
https://imgur.com/a/C8yV83v
> The more an article would benefit from photos, the less likely it’ll have them.
Case in point, I recently wrote a CLI to show which of your AWS infra is not captured in terraform, and you can either print the result as a json to consume by a machine or generate a dashboard with some charts. It took me an embarrassing while to realise that I should have included a damned screenshot in the README, in fact I think I only realised when I wanted to show it to my brother.
Which is a bummer because it is a complete different point of view from the more typical user experience
In many cases the repository isn't meant to be more than for source code too, not everyone use their git repository as also the marketing page, that'd go somewhere else.
With that said, grapheneos.org doesn't seem to have any screenshots either, which I also don't understand and think is a bummer. Even though the point of the differences with GrapheneOS might not be mainly visual, just showing what it looks like seem like a no-brainer.
It's like we've had this ancient knowledge passed down for generations but people constantly just ignore it.
GrapheneOS users can update to it via the Alpha channel and try it out rather than looking at screenshots. There's still more to improve before it will go to the Beta and Stable channels.
It's the default SMS/MMS app for GrapheneOS and isn't available for use outside GrapheneOS so we aren't trying to promote it as an option.
https://imgur.com/a/ZGpbqB7
Your comment is unnecessarily inflammatory.
There's only a handful of critical details in a call history, and absolutely no reason for any UI to implement them as secondary or tertiary details: Whether it was in- or outbound. To/from what contact. The date and time.
2 taps for some other extra info such as call length, or further contact details, would be OK I guess, but for first-level info as these, it's 100% bad design.
I mean come on, design-wise this was already a "Done" thing in the golden Nokia days! https://the-gadgeteer.com/2009/03/02/a-week-with-the-nokia-n...
[*] Ctrl+F to find the image below "miss a call".
Clearly.
>There's only a handful of critical details in a call history
And they're all there: profile pic, contact name, indicators that show incoming/outgoing + missed/connected, which SIM, a redial button, how long ago (which after about a week shows the date), Tapping the middle expands the row (no obstructive pop-up) to show Block, Message, & Details buttons.
The reason it has 'human times' is because multiple calls with the same contact are grouped, so a precise time doesn't always make sense. Tapping the Details will show all calls in that group, whether it's one or seven, with their full dates, times, durations, and further options. It's never been a difficult UX.
I might be mistaken but I seem to recall it being a done thing for android prior to several years ago when it was "improved" with an update. Although it's possible I'm confusing the call apps from AOSP and various vendors. Either way several of my past android devices had a significantly better address book, dialer, and call history.
Also, GrapheneOS has very recently released automatic call recording for the Dialer.
You mean the perfectly functional (if barebones) AOSP call app? :)
So having a bare bones aosp messaging app was never an issue for me. Having said that, I find fossify messages pretty good.
Will try out the new GOS app too.
AFAIUI though GOS does intend on providing an RCS impl eventually even if it takes years to do.
Do NOT talk about privacy, E2EE, or any of that. To regular people, "privacy" has negative value, so even if they wanted something, your talk of private communication and not being scanned by data brokers and governments will make them want it less.
So what to do then?
I present Signal as a novelty and focus on one single feature: "hey, video calls work much better than WhatsApp! Try it out!"
Bam, instant download.
I broadly expect third-party RCS apps to drop that though, like how essentially none support all of MMS. did you know MMS supports slideshows (I built support for this once)? 3d objects (mimetype model/gltf+json)? "timed text" (mimetype text/mp4)?
In my experience, Graphene OS doesn't make compromises.
Of course it is relevant privacy-wise (Google still gather a lot of metadata about who speaks to who and when), but that's not even the reason I'm mentioning it.
In the RCS specification, there are three lines on a killer-feature: device attestation. A server can whitelist which devices are allowed to connect to it. And of course Google uses this, allowing only Google-certified devices and Apple devices.
And then, there is actually one RCS client for Google's RCS servers. Because Google Messages doesn't use RCS, it uses a custom protocol based on protobuf. My personal guess is that this protobuf is a 1-to-1 matching with actual RCS, and it's both-way compatible. But still, that means that potentially the Google device-attestation won't work with an RCS client.
Sibling comments say that GrapheneOS plan on implementing it. I think it can reasonably work. TBH I'm expecting that giving a LLM the publicly available information about RCS on microG should give a working "send message" within a day (even when using Google apps rather than microG, it's just that the microG work explains the API). And once RCS work in GrapheneOS' message app, it should be pretty straightforward to port to microG, so yay. However I have to admit I'm not optimist about how long it will keep working. I'd say we are two years away from Google enforcing RKP device integrity for RCS, and uh, good luck passing that.
Of course, I'm hoping that, in the EU, the DMA will break this Google/Apple-only device-attestation, but I'm not aware of anyone pushing that ATM.
Unfortunately I think that feature is shutting down.
https://www.verizon.com/support/vtext-vzwpix-shutdown/
I'm still waiting until RCS is supported before I actually use it.
It's not as funny in hindsight, given the unexpected results of that election, but at the time, it felt like top-tier humor.
(sarcasm obvious, but indeed full system backup is sorely missing. Seedvault is crap, not an option)
So now I must have extra dedicated app just for SMS, which could be replaced easily with another alternative messenger if ANYONE bothered to implement simple SMS support, but seems nobody is interesting in this, so I am not interesting in your messengers if you cant be bothered to support at least SMS and use Whatsapp (and have Telegram as backup if WA would block me again, appeal took ~5 hours to resolve).
I can imagine many reasons to devote resources to it:
* A platform is only as good as its apps. If they want to grow GOS in the general public, it requires a good SMS/MMS messaging app.
* LLM tools greatly reduce development costs, especially for well-known functions like text messaging.
* Without secure messaging (as far as SMS/MMS can be secure), the platform security is greatly reduced.
* GOS got a big donation, or has a volunteer that wants to do messaging ...
But idk what I'm talking about. What is their approach?
If they fix(ed) their messaging app and their keyboard, then they've really eliminated a lot of potential complaints if a less tech-savvy crowd ends up buying future Motorolas.
We've announced our plan to add RCS with Messaging Layer Security (MLS) for E2EE compatible with Google Messages and iOS.
> GOS got a big donation
We receive large donations on an ongoing basis.
> or has a volunteer that wants to do messaging
Everyone doing substantial work on the project is paid to do it full time. We hired all the people doing large amounts of high quality volunteer work. We've moved on to a process of filtering candidates based on their CV, an interview process and small test projects.
They also plan to eventually support RCS in the Messaging app.
That's great. How can a FOSS project afford that? Where does GOS money come from? Did Daniel win the lottery?
They have 14 devs 13 are payed in ETH and 1 in CAD.
Iirc they said something like 2 million in donations in 2025. Vitalik Buterin may have donated at least some time ago.
Proton donates double digits.
Cape has donated around 100k https://www.cape.co/blog/cape-supports-grapheneos and plans to donate 100k this year.
There's estimated 500k users so if 25% donated 10 dollars a year that's 1.25 million.
Modernizing these apps seems very high-impact. These are the very first things a new user sees and after the initial modernization, they should be relatively cheap to maintain.
Messaging can be replaced with one of the hundreds decent messaging apps.
Unlike the backup app which is utterly unusable, untrustworthy and frankly crap. And CANNOT be replaced by anything else.
As it stands it's impossible to have reliable backups in GOS.
If my phone were lost, stolen or destroyed, I would simply revoke its Wireguard key, buy a new Pixel, flash Graphene, and provision a new Wireguard key. Essentially no data of value would be lost, and restoring my apps and settings manually would take an hour tops. Admittedly, I don't use many apps, so YMMV.
I agree that a new backup system is also high impact, but there can be more than one high-impact thing, and the Message app is really low-hanging fruit.
IIRC when they started first announced their replacement for the AOSP camera they said they hired a developer specifically for it.
People prefer larger tap targets on touch screens.
And tons of whitespace doesn't make the tap targets bigger. It exacerbates the problem of bigger targets causing less to fit on the screen.
Only in a completely stupid, nonsensically A/B tested notion of "prefer". I'll refer you to this ~~excellent piece of satirical writing~~ actual post from Google design team: https://design.google/library/expressive-material-design-goo...
Are you this … poorly informed