So essentially, it's not really an Apple thing, it's more that the universal RCS profile just didn't have encryption, and Google RCS was a non-standard extension that nobody else was allowed to use.
The real news is the update to GSMA RCS, because without that, none of this matters. What I'm missing in the article is who's going to own the keys and why this is probably going to default to the telcos as if it's MMS. Are they going back to the days of charging per message?
With iMessage you'd be putting your trust in Apple, with Google RCS you'd be putting your trust in Google. For WhatsApp that'd be Meta and for Signal that's Signal. But with GSMA RCS?
The thing about RCS is that no messengers seem to care at all about implementing RCS themselves. Part of that is probably because depending on the carrier, RCS may require access to certain SIM card information, which only pre-installed apps can do, and part of it is that many developers are waiting for Google to add RCS to the same API that SMS/MMS already exposes because they don't want to implement RCS themselves.
Realistically, the target demographic for their documentation is 1) Apple (who they'd happily supply with details to get rid of the green bubble problem) and maybe 2) government officials looking into antitrust concerns. In theory someone working for LineageOS can implement an RCS client, though, but for those developers I don't think reverse engineering the remaining unknowns about the protocol (mostly "what server" and "what message contents") aren't that difficult.
I'm not cryptographer, but I haven't heard any major issues from actual cryptographers about MLS. It's encryption principles seem to be similar to those of Signal. Google is actually already using MLS in their proprietary E2EE implementation.
Ideally, MLS would be combined with MIMI so that messaging apps become interoperable, but that's probably a pipe dream.
> who they'd happily supply with details to get rid of the green bubble problem
I would be surprised if this eliminates green bubbles. iMessage supports many features unavailable over RCS on Android devices. These would still be disabled and Apple needs a way to indicate a degraded feature set to iMessage users.
the issue is that it simply may not be up to them, at least in Europe. if the EU decides that keeping the blue bubbles contravenes the DMA, then the blue bubbles will go
Blue bubbles don't mean privacy, and green bubbles don't mean insecure. I would presume encrypted RCS would satisfy privacy, and would remain green to indicate it doesn't support iMessage-specific features.
iMessage is encrypted. Blue means the “SMS” was sent over iMessage and it is secure. Green means it was sent as a normal SMS. This is super helpful for non-technical people that want privacy.
I was just engaging with a hypothetical - see my other replies to siblings in this thread if you need clarification. iDevices are my daily drivers, but I don't understand all the fanboys getting triggered here
If they were functionally equivalent, why signal a difference? What's the benefit, you think? I'm not saying that they definitely would signal a difference, but in this hypothetical, if the color difference remained, it would be obvious why.
there's two doors through which the message can leave your phone... the blue door and the green door. (Ignoring the SMS tiny door)
If the feature sets of the blue and green door happen to be the same for a time, that doesn't mean a message sent through the green door is "actually" leaving through the blue... The doors are actually different (even if the feature sets are the same (for a time))
We were (originally) talking about a mystical magical timeline where the two standards converge. You can make another hypothetical, where they converge, but only temporarily, but that's a new flavor on the hypothetical that was first posed way way back where the thread started. I'm sick of repeating myself, so I'll leave the musing to those who are more invested.
Not to Google. Green bubbles were a big social shaming issue affecting the sale of Android. This is all in the US only afaik. So in other countries with a similar iPhone market share there isn’t a green bubble social stigma.
That's false. The color green is irrelevant. If the Apple bubbles had been green, and the Android bubbles had been blue, still the Android bubbles would have been shamed. It was never about the color. It was because of the SMS/iMessage feature incompatibilities.
Let me spell it out: the arbitrary color lets you identify the ones who use Android. Some people think the reason for using Android is being poor. Others don’t want to be seen as poor, because social posturing is important to them.
> Others don’t want to be seen as poor, because social posturing is important to them.
Then they should buy an iPhone if social posturing is important to them.
In all seriousness now: the green buble shows you that you’re sending SMSes which, based on carrier and/or country it can cost you, especially if you’re roaming overseeas where every SMS is 10/20/50c each.
iPhone users perceive Android devices as poor. It’s naive and biased, but there’s at least some validity based on the fact that Android devices can cost anywhere from $100 for some basic model at Walmart to ~$2k for the bendy/foldies.
What most are saying is that there’s always been the perception that comes with green messages. When I was on Android (pretty much since the first Nexus all the way to the Galaxy Fold 4), I definitely noticed iPhone users avoiding SMSing with me or in groups, and instead using Facebook Messenger because of the issues that come with group texts involving non-iOS users.
Now that I’m on iOS, I’m aware of the differences, although I don’t particularly care since so many Android devices support RCS.
Just please stop sending the text that reads as follows, it totally destroys group chats and the amount of information conveyed in a react doesn't require quoting back the entire message, eg
Liked "I would be surprised if this eliminates green bubbles. iMessage supports many features unavailable over RCS on Android devices. These would still be disabled and Apple needs a way to indicate a degraded feature set to iMessage users."
I have never seen a reaction that helped. "OK" is short, it's in plain text, and it works easily. I don't need your thumbs up. Or your like. You want to emoji, go ahead, but I'm getting older and I can't zoom in on them without blowing up general text to the same size. With more complex emoji I have to screenshot the text and then pull up the image to zoom on it to even tell what it is.
I'd silence the conversation, except that iMessage won't let you have two identical groups with exactly the same members. So both humorous and serious stuff goes into the same group chat, and it's often very time-sensitive if serious. Then three or four people start joking around, reacting to each other, and suddenly while I'm at dinner (or, my favorite, one hour into a three-hour drive) my phone or watch is going off every twenty seconds for five minutes. I can't ignore them, because one of those dings might be from someone else about something that needs an answer right now. I can't risk forgetting to turn notifications back on.
When I still used an Android phone, the max-ten-people SMS rule meant that I was missing important business information - like, for example, I found out that our secretary had cancer when she asked me for restaurant recommendations near MD Anderson Cancer Clinic in Houston. Never occurred to anyone else that I had gotten none of that.
You admit that you’re getting older, and I think that’s part of the disconnect with emojis. OK does not convey the same thing. You’re talking about having to zoom in to see the emoji, and the younger crowd already has every one memorized. The reactions may not help you but I’d say for most of us, they do help.
Fine. Is "10-4" or "copy that" or "Roger" acceptable? Because the whole point of that text, in a work context (and this is always a work conversation; I like my partners but I'm not personal friends with them), is to convey "I have received your message". And a reaction generates an SMS that is, until you realize what it is, kind of incomprehensible. "Loved '[my comment]'" makes no sense when you get it as a long comment.
> The reactions may not help you
I have trouble seeing how they help anyone. You made an obvious joke. A guy who laughs at anything reacts "HA-HA!!" or whatever. What is the contribution? The youngest member of my partnership is 40, though we do have a 33-year-old joining in a few months.
This isn't "get off my lawn", much as I do love that. It's "explain to me how it's useful for actual minute-to-minute work". I'm a physician. An anesthesiologist. I never know when the next emergency will arise, but OTOH we don't go for a sterile cockpit approach because there are a lot of conversations that have to do with the running of the day at work that aren't entirely serious (and don't involve patient care, as such; that's why we don't use the sterile cockpit method - it's more about figuring out who can let whom go to lunch, becuase you can't just leave someone under anesthesia to go eat, or how we might be able to let Dr. X operate in about an hour - personnel management is the biggest part of my on-call duties).
Well you actually make a point for short reaction standardized support.
You won't be able to alter behavior of everyone around you. So at least the software should render these interactions in the least obnoxious way by being consistent on both side.
You will always be able to ask for textual clarification. But the big win is that you won't be bothered by sub-par quoting repost.
We are 3-6 people, and our pattern is specific reaction to questions like this. "do (specific task) so I can go forward" "can someone take over communication with X", depending on what we do we react differently I will do it/it is done/please clarify. This means that if you need two people in a meeting and get two "please clarify" and two "will be there" reactions, there will be less traffic in the chat. It is more concise.
You have a hint above you need to be specific what means what, when we onboard new people we go through these things. This is a problem with ontologies you have to be specific and not allow meanings to drift.
I am not a emoji expert but this has been a way to make our chats a lot more easy to get a grip on.
We do not use Apple so do not get "Loved X" types of messages.
> OK does not convey the same thing.
Fine. Is "10-4" or "copy that" or "Roger" acceptable? Because the whole point of that text, in a work context (and this is always a work conversation; I like my partners but I'm not personal friends with them), is to convey "I have received your message".
So I had missed the “in a work context”, where I think your point is slightly more valid.
>And a reaction generates an SMS that is, until you realize what it is, kind of incomprehensible. "Loved '[my comment]'" makes no sense when you get it as a long comment.
Only if you don’t both have iPhones, and the necessary information is all at the beginning. You see “Loved” and a few words from the start of the message and you remember what you said and you know which message.
> The reactions may not help you
I have trouble seeing how they help anyone. You made an obvious joke. A guy who laughs at anything reacts "HA-HA!!" or whatever. What is the contribution?
So this answer may surprise you, but emoji reacts actually do communicate something unique, and of value. They are more subtle. They also permit the conversation to terminate after the react. In my mind, and the mind of many others, an actual message necessitates a response, and I’d see it as rude to neither respond nor react to a message. Reactions are subtle and out of hand, and you don’t respond _to_ a reaction. Using a react instead of an actual text response has a way of signaling the other user that they don’t need to respond further, that you read their message, how you feel about it, and no further information is necessary. This is incredibly useful and I’d struggle to communicate with any kind of emotional nuance in this day and age without it. More fundamentally, reactions solve the problem of non-verbal communication and body language in text.
>This isn't "get off my lawn", much as I do love that.
It gives “get off my lawn” a bit when you say you don’t see how it would be useful to anyone. I’d never try to convince you that you need to use it, but I do think you should understand the utility for everyone else.
But, I definitely understand that it’s not useful for your professional use case as an anesthesiologist. Also, wow, what a cool job (seriously)!
While acknowledging that you might not have any agency about this in your specific situation, this sounds more like a social/boundaries problem than a technical one.
If I were in a group chat with people both joking around and sending messages requiring urgent responses, I'd let them know to either cut the banter and keep the channel clear, or contact me otherwise if they need my urgent reaction. Letting people hold my attention hostage like that would drive me crazy.
I realize that I live in an unusual life vis-a-vis most HN readers. I do not work in tech, and I never have. I'm a physician: specifically, an anesthesiologist. I have always enjoyed tech, and I'm certainly miles ahead of most of my colleagues on that. But. Remote work is not possible. Relocating involves getting a new license to practice medicine (3-8 months), getting accepted by the medical staff of any hospital or surgery center you want to work at (~2 months after license is secure and job contract is signed), and all the usual stuff.
So I cannot not answer any number that isn't outside the US system when I'm on call. I can't silence the phone when I'm on call. I can't ignore messages. But we're a partnership, so there's no HR to file a complaint with when someone banters on a business channel, and I can't order them to do something any more than they could order me.
I get not being able to ignore calls (although that sounds like hell too, given how common spam calls are to US numbers), but it would really not be possible for people to agree to call you if they urgently need something?
Not doubting your description of your situation, and it does sound extremely stressful.
No, not really. I’m on call for the whole hospital, after all. Any doctor or nurse can ask who’s on call for anesthesia and get my number. Some call, most text.
So your hospital uses the same group chats for banter and on-call pages? That really sounds quite dangerous (in addition to stressful for the person receiving pages). Again, not sure if you are in any position to suggest changes here, but would an actual on-call paging system not make sense here?
There are so many apps/services available for this exact purpose that can alert (with or without sound, per user choice) through iOS's and Android's "do not disturb" mode, can call or text several numbers in sequence (useful in places with weak signal but a landline) and much more.
It definitely sounds like a technical one if you can't make two groups, one for banter and one for serious talk so you can mute banter when it's not appropriate.
How are other people supposed to know that it's not okay for you right now because you are at dinner?
We all live in the same metro area. You might eat as early as five, you might finish as late as nine. But if you're going to use the business group, it should be about business. Banter is fine during working hours.
People get lazy and just use the "whole group" message rather than send it to those who are working today. And it's much like my problems with Android vs iOS: there are twelve people in this group, eleven of them have iPhones. They are not all going to install and use a separate messaging app for business than for personal communication, especially as iMessage is nominally E2EE. I could adapt or just be completely marginalized. So now twelve have iPhones.
Have you considered using something like Slack or Discord or (can’t believe I’m suggesting this) Teams, all of which sound like they’d be more suited to your use case?
This does not sound like an impossible stretch, works on more device types, and in the case of Slack or Teams can also be configured for HIPAA compliance (which while you don’t call it out, seems like it may be useful). Tens of millions of people use a chat system for work distinct from their personal friend groups, even if the venn diagram is a circle.
Oh, that for sure. That seems like the obvious solution I'd pick on Signal or WhatsApp, and if Apple Messages doesn't support it, it's yet another infuriating example of their "we know best" attitude.
I like Apple hardware, but try to avoid its first party apps as much as possible due to that.
What happens if you have a group with N+1 members and then remove the extra one? That would be a weird error message to write... "you can't remove X because everyone else is already in a group?"
The thumbed up reaction is useful because you can react to something specific in a fast-paced conversation. iMessage also allows replying to a specific message, which is also useful for the same reasons.
> With more complex emoji I have to screenshot the text and then pull up the image to zoom on it to even tell what it is.
...you can make the font bigger. Or get glasses.
> I'd silence the conversation, except that iMessage won't let you have two identical groups with exactly the same members
Create group 1 with coworkers A,B. Create group 2 with coworkers B,C. Add C to group 1, A to group 2. Two different chat groups.
"I won't bother to look up how to do things on my phone" != "my phone sucks."
> The thumbed up reaction is useful because you can react to something specific in a fast-paced conversation. iMessage also allows replying to a specific message, which is also useful for the same reasons.
A makes joke. B and C react "laugh". D replies with sub-joke. E, F, and G react "groan". Produce this little cascade every time a serious topic is brought up and someone makes an offhand joke as a lead-in to a serious topic.
> you can make the font bigger. Or get glasses
I have and use reading glasses. Making the font bigger is an option but I can read text just fine at that size. I can't make out the details of a complex emoji.
> Create group 1 with coworkers A,B. Create group 2 with coworkers B,C. Add C to group 1, A to group 2. Two different chat groups.
A completely non-obvious behavior (you can only create a group after you have sent the first text, see https://support.apple.com/guide/iphone/group-conversations-i... for info), and as it's late at night, I can't test it. Trying to search for how to do this turns up mostly threads about how the same group of contacts keeps showing up in different conversation threads.
> "I won't bother to look up how to do things on my phone" != "my phone sucks."
Feel free to tell me what search will show me how to make a "MyCompany - Business" and "MyCompany - Social" group without ever sending a message, and guaranteeing that Business messages always go to Business and Social always go to Social.
> A makes joke. B and C react "laugh". D replies with sub-joke. E, F, and G react "groan". Produce this little cascade every time a serious topic is brought up and someone makes an offhand joke as a lead-in to a serious topic.
iMessages/SMS is not a conversation or an email and the same rules don't apply. You don't have the recipient's attention for any longer than it takes to read the message you've sent. If you want to make a joke then make a point you need to do both in the same message.
> I'd silence the conversation, except that iMessage won't let you have two identical groups with exactly the same members. So both humorous and serious stuff goes into the same group chat, and it's often very time-sensitive if serious
Really? That's insane, so that means that 3rd party messaging apps literally have better UX than first party ones, as I have lots of groups with the same members for different things.
Absolutely. Apple Messages is way too minimal, for both iMessage and SMS.
As another example, it makes it almost impossible to manage multiple numbers for a given contact (e.g. to explicitly text somebody’s work phone), and the sender side is very confusing as well with dual-SIM. Apple’s implementation freely merges threads that I’m trying hard to keep separate and then still falls over with tons of delivery errors in complex situations (usually after swapping SIMs).
It all works reasonably well if you have a single long-lived mobile number and all your contacts have the same, and are using iMessage (or now RCS), since that’s presumably the reality for most Apple engineers.
Anything slightly more unusual and the thing falls apart completely and makes me wish for a Nokia 3310 (or convince my contact to switch to something more reasonable for messaging).
I don't believe this is true, but you do have to give one of the iMessage groups a name to make it independent from another group.
If you imagine that primary key for a group is its name, and the default name for a group is its participants, this does kind of make sense.
You'd expect an app, like Whatsapp or Discord or Signal, which focuses primarily on messaging, to be able to devote more attention to it than apple, which is really just a hardware company that reluctantly makes just enough software to charge 30% of all the good app's profits, and sell their hardware.
iMessage just not supporting android/windows/linux devices already makes it drastically worse than any other popular chat app.
You’ve pretty much indirectly nailed the issue: on iOS, iMessage is much more than just a “chat app”. It has an unrivaled feature set on iOS that isn’t replicable on other chat apps. The discourse that reduces it to a “chat app” is critically missing this point.
This wouldn’t mean much if iOS was a small percentage of phones. In regions where it is a majority of phones people use those additional features. In places like the US where most people are using iOS, most people don’t even realize those features don’t exist or are semi-broken on other chat apps because they don’t use them. For average people that have been using iMessage for a long time with other iMessage users, using those other chat apps feels like a downgrade.
The only two features I can think of that iMessage has which discord/whatsapp/etc don't are:
1. Automatically can flip to "do not disturb" mode when my phone is in sleep mode, and display that notice to my companion. Other chat apps require manually configuring that I think. I also suspect apple doesn't provide an API to make this easily possible for other apps.
2. iMessage makes it easy to identify the poors, the android users, and ignore them. If I exchange numbers on a dating app and get a green bubble, I can know to immediately ghost them.
Are those the features you were thinking about, or something else?
Most (all?) of the Apple iOS apps and data can be collaboratively shared, edited, etc over iMessage and it is extremely seamless with fine-grained access controls. I get people sending me calendars, notes, slide decks, documents, etc to either read or work on together via iMessage/iCloud. You can selectively share most things in your iOS environment with any other person in the iOS ecosystem. Google Apps is a pale imitation of this. And the security is tight.
I’ve never seen anything like this on any other chat app I’ve used. Most objects in iOS can be directly shared or collaborated on over iMessage, and that is a very rich set of objects. People that only use iMessage don’t even realize other chat apps can’t do some of these things.
So… attachments? WhatsApp and Signal can send those too, directly from the share sheet.
I find the iMessage implementation very clunky compared to WhatsApp. It’s trying so hard to be “minimal” about delivery status and recipient capabilities that I never quite know whether something worked or not, especially with contacts that have older devices on their iMessage account.
They use iMessage with their family and friends. They use it at work too. Some of their friends, and maybe some of their family, work at the same place. I can try to convince 11 other people who are my business partners to switch to, say, Signal. A special app used only for our group communications. Or I can buy an iPhone. I chose the latter.
It's not my choice. I'm making the best of it that I can. I wish it were not so, but it is.
All the non-tech people in every non-US country have whatsapp/telegram/wechat/line/kakao installed (depending on the country), and it seems to work fine.
It's just the US that has picked a universal messenger that doesn't work on android, every other country, the vast majority of the planet, defaults to a cross-platform phone messenger app.
Not every non-US country. Most people in Norway have iPhones, so iMessage is heavily used. They also use Facebook messenger a lot for some bizarre reason.
> iMessage makes it easy to identify the poors, the android users, and ignore them.
I hope this is sarcasm, and you're not actually that narrow minded.
It is an interesting complete marketing victory in the US by Apple though, that there is a widespread perception that you would only have an Android if you couldn't afford an iPhone. I've had an iPhone for work, it's fine. I much prefer Android and I'll stick to it, and the reasons for that have nothing to do with money. I'm glad I don't love in the US where that would apparently make me a social pariah.
iMessage's killer feature is that you can send a group message to more than a total of ten people. SMS does not officially support this.
I do not recall this being a problem in the pre-iMessage days, even with flip phones. I was on prepaid T-Mobile and had to pay for every message I received, which is the one place where I thought the US billing system had gone nuts - you could always decline to receive a phone call, knowing the number, but you can't refuse a text. I was surprised that nobody ever abused that, but they never did so on a large scale. At ten cents per text, sent or received, you communicated when you needed to, or when you had something to contribute, but one minute of voice was the same cost. One sent and one received text cost as much as two minutes of talk, which can convey a lot more information.
I can't remember the last time I sent an SMS. Comparing iMessage to SMS is not useful. Compare it to one of the (several) cross platform messaging services.
In Europe, Android is on equal par with Apple. WhatsApp is the default messaging service - it is universally installed among my friends, relatives, colleagues, contractors etc.. No-one cares what model of phone the other person has. Everyone communicates.
The protocol is open but key exchange is not: even on Android, third-party messengers can’t interoperate with Google Messages. See page 11 of that PDF.
That's true, but Google has also indicated that they're switching to the GSMA spec which is intended for interoperability.
I also doubt that Google would withhold such details from parties like Apple even if they maintained their proprietary format. Small developers would need to reverse engineer the details, unfortunately.
My question is basically whether they open it up or limit it to companies they have deals with. Reverse engineering is a risky game for a service with device checks since that’s potentially a CFAA violation and it could lead to your users getting their hardware banned.
Only Messages was allowed to support it. At the time it was written, for example, it was years after the Signal developers had asked for basic RCS support (2015) and given up on Google relenting and allowing it in 2018.
Signal has been rather dismissive of RCS in general. Of course RCS was as insecure and unencrypted as regular SMS/MMS until now, but I haven't found a sign that Signal ever even looked into supporting RCS at all.
At this point I think they just wanted to get rid of their SMS backup feature and used RCS as an excuse.
Signal was dismissive of unencrypted messaging. Google used their protocol for their proprietary E2EE system so it’s unlikely that this objection would apply if that system was open.
Put another way, if this was a Signal thing what other Android app is doing this?
None, but that issue has no mention of what you said in the other message
("Only Messages was allowed to support it. At the time it was written, for example, it was years after the Signal developers had asked for basic RCS support (2015) and given up on Google relenting and allowing it in 2018")
Because the rest of the world seems to neither care nor even notice the bubble (of either colour) i.e iMessage is irrelevant almost entirely outside North America (and that too I guess mostly USA; only among just the iPhone users of course)
I believe Canada has an even higher iOS market share than the US. Mexico mostly uses WhatsApp but I don’t text people there much. I have and use both WhatsApp and Signal routinely in addition to iMessage; no one I know uses WhatsApp within North America and only a handful use Signal.
When I worked in Europe just about everyone I texted with had an iPhone. We always use WhatsApp or Signal there by default. Nonetheless, iMessage was usually the fallback when those chat apps glitched because it is so reliable, especially compared to Signal. YMMV, etc.
What iMessage has going for it is that it is genuinely a very good implementation of a social chat app with unique features enabled by the iCloud ecosystem. I’m pretty agnostic about it, I’ve used a lot of chat apps by virtue of being more global than most, but iMessage is objectively pretty great when you stay within the Apple ecosystem. I’ve reduced things down to WhatsApp, Signal, and iMessage, which is kind of the minimum set that gets you global coverage, but if everyone is on iOS then iMessage is noticeably superior to Signal or WhatsApp. iMessage is more than just a chat app but it limits itself to that when interacting with other ecosystems.
> I don't think reverse engineering the remaining unknowns about the protocol (mostly "what server" and "what message contents") aren't that difficult.
That's hard to parse. Removing the double negation, we end up with
"I think reverse engineering the remaining unknowns about the protocol (mostly "what server" and "what message contents") are that difficult."
> RCS may require access to certain SIM card information, which only pre-installed apps can do
> because they don't want to implement RCS themselves.
Sounds like they can't implement RCS themselves even if they wanted to, not simply that Google doesn't provide an open source implementation? (Referring to app developers here, not custom ROM devs.)
They can't implement RCS for every carrier, but they can implement it for some. Others require nothing more than a network call to a predefined HTTP address over a data connection.
Although Google may dislike it, I don't believe Google's RCS implementation (the one most of the world uses) requires elevated permissions. Their activation sequence is proprietary and closed source, though so I'm not 100% sure.
Just having a base implementation for custom ROMs would be a start. Given that Google will block custom ROMs from RCS in their app (I believe because the spec says to), there is a need for an independent implementation if this makes RCS popular enough under American users.
Someone will have to inventory the activation mechanisms for each carrier to see if there really is a disadvantage. I'd start with mine, but all of the carriers in my country have shut down their RCS servers a decade ago.
I am not familiar with RCS, but considering the plethora of messaging apps available that just work, why did they choose the most complicated way for users to use it? And what do you mean it is not available on every carrier and needs SIM access?
I haven't seen any indication of that at all. There's sort of an API, but it's basically restricted to Samsung's messenger only.
The EU won't get involved unless a significant chunk of the user base uses Google Messenger. I don't think EU users will reach that threshold because most of the EU uses basically any chat app except for SMS/MMS. Things like receiving verification SMS messages still work using the existing API and I have a feeling that that represents the majority of SMS use in the EU.
I understand your point that the "news" part is that RCS standard now includes E2EE, rather than about Apple's support for said standard.
But I don't think it's fair to suggest or imply that this development is unrelated to Apple either.
RCS has been a thing for nearly a decade, and Google's RCS backend has been doing non-standard E2EE for half that time.
Within 8 months of Apple publicly announcing they would adopt RCS and work with GSMA to support standardised E2EE, there is suddenly a standard for it...
It is worth noting that the E2EE system they are using (MLS/RFC9420) was only finalised as a standard as of mid 2023 and has had errata from the last few months. They basically added E2EE to RCS more or less as soon as the protocol they are using standardized with IETF.
Google has been working on replacing the ad-hoc Signal protocol with MLS since before Apple announced they'd support RCS, it would have happened anyway.
It's more likely Apple was made aware of the spec/Jibe/Messages roadmap when they finally got on board, decided not to target the latest UP version for some reason, and realized implementing the current E2EE scheme would be wasted effort given it would need to be revamped within a year. The iOS RCS client is still pretty far from being provisioned worldwide.
Look at Google’s documentation: they explicitly state that only their Messages app is allowed to talk to their key exchange server. The entire marketing campaign they ran about RCS was predicated on nobody reading their docs or noticing all of the Android developers begging for permission to use RCS for years.
> E2EE is implemented in the Messages client, so both clients in a conversation must use Messages, otherwise the conversation becomes unencrypted RCS. In rare situations where the conversation starts as E2EE, then one of the clients migrates to a different RCS client or an older Messages client that does not support E2EE, Messages might be unable to detect the change immediately. If the Messages user sends a new message, it’s still E2EE, however the recipient client may render the encrypted base64 payload directly as message content.
Yes, Google only made it available for Google Messages. They don't have an SDK or API you can use to make your own clients or servers. Google also didn't put it up for standards with the GSMA or any other standards body, at least not publicly. There are no records of it.
There are some older submissions here you can probably find using one of the HN search sites about this, but IIRC those didn't really have any internal Google policy about this, they kept it all pretty private. The only 'leak' I remember about this was the thing where manufacturers that preload Google Android have to ship Google Messages to get RCS support from Google, otherwise they can't have it. Also means you can't have RCS without Play Services.
I really, really, really hope RCS doesn't make it as a standard.
Now that it's end-to-end encrypted, it's slightly better than SMS, but it's still laughably incapable compared to decades-old protocols that support multiple devices, phone-number-independent identifiers, self-hosting, have open implementations and non-insane specifications etc.
As it is, RCS is just Google Talk (Google runs most of the infrastructure), but tied to a single device (no messaging from your laptop or tablet if your phone battery dies!) and impossible to use without a phone number.
It makes me really sad to see that even technical audiences don't see the long-term plan here: Cementing the use of phone numbers instead of email addresses as the primary identifiers in people's digital lives, and making the closed, carrier and Google operated RCS ecosystem the ultimate replacement for email and other open web standards for B2C and P2P messaging. (Yeah, most people already use Gmail, but the point is that self-hosting email is at least still possible, and there's still relatively free competition of sending service providers; with RCS, there's no chance to play without paying the cartel.)
> Cementing the use of phone numbers instead of email addresses as the primary identifiers in people's digital lives
From my experience RCS is just a backup/temporary holdover system to keep SMS usable as is, since people are increasingly using regular chat apps like WhatsApp. Plus as long as spam/identity is a major issue then phone numbers will be a part of verification systems. They will use anything they can get to make it harder to abuse. Whether the root ID is phones or not doesn't really make a difference if a phone number is required at some point to use a service.
There's a large split here between the US (where people largely use SMS and now RCS) and the rest of the world, which largely uses WhatsApp, WeChat, or very few others.
I'm of course also just as critical of having Meta run the world's communication industry instead of Google, but that's the duopoly (or rather two monopolies split geographically) we're headed towards. Cheering on RCS as a way out of it, instead of directly towards it, is deeply misguided.
That said, at least WhatsApp provides some basic features that XMPP has supported more than 20 years ago (multiple devices being logged in simultaneously, synced message archives etc.) – I'm not holding my breath ever seeing these on RCS. As a pseudo-federated standard, protocol and client development will always be much more complex, and looking at the baseline complexity of the RCS specification powering the few existing features, I'm just not seeing it happen.
Needing my phone to be powered up and connected to the Internet to message people from my computer in 2025 is absurd.
RCS is a GSMA standard, like VoLTE and SMS messages. Of course it's going to use telecoms features as unique identifiers, that's what it was designed to do.
While I agree that tying everying to a phone number is far from optimal, it's the status quo in messenger land. Only tech nerds use services like XMPP and Matrix, the rest all use either chat apps that tie you to a phone number or just text directly.
RCS is there for the people who still use SMS/MMS. In my country, that's basically nobody. In Canada and the US, that's the majority of non-iPhone people, and the iPhone people have been complaining about the shitty integration between iMessage and MMS since the day iMessage took off (because MMS is terrible for modern messengers).
RCS runs on your carrier's infrastructure. Google hosts RCS services for people whose carrier doesn't support RCS, but Apple won't be using those. RCS on iOS requires carrier support, which many carriers still have yet to turn back on.
I think you're confusing the status quo with the goal behind RCS. The unfortunate truth is, the people who are using RCS would've used SMS/MMS before. RCS just appeared in their messengers some day and made texting a lot better.
I'd still advocate for signal over RCS any time of the week (though I don't need to, because nobody uses SMS/RCS here anyway thanks to WhatsApp), but RCS is an abject improvement over the terrible messenger protocols it replaced.
Even worse: it silently fails if the device does not run an unmodified anf certified Google Android OS. This means, it will not work on alternative OS and rooted devices
It's far more than "slightly better." It supports full resolution content, longer messages, and reactions/interactions. For most people it's indistinguishable from iMessage/etc.
Do you really think that phone numbers aren't already a ubiquitous identifier? That is done. Nothing you're saying is changing because of RCS.
Yes, it's already largely done, but that doesn't mean it was a good idea, so why cheer moving into the same bad direction just because there's now finally a baseline of security?
It's also anything but indistinguishable from iMessage. I can use iMessage on any number of devices without my phone having to be turned on, having the SIM with my number on it inserted, and being connected to the Internet (not always a given when traveling etc.)
The same is true for WhatsApp. Even XMPP could do it 20 years ago! This is not a new niche feature – it's absolutely essential for a modern instant messaging protocol!
No, I'd rather we have an actually open, federated standard such as XMPP or Matrix, with a trusted directory service binding phone numbers (that one could be operated by phone networks) and email addresses or DNS domains to IM handles.
And if we can't figure that out, I consider Google and Meta equally bad gatekeepers of global B2C and P2P communication, and don't see why I should use the technically strictly inferior solution of the two.
Unfortunately, RCS on Android requires google apps, so this isn't really a solution to anyone who doesn't want to be tracked by Google everywhere they go.
I'm still a little confused as to what problem RCS is supposed to solve. It is just as centralized as any other chat app, and is a bit more invasive (often requiring device attestation). Is it really worth all this hassle just to not have to install, let's say, Signal?
Defaults matter. While I've gotten some of my friends and family members to install and use Signal, I still have more chats via SMS/MMS (and more recently RCS, since Apple finally started supporting it) than I do on all other messaging apps combined.
This is likely to differ greatly by demographic. I don’t know literally anyone who uses SMS/MMS. The only SMS message I’ve received in years are automated services/spam.
That's not necessarily true. For full compatibility you'd need a pre-installed app on Android, but vendors like Samsung and Sony and OnePlus can build their own RCS messengers for those devices should they choose to. Same with custom ROM developers for an open source implementation.
For non-ROM developers, it depends on what RCS activation technique your carrier uses.
RCS isn't a Google spec, or an Apple spec, or even an IETF/IEEE/ISO spec. It's part of the core mobile networking specifications. It was created by the people who designed the MMS spec after 4G switched mobile networks to everything-over-IP. Unfortunately, the 4G spec didn't require RCS, it was just an optional side feature, so carriers never bothered with it.
RCS solves the problem that most of the US uses iMessage or SMS/MMS, but the SMS/MMS part of that equation is absolutely dreadful. File size limits are stuck in the mid 2000s, messages are split over multiple SMS packets if you send more than one sentence, the entire thing is unencrypted. Sometimes people like to send photos to each other and the 150KiB or so file size limit on MMS isn't enough for that anymore.
As for why not have people install Signal: why would they, because everyone is already using something else? I live in a country where everyone uses chat apps and all but one of my contacts are on WhatsApp. In other places, that'll be Telegram, and in some North American countries, that'll be iMessage/MMS, the texting app that comes with the phone for sending texts.
I don't believe this FUD. I think overal the market has moved from from charging for messages. I fully believe carriers would love to rip off everyone as much as they can, but I think carriers know customers would just use facebook messenger if they tried charging per-message.
Carriers charging too much is exactly why WhatsApp became so popular in so many countries. It was optimised for very little data usage, so was dramatically cheaper than SMS.
Don't forget you could also send photos with it, which is more than what can be said about MMS.
Funny enough, I think I was charged once for a MMS in the past 5 years. No idea how I managed to do it, but it seems to still exist and still be charged per message even on my unlimited everything else plan.
RCS seems to be mainly designed as a successor for SMS.
For interpersonal communication, SMS is dead in the majority of the world, so a successor is entirely irrelevant.
For for the 1 or 2 countries where people still send SMS, RCS seems like a major improvement with a bunch of feature that have been available on other platforms for many years now.
No, it's worse than a standard centralized chat app: It's ostensibly federated, with network operators running the servers.
But practically, only Google actually knows how to do that (the specifications are absurdly complicated!), and so they do it for all operators as a service.
It's a fig leaf of an open protocol and service even for telco industry standards.
It also requires a Google account as far as I know. I have Google apps but no account signed in. And when I tap on the connect RCS option it asks me to sign in.
Anyway iMessage (and iOS for that matter) is irrelevant where I live so I don't expect this to change anything. I'm not going to be on RCS. The main apps here are WhatsApp and Telegram (the latter more for groups)
I have a very minimal Android phone with no Google account ever added/used on the device, and it says my chats with other Android users are using RCS ...
The phone number is associated in the other direction though (way back when Google didn't be evil and GMail required invites, I dared to trust them with it, I forget for what).
It shouldn't. The only reason Google Messages sometimes asks for an account is to support remote access via messages.google.com without scanning a QR code, as far as I know.
While it's largely openness/federation theater (Google runs most servers in the background, either on behalf of or instead of the mobile networks), they at least got that part right (as in conforming to the specification, not as in doing the long-term right thing for users) and exclusively use the phone number as an identifier.
Ah ok strange. It is a Samsung phone though. Samsung has been forcing a Google login in more and more places unfortunately. I think they made some deal with them about the AI features. Just like they now promote OneDrive instead of their own cloud. Maybe that's why or I didn't understand the popup.
I don't really want it if I can't access my messages online anyway. The whole reason I love telegram and WhatsApp is that I don't need my phone when I'm on the computer (which is 90% of the time). But a Google account is out of the question.
Right now I even bridge WhatsApp and Telegram through matrix because I don't trust those either, though I don't think I trust any company less than Google. But I don't know if you can do that for RCS.
But tbh I'm not looking for any other chat app unless it's federated and I can run my own server. RCS is technically federated but limited to a group of big companies so that's pretty useless to me.
I think I'll just block it just like I do SMS. I turn off all the notifications for the relevant apps.
No chance for bridging RCS to Matrix, as far as I know. That’s what I find so concerning about it: It’s theoretically more open, but practically much more locked down than both SMS and proprietary alternatives.
Yeah me too. It doesn't help at all to take control away from big tech (really, meta or google is the same difference). And it loops in the phone carriers. You know, those guys that charged us 1 euro for 180 bytes just because they could get away with it. I never ever want those guys in the middle again, just as a raw bit pipe only.
The only thing that's open is the standard, but in practice you need to be on google's radar to be connected. So it's just as closed to us as everything else.
this is so true for networks that don't implement RCS servers,
not even Android - iOS interop present!
one thing i would like to see happen is deprecating SMS message with Labels rather than numbers, phishing has got far far too common in my jurisdiction RCS + some sort of DNS validation like atproto of sender would go a long long way
> RCS + some sort of DNS validation like atproto of sender would go a long long way
Now this would be a messaging protocol I could get behind. Phone networks could even provide a phone number registry for people that insist on using that for whatever reason.
But there's absolutely no chance it'll happen – neither the telecommunications industry nor Google have any interest in making federation for others than "trusted partners" possible.
SMS is already a goldmine for carriers (thanks to the widespread use of SMS for OTPs and authentication), so why not make the next logical step and replace email for as many remaining B2C use cases as possible and collect some rent there as well?
Your point about Google's central role is spot-on, and without an open, Google-independent implementation, RCS does remain problematic for anyone avoiding that ecosystem.
Yes. Not everyone is going to install Signal (which isn’t end to end encrypted btw), everyone has a cell phone that can support either iMessage/RCS/MMS/SMS and when you send a message to someone else’s number, you have graceful (sic) degradation.
Why was RCS even designed with a none encrypted mode? I get that the original spec isn't exactly new, but it's also not so old that encryption, security or privacy wasn't an issue.
Phone calls aren't encrypted either, if you think about it [1]. There's a large expectation of the telecommunications industry to be able to perform legal interception, and providing end-to-end encryption out of the box might be seen as a direct violation of that requirement.
[1] Except, somewhat incongruently, between Google Fi subscribers on some Android phones: https://support.google.com/fi/answer/11295314?hl=en – no idea how that came to be and how it even works! I suspect it just upgrades to a FaceTime-like VoIP call.
It's the evolution of SMS/MMS; development started 18 years ago, in 2007. The modern spec is based on that with a whole bunch of additional revisions for things like video calling and transferring money. It was designed long before major messenger apps had e2ee in the first place.
Had it been designed with the security practices at the time, the protocol would've been ossified to the point of being practically insecure by today's standards. In a sense, the fact nobody cared about it until the spec was old enough to drive is actually good for users.
The GSMA which designs RCS also serves the needs of government agencies that are tracking (international) criminals, so I bet there must have been some pretty strong opposition against E2EE in the official spec. Frankly, I'm surprised they're even putting it in the spec.
I'm not sure about the case of RCS, but I've seen some instances of a none cipher being better for compression and deduplication, because the encryption messes with the data.
You'd normally compress the data before encrypting it as that makes the resulting cyphertext more resilient against cryptanalysis as well as reduces the amount of data which needs to be encrypted so this sounds like a bogus reason.
That doesn't allow you to deduplicate across users, though – which of course is the entire point, or the network would be able to see who's forwarding which documents.
It depends on what you're doing I guess... for storage it doesn't make sense, but for pushing a lot of data over a private pipe, why spend the resources adding a cipher?
It’s funny that everyone bashed Apple for their lack of RCS support and now that they have it, all posts seem to indicate RCS is a shit standard at best. I have no idea if it is but that’s the impression I got.
I guess it was just a talking point to shit on Apple’s approach?
I don’t care anyway. Here everyone uses WhatsApp so RCS is not important but just an outsider observation.
I think the RCS users are quite happy that iOS has RCS now. Though, they may be disappointed that Apple didn't set up an RCS server like Google did, because now people find out that their carrier doesn't do RCS so they're still missing out in the advantages.
But, when RCS works, it works well. The stupid compatibility hacks Google and Samsung and everyone else implemented to make SMS/MMS pretend to be good at group messaging (like the ways they indicate emoji reactions) no longer need to be encoded in human-readable form.
The encrypted component of RCS was a Google special and I think everyone knew that. People wanted Apple to immediately take up Google's encryption spec, but Apple waited for the GSMA spec to be updated with E2EE which is a much cleaner solution.
The opponents of RCS have a point; using RCS is a bit like using your ISP's email servers in that the quality of your ISP determines how good of a time you'll behaving with it.
There are also many advantages to full RCS support that nobody seems to have implemented yet. Things like video calls, or sending money over text. No longer needing third party services like FaceTime or WhatsApp to do video calls is a step in the right direction in my book.
> I guess it was just a talking point to shit on Apple’s approach?
It started with Apple promoting the "green bubble = inferior" thing. Google responded by insisting the iMessage experience with Android was only bad because Apple refused to support RCS. Now here we are.
The RCS protocol is much better than SMS/MMS. But there are also plenty of better protocols out there. Both can be true.
It is good that commercial messengers forced GSM association to finally create E2EE standards. The reason why telcos want you to use RCS becomes obvious if you calculate how much 1Gb of data costs if sent as SMS (I guess that one could buy a car with this money).
I'd say it's the norm rather than the exception outside of the US.
US operators do things quite a bit differently from the rest of the world; for example, prepaid cards without a monthly fee are not really a thing, i.e. essentially every plan has a monthly fee, but that then almost always includes texting.
Outside the US, it's usually possible to receive calls and SMS on a prepaid SIM without paying anything other than maybe the occasional top-up to not lose the number; in exchange, outbound texts and calls are usually paid.
I believe the distinction that separated the US from the rest of the world is that US carriers charged the recipient of a message, while the rest of the world charged the sender. I don't know if that's true for evrryer carrier or if it's still true today, but it made a major difference.
It's also the reason apps threaten you with fees ("this service may cost you money") when all they do is send a verification SMS. Receiving messages is free in most places but because of a handful of shitty carriers apps now have this warning embedded in them.
It’s actually a “shared cost” model, not really “called party pays”, as far as I know.
And as far as I understand, this is all downstream of US mobile numbers not having a dedicated prefix identifying them.
They have region-specific area codes just like landlines to which calls are physically routed, and from there it’s routed onwards to wherever the mobile phone might be. That could well be a long-distance leg of which the caller is unaware, so it would be surprising to bill them for it. That leaves only the called party.
This model was then probably just carried over to SMS.
US carriers haven’t charged for long distance calls for decades at least for domestic calls.
Besides with number portability, you can keep your same mobile number when you change carriers no matter what the original region was. I’ve had my same number for over 20 years and have changed carriers 5 times.
They're largely not charging end users for it anymore because the cost is just too low these days, true, but as I understand that's still how the pricing model evolved.
> you can keep your same mobile number when you change carriers no matter what the original region was
Yes, but only because all carriers have physical or at least logical/rented infrastructure in effectively all "rate centers" [1]. The call still goes to whatever rate center your number corresponds to (barring other agreements, I assume, e.g. the originating and terminating carrier having VoIP interconnectivity).
That's very different in countries that have dedicated prefixes for mobile numbers: The originating carrier can immediately detect the target network (instead of target region) from the prefix and route the call to the nearest interconnection point between the two.
This means that the terminating carrier usually carries the traffic for the longest geographic stretch, something for which they usually/historically got to bill the originating carrier via interconnection fees. Today, these fees are either gone or nominal/heavily regulated, but the more efficient routing is still a factor for reliability.
Explicit charges are very rare these days, but there are at least still metered plans that count both incoming and outgoing texts against a monthly maximum.
Mine either provides 120 SMS/minutes or unlimited text and call. I used to use the 120 minutes version and almost exclusively used it for phone calls. These days I'm on unlimited because of a combo discount on my phone.
Most of the world isn't using SMS/MMS so lots of places have carriers that still charge for the feature.
When I enabled RCS on my Android, I started getting ads with rich media. So I disabled it. And moreover WhatsApp is the dominant messaging app in my country. So this doesn't matter.
Apple runs servers for managing iMessage key exchange, just like Google’s RCS encryption. Both of them use device attestation to restrict access to those servers to their own apps.
Think about it this way: you create an RCS message and hit send. Apple has to encrypt it now but all they have is a phone number. The phone number might belong to a local carrier or one on the other side of the planet. They need the public key associated with that number, right? Who has that? How do they get it? Who owns and manages that infrastructure?
That’s the same problem they have with iMessage: you can watch this the first time you use a new number and it displays green at first but switches to blue once it retrieves the other party’s key. That happens by connecting to Apple’s servers, which seems likely to be the same thing they’d do for RCS.
Another function which is the same: you connect to the server to register your device to your account. It uses hardware attestation to verify that the hardware is what it claims, trying to make spammers have to buy physical devices and to prevent spoofing.
Their infrastructure is iMessage protocol specific, though, and that's incompatible with whatever Google does for RCS.
So either somebody has to build some new service bridging the gap, or RCS encryption is "serverless" in the way that e.g. OTR was, but unlike Signal (which needs explicit server support for managing pre-keys to bootstrap new connections while the recipient is offline, for example).
Some of their infrastructure is iMessage specific but things like account management, abuse mitigation, and device verification should have plenty of opportunities for reuse.
Does anybody know how the trust model for this looks like? Is it trust on first use together with a notification if a contact's key changes, a centralized key server (if so, who runs it, and is there key transparency), or just opportunistic encryption not protected against active attackers in the middle?
It's using MLS for encryption and key exchange, which is based in part in Signal's encryption.
I believe they'll probably be using TOFU like all the other popular encrypted messenger apps. Google's messenger (the encryption of which already uses MLS) has a verification feature where you can match key fingerprints by comparing numbers, but who knows how Apple will implement this.
There have been dozens, called anything from Message+ to Joyn. Most seem to be shutting down, though, because nobody used RCS since its inception from somewhere around 2009 and renewed interest in launching RCS services around 2012.
I think Google‘s was something different. This is an actual standard that Apple is committing to implement. I was under the impression Google’s encryption was just their own layer thing they added on top it was not actually standardized.
When people asked last year about why Apple wasn’t implementing encrypted RCS I think they even said that they wanted to wait for a standard.
So an important context here is the server side implementation of RCS is Google's at every major carrier. Google bought the carrier-side provider of RCS services, Jibe, and so the entire RCS stack is still basically just Google Chat with an "it's a standard" label on it.
Verizon, AT&T, and T-Mobile all use Google's RCS implementation, the only way to not send Google your messages in the US is to own an iPhone and disable RCS.
> Verizon, AT&T, and T-Mobile all use Google's RCS implementation, the only way to not send Google your messages in the US is to own an iPhone and disable RCS.
>While Apple’s proprietary iMessage system already supported E2EE, this wasn’t extended to RCS messaging because the previous RCS standard didn’t provide cross-platform support. Google Messages also enabled E2EE by default for RCS texts, but only conversations between Google Messages users were E2EE, and not those exchanged with iMessage users or users of other RCS clients on Android.
this dances around, but does not seem to answer, the big question of whether android will get iMessage or not?
Potentially, but it’s fine as long as it’s done on the device and only notifies the user. Like ‘This might be spam, are you sure you want to view it’ or ‘This message might contain nudity’ if people care about enabling that kind of filter.
As long as it never will call out to any external server it doesn’t break the security.
Sounds like the standard wants phone RCS apps to do CSAM scanning as well as general analysis to see if the encrypted messages are about criminal activity. Not great.
Is it possible that we'll see non-smartphone devices (eg dumbphones) being able to interop with Apple and Google through the same end-to-end encrypted protocol?
I believe even then only US carriers (the rest of the world has moved on from P2P SMS, and only businesses are really still sending them for SMS-OTP and marketing), and of course Google, as the only party actually invested in it (via their acquisition of Jibe [1]).
Yes the Google Business stuff exists for B2C marketing type use cases, but it is a very limited feature set compared to real RCS and cannot be used for regular communications using phone numbers.
I believe GP's objection is to not being able to access RCS from a non-Google-provided app on Android, not access to the RCS network on the backend side.
iOS did boycott RCS for a long time in order to convince US teens to buy iPhones rather than Android phones (due to incompatibilities between iMessage and SMS, which are popular in the US). It worked. I think there was even some leaked internal email which admitted to doing this. The US antitrust agencies ignored it; there were no legal consequences for Apple. I believe Apple finally decided to add RCS support after EU legislators threatened to force their hand.
About a billion people use it every day, but they're concentrated in specific countries. I believe India is a major RCS user for instance.
Like Signal, it works fine, but you need your contacts to also use it. That's easy on Android (Google hosts an RCS server for people whose carriers don't) but carrier dependent on iOS.
RCS video calls and payments seem to be left unimplemented by Google.
Like so many other google products they get it going, maybe polish it a bit here and there, and then everyone wants to work on more prestigious stuff. That's why Google has had something like half a dozen iterations of an instant messaging service.
GV wasn't even an internal product - they bought up Grand Central and for a while the business offering was still branded as GC. But at one point, it was integrated into Hangouts. It's so strange...
They don't support any HD voice codecs, so call quality is shit, the integration with iOS is non-existent, the app doesn't sync in the background so every time you open it you have to wait 5-10s before you can use it...you can't even set a ringtone so you can tell a GV call from a cellular call.
There are years between updates and then suddenly for like 6 months it'll get a slew of updates, most of which aren't user-facing. Then back to update silence. It's really odd.
I think it only survives because it's so thoroughly overlooked. Probably nobody working on a new messaging/chat/VoIP/video conference/etc. platform within Google wants to nominate Google Voice as the thing they're replacing or reinventing.
I hope it stays that way. I'm almost certain that the minute management remembers it's there, it will get shut down, at least for non-paid (i.e. GSuite) accounts.
I don't think carriers had much of a reason to invest in RCS servers up till recently, because only Android really supported it and that came with a free, third party server. Maybe now carriers will start caring.
By online statistics, Brazil seems to be a WhatsApp country, though, so I don't think many people will be using carrier services for chat. In turn, I don't think carriers will be quick to invest in servers and software to provide RCS to customers very soon.
I've disabled RCS. RCS groups are used for spam. Unknown numbers in random countries add me and many other numbers to said groups, send spam and then quit the groups.
> The GSM Association announced that the latest RCS standard includes E2EE
> While Apple’s proprietary iMessage system already supported E2EE, this wasn’t extended to RCS messaging because the previous RCS standard didn’t provide cross-platform support
So essentially, it's not really an Apple thing, it's more that the universal RCS profile just didn't have encryption, and Google RCS was a non-standard extension that nobody else was allowed to use.
The real news is the update to GSMA RCS, because without that, none of this matters. What I'm missing in the article is who's going to own the keys and why this is probably going to default to the telcos as if it's MMS. Are they going back to the days of charging per message?
With iMessage you'd be putting your trust in Apple, with Google RCS you'd be putting your trust in Google. For WhatsApp that'd be Meta and for Signal that's Signal. But with GSMA RCS?
The encryption is based on MLS: https://www.rfc-editor.org/rfc/rfc9420.html
I don't think Google wanted to gatekeep their E2EE implementation. They have some generic documentation about how it works: https://www.gstatic.com/messages/papers/messages_e2ee.pdf
The thing about RCS is that no messengers seem to care at all about implementing RCS themselves. Part of that is probably because depending on the carrier, RCS may require access to certain SIM card information, which only pre-installed apps can do, and part of it is that many developers are waiting for Google to add RCS to the same API that SMS/MMS already exposes because they don't want to implement RCS themselves.
Realistically, the target demographic for their documentation is 1) Apple (who they'd happily supply with details to get rid of the green bubble problem) and maybe 2) government officials looking into antitrust concerns. In theory someone working for LineageOS can implement an RCS client, though, but for those developers I don't think reverse engineering the remaining unknowns about the protocol (mostly "what server" and "what message contents") aren't that difficult.
I'm not cryptographer, but I haven't heard any major issues from actual cryptographers about MLS. It's encryption principles seem to be similar to those of Signal. Google is actually already using MLS in their proprietary E2EE implementation.
Ideally, MLS would be combined with MIMI so that messaging apps become interoperable, but that's probably a pipe dream.
> who they'd happily supply with details to get rid of the green bubble problem
I would be surprised if this eliminates green bubbles. iMessage supports many features unavailable over RCS on Android devices. These would still be disabled and Apple needs a way to indicate a degraded feature set to iMessage users.
Yep. They’re never going away.
Blue = iMessage Green = Other
It doesn’t matter if both support 100% identical feature sets, it’s gonna stay like that.
it does leave the door open for pointing the finger for who's at fault when text groups with OS blends get all scrambled https://discussions.apple.com/thread/255769788?answerId=2607...
do you have evidence for this?
It’s the way Apple works, and their behavior so far has been consistent.
Blue bubbles are a branding thing, they wouldn’t share them with others. Then what’s the point of having the branding?
They do actually indicate a difference of functionality. RCS doesn’t support iMessage apps for example, not that those get much use.
But like I said, even at parity I think they’d keep the branding.
the issue is that it simply may not be up to them, at least in Europe. if the EU decides that keeping the blue bubbles contravenes the DMA, then the blue bubbles will go
Really shows how apple is only into privacy when it's self-serving.
How does it show that?
Blue bubbles don't mean privacy, and green bubbles don't mean insecure. I would presume encrypted RCS would satisfy privacy, and would remain green to indicate it doesn't support iMessage-specific features.
iMessage is encrypted. Blue means the “SMS” was sent over iMessage and it is secure. Green means it was sent as a normal SMS. This is super helpful for non-technical people that want privacy.
> Green means it was sent as a normal SMS
No it doesn't, and it would mean that even less when green messages start meaning end-to-end encrypted RCS.
What does it mean then? Genuine question.
Because it leaks the device type of your messaging partner.
As another commenter said: how? show your working?
You are at the very least letting this hypothetical scenario (that another random HN commenter posed) feed into your “damn Apple!” feedback loop.
Blue bubbles says nothing about privacy. It tells users which service is being used. It informs them about what to expect. Chill.
> Blue bubbles says nothing about privacy.
iMessage is encrypted, so it is pretty private. Am I missing something?
At least the false pretence would vanish if both support 100%
What about when either changes? Do you expect them to alternate colour schemes as each protocol plays catch up or gets more features?
I was just engaging with a hypothetical - see my other replies to siblings in this thread if you need clarification. iDevices are my daily drivers, but I don't understand all the fanboys getting triggered here
What false pretense? They dictate two different ways of sending messages with different capabilities.
If they were functionally equivalent, why signal a difference? What's the benefit, you think? I'm not saying that they definitely would signal a difference, but in this hypothetical, if the color difference remained, it would be obvious why.
> If they were functionally equivalent, why signal a difference?
Equivalent does not mean the same. Sending an actual SMS can cost extra.
there's two doors through which the message can leave your phone... the blue door and the green door. (Ignoring the SMS tiny door)
If the feature sets of the blue and green door happen to be the same for a time, that doesn't mean a message sent through the green door is "actually" leaving through the blue... The doors are actually different (even if the feature sets are the same (for a time))
We were (originally) talking about a mystical magical timeline where the two standards converge. You can make another hypothetical, where they converge, but only temporarily, but that's a new flavor on the hypothetical that was first posed way way back where the thread started. I'm sick of repeating myself, so I'll leave the musing to those who are more invested.
because they can’t support the same functionality. apple would add something new, they would want no constraints to what they can do.
> apple would add something new
Once again, I'm engaging with a hypothetical. Indeed this is how it would play out in reality.
Branding. It’s that simple.
it's never going to 100%. can't play 8ball with an android
Never said it would be. Just playing hypotheticals with the GGP comment
> It doesn’t matter if both support 100% identical feature sets, it’s gonna stay like that.
That's completely irrelevant. The problem was (obviously!) always about the incompatibilities rather than the color.
Not to Google. Green bubbles were a big social shaming issue affecting the sale of Android. This is all in the US only afaik. So in other countries with a similar iPhone market share there isn’t a green bubble social stigma.
That's false. The color green is irrelevant. If the Apple bubbles had been green, and the Android bubbles had been blue, still the Android bubbles would have been shamed. It was never about the color. It was because of the SMS/iMessage feature incompatibilities.
Let me spell it out: the arbitrary color lets you identify the ones who use Android. Some people think the reason for using Android is being poor. Others don’t want to be seen as poor, because social posturing is important to them.
> Others don’t want to be seen as poor, because social posturing is important to them.
Then they should buy an iPhone if social posturing is important to them.
In all seriousness now: the green buble shows you that you’re sending SMSes which, based on carrier and/or country it can cost you, especially if you’re roaming overseeas where every SMS is 10/20/50c each.
I don't think it has to do with poverty. There are Android phones that are as expensive as iPhones. It was just because of incompatibility.
iPhone users perceive Android devices as poor. It’s naive and biased, but there’s at least some validity based on the fact that Android devices can cost anywhere from $100 for some basic model at Walmart to ~$2k for the bendy/foldies.
What most are saying is that there’s always been the perception that comes with green messages. When I was on Android (pretty much since the first Nexus all the way to the Galaxy Fold 4), I definitely noticed iPhone users avoiding SMSing with me or in groups, and instead using Facebook Messenger because of the issues that come with group texts involving non-iOS users.
Now that I’m on iOS, I’m aware of the differences, although I don’t particularly care since so many Android devices support RCS.
Social posturing is important to everyone. You probably just socially posture differently.
Just please stop sending the text that reads as follows, it totally destroys group chats and the amount of information conveyed in a react doesn't require quoting back the entire message, eg
Liked "I would be surprised if this eliminates green bubbles. iMessage supports many features unavailable over RCS on Android devices. These would still be disabled and Apple needs a way to indicate a degraded feature set to iMessage users."
I have never seen a reaction that helped. "OK" is short, it's in plain text, and it works easily. I don't need your thumbs up. Or your like. You want to emoji, go ahead, but I'm getting older and I can't zoom in on them without blowing up general text to the same size. With more complex emoji I have to screenshot the text and then pull up the image to zoom on it to even tell what it is.
I'd silence the conversation, except that iMessage won't let you have two identical groups with exactly the same members. So both humorous and serious stuff goes into the same group chat, and it's often very time-sensitive if serious. Then three or four people start joking around, reacting to each other, and suddenly while I'm at dinner (or, my favorite, one hour into a three-hour drive) my phone or watch is going off every twenty seconds for five minutes. I can't ignore them, because one of those dings might be from someone else about something that needs an answer right now. I can't risk forgetting to turn notifications back on.
When I still used an Android phone, the max-ten-people SMS rule meant that I was missing important business information - like, for example, I found out that our secretary had cancer when she asked me for restaurant recommendations near MD Anderson Cancer Clinic in Houston. Never occurred to anyone else that I had gotten none of that.
You admit that you’re getting older, and I think that’s part of the disconnect with emojis. OK does not convey the same thing. You’re talking about having to zoom in to see the emoji, and the younger crowd already has every one memorized. The reactions may not help you but I’d say for most of us, they do help.
> OK does not convey the same thing.
Fine. Is "10-4" or "copy that" or "Roger" acceptable? Because the whole point of that text, in a work context (and this is always a work conversation; I like my partners but I'm not personal friends with them), is to convey "I have received your message". And a reaction generates an SMS that is, until you realize what it is, kind of incomprehensible. "Loved '[my comment]'" makes no sense when you get it as a long comment.
> The reactions may not help you
I have trouble seeing how they help anyone. You made an obvious joke. A guy who laughs at anything reacts "HA-HA!!" or whatever. What is the contribution? The youngest member of my partnership is 40, though we do have a 33-year-old joining in a few months.
This isn't "get off my lawn", much as I do love that. It's "explain to me how it's useful for actual minute-to-minute work". I'm a physician. An anesthesiologist. I never know when the next emergency will arise, but OTOH we don't go for a sterile cockpit approach because there are a lot of conversations that have to do with the running of the day at work that aren't entirely serious (and don't involve patient care, as such; that's why we don't use the sterile cockpit method - it's more about figuring out who can let whom go to lunch, becuase you can't just leave someone under anesthesia to go eat, or how we might be able to let Dr. X operate in about an hour - personnel management is the biggest part of my on-call duties).
Well you actually make a point for short reaction standardized support.
You won't be able to alter behavior of everyone around you. So at least the software should render these interactions in the least obnoxious way by being consistent on both side.
You will always be able to ask for textual clarification. But the big win is that you won't be bothered by sub-par quoting repost.
> You will always be able to ask for textual clarification. But the big win is that you won't be bothered by sub-par quoting repost.
Why would I need textual clarification? It was/is a mediocre joke. I don't need to comment on everything that crosses my path.
We are 3-6 people, and our pattern is specific reaction to questions like this. "do (specific task) so I can go forward" "can someone take over communication with X", depending on what we do we react differently I will do it/it is done/please clarify. This means that if you need two people in a meeting and get two "please clarify" and two "will be there" reactions, there will be less traffic in the chat. It is more concise.
You have a hint above you need to be specific what means what, when we onboard new people we go through these things. This is a problem with ontologies you have to be specific and not allow meanings to drift.
I am not a emoji expert but this has been a way to make our chats a lot more easy to get a grip on.
We do not use Apple so do not get "Loved X" types of messages.
> OK does not convey the same thing. Fine. Is "10-4" or "copy that" or "Roger" acceptable? Because the whole point of that text, in a work context (and this is always a work conversation; I like my partners but I'm not personal friends with them), is to convey "I have received your message".
So I had missed the “in a work context”, where I think your point is slightly more valid.
>And a reaction generates an SMS that is, until you realize what it is, kind of incomprehensible. "Loved '[my comment]'" makes no sense when you get it as a long comment.
Only if you don’t both have iPhones, and the necessary information is all at the beginning. You see “Loved” and a few words from the start of the message and you remember what you said and you know which message.
> The reactions may not help you I have trouble seeing how they help anyone. You made an obvious joke. A guy who laughs at anything reacts "HA-HA!!" or whatever. What is the contribution?
So this answer may surprise you, but emoji reacts actually do communicate something unique, and of value. They are more subtle. They also permit the conversation to terminate after the react. In my mind, and the mind of many others, an actual message necessitates a response, and I’d see it as rude to neither respond nor react to a message. Reactions are subtle and out of hand, and you don’t respond _to_ a reaction. Using a react instead of an actual text response has a way of signaling the other user that they don’t need to respond further, that you read their message, how you feel about it, and no further information is necessary. This is incredibly useful and I’d struggle to communicate with any kind of emotional nuance in this day and age without it. More fundamentally, reactions solve the problem of non-verbal communication and body language in text.
>This isn't "get off my lawn", much as I do love that.
It gives “get off my lawn” a bit when you say you don’t see how it would be useful to anyone. I’d never try to convince you that you need to use it, but I do think you should understand the utility for everyone else.
But, I definitely understand that it’s not useful for your professional use case as an anesthesiologist. Also, wow, what a cool job (seriously)!
> Fine. Is "10-4" or "copy that" or "Roger" acceptable?
Or, since we're on a technical forum: "Ack" / ACK.
> I have trouble seeing how they help anyone.
That sounds like a problem unique to yourself and I imagine this is not the only such case in which you struggle.
Imagine away.
At least I can. The seemingly impossible task for you.
While acknowledging that you might not have any agency about this in your specific situation, this sounds more like a social/boundaries problem than a technical one.
If I were in a group chat with people both joking around and sending messages requiring urgent responses, I'd let them know to either cut the banter and keep the channel clear, or contact me otherwise if they need my urgent reaction. Letting people hold my attention hostage like that would drive me crazy.
> keep the channel clear, or contact me otherwise
I realize that I live in an unusual life vis-a-vis most HN readers. I do not work in tech, and I never have. I'm a physician: specifically, an anesthesiologist. I have always enjoyed tech, and I'm certainly miles ahead of most of my colleagues on that. But. Remote work is not possible. Relocating involves getting a new license to practice medicine (3-8 months), getting accepted by the medical staff of any hospital or surgery center you want to work at (~2 months after license is secure and job contract is signed), and all the usual stuff.
So I cannot not answer any number that isn't outside the US system when I'm on call. I can't silence the phone when I'm on call. I can't ignore messages. But we're a partnership, so there's no HR to file a complaint with when someone banters on a business channel, and I can't order them to do something any more than they could order me.
I get not being able to ignore calls (although that sounds like hell too, given how common spam calls are to US numbers), but it would really not be possible for people to agree to call you if they urgently need something?
Not doubting your description of your situation, and it does sound extremely stressful.
No, not really. I’m on call for the whole hospital, after all. Any doctor or nurse can ask who’s on call for anesthesia and get my number. Some call, most text.
So your hospital uses the same group chats for banter and on-call pages? That really sounds quite dangerous (in addition to stressful for the person receiving pages). Again, not sure if you are in any position to suggest changes here, but would an actual on-call paging system not make sense here?
There are so many apps/services available for this exact purpose that can alert (with or without sound, per user choice) through iOS's and Android's "do not disturb" mode, can call or text several numbers in sequence (useful in places with weak signal but a landline) and much more.
It definitely sounds like a technical one if you can't make two groups, one for banter and one for serious talk so you can mute banter when it's not appropriate.
How are other people supposed to know that it's not okay for you right now because you are at dinner?
We all live in the same metro area. You might eat as early as five, you might finish as late as nine. But if you're going to use the business group, it should be about business. Banter is fine during working hours.
People get lazy and just use the "whole group" message rather than send it to those who are working today. And it's much like my problems with Android vs iOS: there are twelve people in this group, eleven of them have iPhones. They are not all going to install and use a separate messaging app for business than for personal communication, especially as iMessage is nominally E2EE. I could adapt or just be completely marginalized. So now twelve have iPhones.
Have you considered using something like Slack or Discord or (can’t believe I’m suggesting this) Teams, all of which sound like they’d be more suited to your use case?
This does not sound like an impossible stretch, works on more device types, and in the case of Slack or Teams can also be configured for HIPAA compliance (which while you don’t call it out, seems like it may be useful). Tens of millions of people use a chat system for work distinct from their personal friend groups, even if the venn diagram is a circle.
I have never used Slack or Discord. I have only used Teams for Zoom-esque meetings.
We do not have desks. Nor do we have offices.
I'm an anesthesiologist; I work where the patient and the surgeon are.
None of those are desktop applications, all work on Android and iPhones alike. All are more suitable for your use cases than SMS, iMessage or RCS.
Are they HIPAA-legit?
Both Slack and Teams can be configured to be HIPAA-compliant (as I already mentioned). Note that iMessage is NOT HIPAA-compliant.
Oh, that for sure. That seems like the obvious solution I'd pick on Signal or WhatsApp, and if Apple Messages doesn't support it, it's yet another infuriating example of their "we know best" attitude.
I like Apple hardware, but try to avoid its first party apps as much as possible due to that.
What happens if you have a group with N+1 members and then remove the extra one? That would be a weird error message to write... "you can't remove X because everyone else is already in a group?"
The thumbed up reaction is useful because you can react to something specific in a fast-paced conversation. iMessage also allows replying to a specific message, which is also useful for the same reasons.
> With more complex emoji I have to screenshot the text and then pull up the image to zoom on it to even tell what it is.
...you can make the font bigger. Or get glasses.
> I'd silence the conversation, except that iMessage won't let you have two identical groups with exactly the same members
Create group 1 with coworkers A,B. Create group 2 with coworkers B,C. Add C to group 1, A to group 2. Two different chat groups.
"I won't bother to look up how to do things on my phone" != "my phone sucks."
> The thumbed up reaction is useful because you can react to something specific in a fast-paced conversation. iMessage also allows replying to a specific message, which is also useful for the same reasons.
A makes joke. B and C react "laugh". D replies with sub-joke. E, F, and G react "groan". Produce this little cascade every time a serious topic is brought up and someone makes an offhand joke as a lead-in to a serious topic.
> you can make the font bigger. Or get glasses
I have and use reading glasses. Making the font bigger is an option but I can read text just fine at that size. I can't make out the details of a complex emoji.
> Create group 1 with coworkers A,B. Create group 2 with coworkers B,C. Add C to group 1, A to group 2. Two different chat groups.
A completely non-obvious behavior (you can only create a group after you have sent the first text, see https://support.apple.com/guide/iphone/group-conversations-i... for info), and as it's late at night, I can't test it. Trying to search for how to do this turns up mostly threads about how the same group of contacts keeps showing up in different conversation threads.
> "I won't bother to look up how to do things on my phone" != "my phone sucks."
Feel free to tell me what search will show me how to make a "MyCompany - Business" and "MyCompany - Social" group without ever sending a message, and guaranteeing that Business messages always go to Business and Social always go to Social.
> A makes joke. B and C react "laugh". D replies with sub-joke. E, F, and G react "groan". Produce this little cascade every time a serious topic is brought up and someone makes an offhand joke as a lead-in to a serious topic.
iMessages/SMS is not a conversation or an email and the same rules don't apply. You don't have the recipient's attention for any longer than it takes to read the message you've sent. If you want to make a joke then make a point you need to do both in the same message.
You should look at how to zoom on your iPhone - https://support.apple.com/en-gb/guide/iphone/iph3e2e367e/ios
> I'd silence the conversation, except that iMessage won't let you have two identical groups with exactly the same members. So both humorous and serious stuff goes into the same group chat, and it's often very time-sensitive if serious
Really? That's insane, so that means that 3rd party messaging apps literally have better UX than first party ones, as I have lots of groups with the same members for different things.
Absolutely. Apple Messages is way too minimal, for both iMessage and SMS.
As another example, it makes it almost impossible to manage multiple numbers for a given contact (e.g. to explicitly text somebody’s work phone), and the sender side is very confusing as well with dual-SIM. Apple’s implementation freely merges threads that I’m trying hard to keep separate and then still falls over with tons of delivery errors in complex situations (usually after swapping SIMs).
It all works reasonably well if you have a single long-lived mobile number and all your contacts have the same, and are using iMessage (or now RCS), since that’s presumably the reality for most Apple engineers.
Anything slightly more unusual and the thing falls apart completely and makes me wish for a Nokia 3310 (or convince my contact to switch to something more reasonable for messaging).
I don't believe this is true, but you do have to give one of the iMessage groups a name to make it independent from another group. If you imagine that primary key for a group is its name, and the default name for a group is its participants, this does kind of make sense.
I have a number of iMessage groups with the same participants, and different names and logos.
You'd expect an app, like Whatsapp or Discord or Signal, which focuses primarily on messaging, to be able to devote more attention to it than apple, which is really just a hardware company that reluctantly makes just enough software to charge 30% of all the good app's profits, and sell their hardware.
iMessage just not supporting android/windows/linux devices already makes it drastically worse than any other popular chat app.
You’ve pretty much indirectly nailed the issue: on iOS, iMessage is much more than just a “chat app”. It has an unrivaled feature set on iOS that isn’t replicable on other chat apps. The discourse that reduces it to a “chat app” is critically missing this point.
This wouldn’t mean much if iOS was a small percentage of phones. In regions where it is a majority of phones people use those additional features. In places like the US where most people are using iOS, most people don’t even realize those features don’t exist or are semi-broken on other chat apps because they don’t use them. For average people that have been using iMessage for a long time with other iMessage users, using those other chat apps feels like a downgrade.
What features?
The only two features I can think of that iMessage has which discord/whatsapp/etc don't are:
1. Automatically can flip to "do not disturb" mode when my phone is in sleep mode, and display that notice to my companion. Other chat apps require manually configuring that I think. I also suspect apple doesn't provide an API to make this easily possible for other apps.
2. iMessage makes it easy to identify the poors, the android users, and ignore them. If I exchange numbers on a dating app and get a green bubble, I can know to immediately ghost them.
Are those the features you were thinking about, or something else?
Most (all?) of the Apple iOS apps and data can be collaboratively shared, edited, etc over iMessage and it is extremely seamless with fine-grained access controls. I get people sending me calendars, notes, slide decks, documents, etc to either read or work on together via iMessage/iCloud. You can selectively share most things in your iOS environment with any other person in the iOS ecosystem. Google Apps is a pale imitation of this. And the security is tight.
I’ve never seen anything like this on any other chat app I’ve used. Most objects in iOS can be directly shared or collaborated on over iMessage, and that is a very rich set of objects. People that only use iMessage don’t even realize other chat apps can’t do some of these things.
So… attachments? WhatsApp and Signal can send those too, directly from the share sheet.
I find the iMessage implementation very clunky compared to WhatsApp. It’s trying so hard to be “minimal” about delivery status and recipient capabilities that I never quite know whether something worked or not, especially with contacts that have older devices on their iMessage account.
You don't work with non-techie adults, do you?
They use iMessage with their family and friends. They use it at work too. Some of their friends, and maybe some of their family, work at the same place. I can try to convince 11 other people who are my business partners to switch to, say, Signal. A special app used only for our group communications. Or I can buy an iPhone. I chose the latter.
It's not my choice. I'm making the best of it that I can. I wish it were not so, but it is.
All the non-tech people in every non-US country have whatsapp/telegram/wechat/line/kakao installed (depending on the country), and it seems to work fine.
It's just the US that has picked a universal messenger that doesn't work on android, every other country, the vast majority of the planet, defaults to a cross-platform phone messenger app.
In short, consider moving to europe.
Not every non-US country. Most people in Norway have iPhones, so iMessage is heavily used. They also use Facebook messenger a lot for some bizarre reason.
> I also suspect apple doesn't provide an API to make this easily possible for other apps.
They do: https://developer.apple.com/documentation/usernotifications/...
Knowing focus status and being told live when it changes are public API. I think other apps just choose not to do it. Sample project: https://developer.apple.com/documentation/usernotifications/...
> iMessage makes it easy to identify the poors, the android users, and ignore them.
I hope this is sarcasm, and you're not actually that narrow minded.
It is an interesting complete marketing victory in the US by Apple though, that there is a widespread perception that you would only have an Android if you couldn't afford an iPhone. I've had an iPhone for work, it's fine. I much prefer Android and I'll stick to it, and the reasons for that have nothing to do with money. I'm glad I don't love in the US where that would apparently make me a social pariah.
iMessage's killer feature is that you can send a group message to more than a total of ten people. SMS does not officially support this.
I do not recall this being a problem in the pre-iMessage days, even with flip phones. I was on prepaid T-Mobile and had to pay for every message I received, which is the one place where I thought the US billing system had gone nuts - you could always decline to receive a phone call, knowing the number, but you can't refuse a text. I was surprised that nobody ever abused that, but they never did so on a large scale. At ten cents per text, sent or received, you communicated when you needed to, or when you had something to contribute, but one minute of voice was the same cost. One sent and one received text cost as much as two minutes of talk, which can convey a lot more information.
I can't remember the last time I sent an SMS. Comparing iMessage to SMS is not useful. Compare it to one of the (several) cross platform messaging services.
In Europe, Android is on equal par with Apple. WhatsApp is the default messaging service - it is universally installed among my friends, relatives, colleagues, contractors etc.. No-one cares what model of phone the other person has. Everyone communicates.
There’s an API for “focus mode” now, I believe.
I thought Android released an update last year to automatically interpret those as display them as reactions.
iOS did it too when communicating with Android but also updated.
The protocol is open but key exchange is not: even on Android, third-party messengers can’t interoperate with Google Messages. See page 11 of that PDF.
That's true, but Google has also indicated that they're switching to the GSMA spec which is intended for interoperability.
I also doubt that Google would withhold such details from parties like Apple even if they maintained their proprietary format. Small developers would need to reverse engineer the details, unfortunately.
My question is basically whether they open it up or limit it to companies they have deals with. Reverse engineering is a risky game for a service with device checks since that’s potentially a CFAA violation and it could lead to your users getting their hardware banned.
That text seems more a reflection of the fact that only Messages supported it, when the document was written
If they seriously wanted random third parties to implement it, anyhow, they'd have published a specification, not an "overview"
Only Messages was allowed to support it. At the time it was written, for example, it was years after the Signal developers had asked for basic RCS support (2015) and given up on Google relenting and allowing it in 2018.
https://github.com/signalapp/Signal-Android/issues/4837
Signal has been rather dismissive of RCS in general. Of course RCS was as insecure and unencrypted as regular SMS/MMS until now, but I haven't found a sign that Signal ever even looked into supporting RCS at all.
At this point I think they just wanted to get rid of their SMS backup feature and used RCS as an excuse.
Signal was dismissive of unencrypted messaging. Google used their protocol for their proprietary E2EE system so it’s unlikely that this objection would apply if that system was open.
Put another way, if this was a Signal thing what other Android app is doing this?
Did you read that issue? It's Moxie that refused to support it
Yes, I followed it when it was open. Which third-party app do you use which supports RCS E2EE?
None, but that issue has no mention of what you said in the other message
("Only Messages was allowed to support it. At the time it was written, for example, it was years after the Signal developers had asked for basic RCS support (2015) and given up on Google relenting and allowing it in 2018")
> the green bubble problem
Is this a problem? Outside NA?
Because the rest of the world seems to neither care nor even notice the bubble (of either colour) i.e iMessage is irrelevant almost entirely outside North America (and that too I guess mostly USA; only among just the iPhone users of course)
I believe Canada has an even higher iOS market share than the US. Mexico mostly uses WhatsApp but I don’t text people there much. I have and use both WhatsApp and Signal routinely in addition to iMessage; no one I know uses WhatsApp within North America and only a handful use Signal.
When I worked in Europe just about everyone I texted with had an iPhone. We always use WhatsApp or Signal there by default. Nonetheless, iMessage was usually the fallback when those chat apps glitched because it is so reliable, especially compared to Signal. YMMV, etc.
What iMessage has going for it is that it is genuinely a very good implementation of a social chat app with unique features enabled by the iCloud ecosystem. I’m pretty agnostic about it, I’ve used a lot of chat apps by virtue of being more global than most, but iMessage is objectively pretty great when you stay within the Apple ecosystem. I’ve reduced things down to WhatsApp, Signal, and iMessage, which is kind of the minimum set that gets you global coverage, but if everyone is on iOS then iMessage is noticeably superior to Signal or WhatsApp. iMessage is more than just a chat app but it limits itself to that when interacting with other ecosystems.
America is the world's biggest market and most hackernews live here. So it's pretty relevant here.
China has 1b consumers. Just saying. India too.
together, india and china's consumer spending is about 42% of just America's. number of consumers isn't worth squat; dollars spent is.
> I don't think reverse engineering the remaining unknowns about the protocol (mostly "what server" and "what message contents") aren't that difficult.
That's hard to parse. Removing the double negation, we end up with
"I think reverse engineering the remaining unknowns about the protocol (mostly "what server" and "what message contents") are that difficult."
> many developers are waiting for Google to add RCS to the same API that SMS/MMS already exposes because they don't want to implement RCS themselves.
Is that a planned feature? It's frustrating that third party messaging apps don't work with RCS. I hope we don't have to get the EU involved here...
Extra context I forgot to provide:
> RCS may require access to certain SIM card information, which only pre-installed apps can do
> because they don't want to implement RCS themselves.
Sounds like they can't implement RCS themselves even if they wanted to, not simply that Google doesn't provide an open source implementation? (Referring to app developers here, not custom ROM devs.)
They can't implement RCS for every carrier, but they can implement it for some. Others require nothing more than a network call to a predefined HTTP address over a data connection.
Although Google may dislike it, I don't believe Google's RCS implementation (the one most of the world uses) requires elevated permissions. Their activation sequence is proprietary and closed source, though so I'm not 100% sure.
Just having a base implementation for custom ROMs would be a start. Given that Google will block custom ROMs from RCS in their app (I believe because the spec says to), there is a need for an independent implementation if this makes RCS popular enough under American users.
Someone will have to inventory the activation mechanisms for each carrier to see if there really is a disadvantage. I'd start with mine, but all of the carriers in my country have shut down their RCS servers a decade ago.
I am not familiar with RCS, but considering the plethora of messaging apps available that just work, why did they choose the most complicated way for users to use it? And what do you mean it is not available on every carrier and needs SIM access?
I haven't seen any indication of that at all. There's sort of an API, but it's basically restricted to Samsung's messenger only.
The EU won't get involved unless a significant chunk of the user base uses Google Messenger. I don't think EU users will reach that threshold because most of the EU uses basically any chat app except for SMS/MMS. Things like receiving verification SMS messages still work using the existing API and I have a feeling that that represents the majority of SMS use in the EU.
I understand your point that the "news" part is that RCS standard now includes E2EE, rather than about Apple's support for said standard.
But I don't think it's fair to suggest or imply that this development is unrelated to Apple either.
RCS has been a thing for nearly a decade, and Google's RCS backend has been doing non-standard E2EE for half that time.
Within 8 months of Apple publicly announcing they would adopt RCS and work with GSMA to support standardised E2EE, there is suddenly a standard for it...
It is worth noting that the E2EE system they are using (MLS/RFC9420) was only finalised as a standard as of mid 2023 and has had errata from the last few months. They basically added E2EE to RCS more or less as soon as the protocol they are using standardized with IETF.
Google has been working on replacing the ad-hoc Signal protocol with MLS since before Apple announced they'd support RCS, it would have happened anyway.
It's more likely Apple was made aware of the spec/Jibe/Messages roadmap when they finally got on board, decided not to target the latest UP version for some reason, and realized implementing the current E2EE scheme would be wasted effort given it would need to be revamped within a year. The iOS RCS client is still pretty far from being provisioned worldwide.
Given how telcos historically handled messaging (like MMS), skepticism is understandable
Is there anything that shows "no one was allowed to use it" or was it that it wasn't an accepted standard?
Look at Google’s documentation: they explicitly state that only their Messages app is allowed to talk to their key exchange server. The entire marketing campaign they ran about RCS was predicated on nobody reading their docs or noticing all of the Android developers begging for permission to use RCS for years.
https://www.gstatic.com/messages/papers/messages_e2ee.pdf
> E2EE is implemented in the Messages client, so both clients in a conversation must use Messages, otherwise the conversation becomes unencrypted RCS. In rare situations where the conversation starts as E2EE, then one of the clients migrates to a different RCS client or an older Messages client that does not support E2EE, Messages might be unable to detect the change immediately. If the Messages user sends a new message, it’s still E2EE, however the recipient client may render the encrypted base64 payload directly as message content.
https://news.ycombinator.com/item?id=43368471
Yes, Google only made it available for Google Messages. They don't have an SDK or API you can use to make your own clients or servers. Google also didn't put it up for standards with the GSMA or any other standards body, at least not publicly. There are no records of it.
There are some older submissions here you can probably find using one of the HN search sites about this, but IIRC those didn't really have any internal Google policy about this, they kept it all pretty private. The only 'leak' I remember about this was the thing where manufacturers that preload Google Android have to ship Google Messages to get RCS support from Google, otherwise they can't have it. Also means you can't have RCS without Play Services.
The destruction of third party apps has been totally wild.
I'm very curious how long this OS-coupled status quo is going to go on for.
It was just released in the last day or two. There had been drafts I think but now it’s real.
So someone asked Apple and they said “sure we’ll support that”.
I think the big news is that RCS can now be encrypted without relying on Google, but that’s not what gets you headlines.
[dead]
I really, really, really hope RCS doesn't make it as a standard.
Now that it's end-to-end encrypted, it's slightly better than SMS, but it's still laughably incapable compared to decades-old protocols that support multiple devices, phone-number-independent identifiers, self-hosting, have open implementations and non-insane specifications etc.
As it is, RCS is just Google Talk (Google runs most of the infrastructure), but tied to a single device (no messaging from your laptop or tablet if your phone battery dies!) and impossible to use without a phone number.
It makes me really sad to see that even technical audiences don't see the long-term plan here: Cementing the use of phone numbers instead of email addresses as the primary identifiers in people's digital lives, and making the closed, carrier and Google operated RCS ecosystem the ultimate replacement for email and other open web standards for B2C and P2P messaging. (Yeah, most people already use Gmail, but the point is that self-hosting email is at least still possible, and there's still relatively free competition of sending service providers; with RCS, there's no chance to play without paying the cartel.)
> Cementing the use of phone numbers instead of email addresses as the primary identifiers in people's digital lives
From my experience RCS is just a backup/temporary holdover system to keep SMS usable as is, since people are increasingly using regular chat apps like WhatsApp. Plus as long as spam/identity is a major issue then phone numbers will be a part of verification systems. They will use anything they can get to make it harder to abuse. Whether the root ID is phones or not doesn't really make a difference if a phone number is required at some point to use a service.
There's a large split here between the US (where people largely use SMS and now RCS) and the rest of the world, which largely uses WhatsApp, WeChat, or very few others.
I'm of course also just as critical of having Meta run the world's communication industry instead of Google, but that's the duopoly (or rather two monopolies split geographically) we're headed towards. Cheering on RCS as a way out of it, instead of directly towards it, is deeply misguided.
That said, at least WhatsApp provides some basic features that XMPP has supported more than 20 years ago (multiple devices being logged in simultaneously, synced message archives etc.) – I'm not holding my breath ever seeing these on RCS. As a pseudo-federated standard, protocol and client development will always be much more complex, and looking at the baseline complexity of the RCS specification powering the few existing features, I'm just not seeing it happen.
Needing my phone to be powered up and connected to the Internet to message people from my computer in 2025 is absurd.
> I'm of course also just as critical of having Meta run the world's communication industry instead of Google, but that's the duopoly
Don't forget Apple with their iMessage protocol.
RCS is a GSMA standard, like VoLTE and SMS messages. Of course it's going to use telecoms features as unique identifiers, that's what it was designed to do.
While I agree that tying everying to a phone number is far from optimal, it's the status quo in messenger land. Only tech nerds use services like XMPP and Matrix, the rest all use either chat apps that tie you to a phone number or just text directly.
RCS is there for the people who still use SMS/MMS. In my country, that's basically nobody. In Canada and the US, that's the majority of non-iPhone people, and the iPhone people have been complaining about the shitty integration between iMessage and MMS since the day iMessage took off (because MMS is terrible for modern messengers).
RCS runs on your carrier's infrastructure. Google hosts RCS services for people whose carrier doesn't support RCS, but Apple won't be using those. RCS on iOS requires carrier support, which many carriers still have yet to turn back on.
I think you're confusing the status quo with the goal behind RCS. The unfortunate truth is, the people who are using RCS would've used SMS/MMS before. RCS just appeared in their messengers some day and made texting a lot better.
I'd still advocate for signal over RCS any time of the week (though I don't need to, because nobody uses SMS/RCS here anyway thanks to WhatsApp), but RCS is an abject improvement over the terrible messenger protocols it replaced.
> it's the status quo in messenger land
Yes, and it's incredibly frustrating that we couldn't avoid ending up here. Maybe it was inevitable, but I still find it very sad.
Even worse: it silently fails if the device does not run an unmodified anf certified Google Android OS. This means, it will not work on alternative OS and rooted devices
It also silently fails if other party has android phone, but no internet connection. There is no fallback to SMS which works over plain GSM.
It's far more than "slightly better." It supports full resolution content, longer messages, and reactions/interactions. For most people it's indistinguishable from iMessage/etc.
Do you really think that phone numbers aren't already a ubiquitous identifier? That is done. Nothing you're saying is changing because of RCS.
Yes, it's already largely done, but that doesn't mean it was a good idea, so why cheer moving into the same bad direction just because there's now finally a baseline of security?
It's also anything but indistinguishable from iMessage. I can use iMessage on any number of devices without my phone having to be turned on, having the SIM with my number on it inserted, and being connected to the Internet (not always a given when traveling etc.)
The same is true for WhatsApp. Even XMPP could do it 20 years ago! This is not a new niche feature – it's absolutely essential for a modern instant messaging protocol!
You’d rather we turn everything over to Facebook/Meta?
No, I'd rather we have an actually open, federated standard such as XMPP or Matrix, with a trusted directory service binding phone numbers (that one could be operated by phone networks) and email addresses or DNS domains to IM handles.
And if we can't figure that out, I consider Google and Meta equally bad gatekeepers of global B2C and P2P communication, and don't see why I should use the technically strictly inferior solution of the two.
Unfortunately, RCS on Android requires google apps, so this isn't really a solution to anyone who doesn't want to be tracked by Google everywhere they go.
I'm still a little confused as to what problem RCS is supposed to solve. It is just as centralized as any other chat app, and is a bit more invasive (often requiring device attestation). Is it really worth all this hassle just to not have to install, let's say, Signal?
Defaults matter. While I've gotten some of my friends and family members to install and use Signal, I still have more chats via SMS/MMS (and more recently RCS, since Apple finally started supporting it) than I do on all other messaging apps combined.
Where (and why) is that?
I'm from Chile, and the last time I sent an SMS (or heard of anyone sending an SMS) must have been like 12 years ago.
Ever since then, everyone has used Whatsapp or Telegram instead.
Probably the US. SMS, MMS, and now RCS are still ubiquitous there – and only there, as far as I know.
If you decline to use WhatsApp you need to use SMS for a lot of contacts in Germany. Or RCS since the latest iOS update.
in NA, SMS is still dominant. Eu+Sa+india use whatsapp, china/japan have their own apps
This is likely to differ greatly by demographic. I don’t know literally anyone who uses SMS/MMS. The only SMS message I’ve received in years are automated services/spam.
That's not necessarily true. For full compatibility you'd need a pre-installed app on Android, but vendors like Samsung and Sony and OnePlus can build their own RCS messengers for those devices should they choose to. Same with custom ROM developers for an open source implementation.
For non-ROM developers, it depends on what RCS activation technique your carrier uses.
RCS isn't a Google spec, or an Apple spec, or even an IETF/IEEE/ISO spec. It's part of the core mobile networking specifications. It was created by the people who designed the MMS spec after 4G switched mobile networks to everything-over-IP. Unfortunately, the 4G spec didn't require RCS, it was just an optional side feature, so carriers never bothered with it.
RCS solves the problem that most of the US uses iMessage or SMS/MMS, but the SMS/MMS part of that equation is absolutely dreadful. File size limits are stuck in the mid 2000s, messages are split over multiple SMS packets if you send more than one sentence, the entire thing is unencrypted. Sometimes people like to send photos to each other and the 150KiB or so file size limit on MMS isn't enough for that anymore.
As for why not have people install Signal: why would they, because everyone is already using something else? I live in a country where everyone uses chat apps and all but one of my contacts are on WhatsApp. In other places, that'll be Telegram, and in some North American countries, that'll be iMessage/MMS, the texting app that comes with the phone for sending texts.
> For non-ROM developers, it depends on what RCS activation technique your carrier uses.
There's your problem right there. You may not remember being charged per message, but trust me, it was a thing.
The carriers would love to go back to 2 cents per sms, 5 per rcs "rich message" and 10 per encrypted "rich message".
Being charged per message, per minute is pretty common all over the world.
And a lot of carriers still don’t support international romain or will charge a shit ton.
Usually, the cheapest approach is to just buy a cheap sim when you visit another country, but that doesn’t play well if you rely on SMS.
I don't believe this FUD. I think overal the market has moved from from charging for messages. I fully believe carriers would love to rip off everyone as much as they can, but I think carriers know customers would just use facebook messenger if they tried charging per-message.
Carriers charging too much is exactly why WhatsApp became so popular in so many countries. It was optimised for very little data usage, so was dramatically cheaper than SMS.
Don't forget you could also send photos with it, which is more than what can be said about MMS.
Funny enough, I think I was charged once for a MMS in the past 5 years. No idea how I managed to do it, but it seems to still exist and still be charged per message even on my unlimited everything else plan.
Exactly. That happened like 10-15 years ago. I think the market has evolved and consumers now would not accept this from carriers now.
>but vendors like Samsung and Sony and OnePlus can build their own RCS messengers for those devices should they choose to.
Yes, but AFAIK they all caved and switched to google messages instead
>Same with custom ROM developers for an open source implementation.
Does one exists?
RCS seems to be mainly designed as a successor for SMS.
For interpersonal communication, SMS is dead in the majority of the world, so a successor is entirely irrelevant.
For for the 1 or 2 countries where people still send SMS, RCS seems like a major improvement with a bunch of feature that have been available on other platforms for many years now.
No, it's worse than a standard centralized chat app: It's ostensibly federated, with network operators running the servers.
But practically, only Google actually knows how to do that (the specifications are absurdly complicated!), and so they do it for all operators as a service.
It's a fig leaf of an open protocol and service even for telco industry standards.
Now that Signal cannot be the SMS / RCS app, yes that's too much hassle. Network effects are too powerful.
Oh, what's up with Signal?
They used to be SMS compatible. But now are just a solo like most other chat app.
https://signal.org/blog/sms-removal-android/
It also requires a Google account as far as I know. I have Google apps but no account signed in. And when I tap on the connect RCS option it asks me to sign in.
Anyway iMessage (and iOS for that matter) is irrelevant where I live so I don't expect this to change anything. I'm not going to be on RCS. The main apps here are WhatsApp and Telegram (the latter more for groups)
I have a very minimal Android phone with no Google account ever added/used on the device, and it says my chats with other Android users are using RCS ...
The phone number is associated in the other direction though (way back when Google didn't be evil and GMail required invites, I dared to trust them with it, I forget for what).
It shouldn't. The only reason Google Messages sometimes asks for an account is to support remote access via messages.google.com without scanning a QR code, as far as I know.
While it's largely openness/federation theater (Google runs most servers in the background, either on behalf of or instead of the mobile networks), they at least got that part right (as in conforming to the specification, not as in doing the long-term right thing for users) and exclusively use the phone number as an identifier.
Ah ok strange. It is a Samsung phone though. Samsung has been forcing a Google login in more and more places unfortunately. I think they made some deal with them about the AI features. Just like they now promote OneDrive instead of their own cloud. Maybe that's why or I didn't understand the popup.
I don't really want it if I can't access my messages online anyway. The whole reason I love telegram and WhatsApp is that I don't need my phone when I'm on the computer (which is 90% of the time). But a Google account is out of the question.
Right now I even bridge WhatsApp and Telegram through matrix because I don't trust those either, though I don't think I trust any company less than Google. But I don't know if you can do that for RCS.
But tbh I'm not looking for any other chat app unless it's federated and I can run my own server. RCS is technically federated but limited to a group of big companies so that's pretty useless to me.
I think I'll just block it just like I do SMS. I turn off all the notifications for the relevant apps.
No chance for bridging RCS to Matrix, as far as I know. That’s what I find so concerning about it: It’s theoretically more open, but practically much more locked down than both SMS and proprietary alternatives.
Yeah me too. It doesn't help at all to take control away from big tech (really, meta or google is the same difference). And it loops in the phone carriers. You know, those guys that charged us 1 euro for 180 bytes just because they could get away with it. I never ever want those guys in the middle again, just as a raw bit pipe only.
The only thing that's open is the standard, but in practice you need to be on google's radar to be connected. So it's just as closed to us as everything else.
this is so true for networks that don't implement RCS servers, not even Android - iOS interop present!
one thing i would like to see happen is deprecating SMS message with Labels rather than numbers, phishing has got far far too common in my jurisdiction RCS + some sort of DNS validation like atproto of sender would go a long long way
> RCS + some sort of DNS validation like atproto of sender would go a long long way
Now this would be a messaging protocol I could get behind. Phone networks could even provide a phone number registry for people that insist on using that for whatever reason.
But there's absolutely no chance it'll happen – neither the telecommunications industry nor Google have any interest in making federation for others than "trusted partners" possible.
SMS is already a goldmine for carriers (thanks to the widespread use of SMS for OTPs and authentication), so why not make the next logical step and replace email for as many remaining B2C use cases as possible and collect some rent there as well?
Your point about Google's central role is spot-on, and without an open, Google-independent implementation, RCS does remain problematic for anyone avoiding that ecosystem.
Yes. Not everyone is going to install Signal (which isn’t end to end encrypted btw), everyone has a cell phone that can support either iMessage/RCS/MMS/SMS and when you send a message to someone else’s number, you have graceful (sic) degradation.
Could you elaborate on your claim that Signal is not end-to-end encrypted?
Signal is absolutely end-to-end encrypted
Lol signal is end to end encrypted. what are you even talking about? are you thinking telegram or something?
Why was RCS even designed with a none encrypted mode? I get that the original spec isn't exactly new, but it's also not so old that encryption, security or privacy wasn't an issue.
Phone calls aren't encrypted either, if you think about it [1]. There's a large expectation of the telecommunications industry to be able to perform legal interception, and providing end-to-end encryption out of the box might be seen as a direct violation of that requirement.
[1] Except, somewhat incongruently, between Google Fi subscribers on some Android phones: https://support.google.com/fi/answer/11295314?hl=en – no idea how that came to be and how it even works! I suspect it just upgrades to a FaceTime-like VoIP call.
Encryption and privacy isn't an issue for carriers, which were part of the standard body and operate SMS protocol even in 2025.
You assume everyone has the same goals in mind :)
It's the evolution of SMS/MMS; development started 18 years ago, in 2007. The modern spec is based on that with a whole bunch of additional revisions for things like video calling and transferring money. It was designed long before major messenger apps had e2ee in the first place.
Had it been designed with the security practices at the time, the protocol would've been ossified to the point of being practically insecure by today's standards. In a sense, the fact nobody cared about it until the spec was old enough to drive is actually good for users.
The GSMA which designs RCS also serves the needs of government agencies that are tracking (international) criminals, so I bet there must have been some pretty strong opposition against E2EE in the official spec. Frankly, I'm surprised they're even putting it in the spec.
I'm not sure about the case of RCS, but I've seen some instances of a none cipher being better for compression and deduplication, because the encryption messes with the data.
You'd normally compress the data before encrypting it as that makes the resulting cyphertext more resilient against cryptanalysis as well as reduces the amount of data which needs to be encrypted so this sounds like a bogus reason.
That doesn't allow you to deduplicate across users, though – which of course is the entire point, or the network would be able to see who's forwarding which documents.
It depends on what you're doing I guess... for storage it doesn't make sense, but for pushing a lot of data over a private pipe, why spend the resources adding a cipher?
You'd have to compress every single message separately and then encrypt them. That's still a far cry from being able to compress across every message.
I assume some sort of multicast.
It’s funny that everyone bashed Apple for their lack of RCS support and now that they have it, all posts seem to indicate RCS is a shit standard at best. I have no idea if it is but that’s the impression I got.
I guess it was just a talking point to shit on Apple’s approach?
I don’t care anyway. Here everyone uses WhatsApp so RCS is not important but just an outsider observation.
It's possible that the people complaining now are not the same people that complained about apple's lack of rcs support.
I think the RCS users are quite happy that iOS has RCS now. Though, they may be disappointed that Apple didn't set up an RCS server like Google did, because now people find out that their carrier doesn't do RCS so they're still missing out in the advantages.
But, when RCS works, it works well. The stupid compatibility hacks Google and Samsung and everyone else implemented to make SMS/MMS pretend to be good at group messaging (like the ways they indicate emoji reactions) no longer need to be encoded in human-readable form.
The encrypted component of RCS was a Google special and I think everyone knew that. People wanted Apple to immediately take up Google's encryption spec, but Apple waited for the GSMA spec to be updated with E2EE which is a much cleaner solution.
The opponents of RCS have a point; using RCS is a bit like using your ISP's email servers in that the quality of your ISP determines how good of a time you'll behaving with it.
There are also many advantages to full RCS support that nobody seems to have implemented yet. Things like video calls, or sending money over text. No longer needing third party services like FaceTime or WhatsApp to do video calls is a step in the right direction in my book.
> I guess it was just a talking point to shit on Apple’s approach?
Apple is not a sports team. What people are shitting on is a vendor-specific messaging app. It would be the same if there was a Samsung chat.
> I guess it was just a talking point to shit on Apple’s approach?
It started with Apple promoting the "green bubble = inferior" thing. Google responded by insisting the iMessage experience with Android was only bad because Apple refused to support RCS. Now here we are.
The RCS protocol is much better than SMS/MMS. But there are also plenty of better protocols out there. Both can be true.
It is good that commercial messengers forced GSM association to finally create E2EE standards. The reason why telcos want you to use RCS becomes obvious if you calculate how much 1Gb of data costs if sent as SMS (I guess that one could buy a car with this money).
Does any carrier still charge for SMS messages?
I'd say it's the norm rather than the exception outside of the US.
US operators do things quite a bit differently from the rest of the world; for example, prepaid cards without a monthly fee are not really a thing, i.e. essentially every plan has a monthly fee, but that then almost always includes texting.
Outside the US, it's usually possible to receive calls and SMS on a prepaid SIM without paying anything other than maybe the occasional top-up to not lose the number; in exchange, outbound texts and calls are usually paid.
I believe the distinction that separated the US from the rest of the world is that US carriers charged the recipient of a message, while the rest of the world charged the sender. I don't know if that's true for evrryer carrier or if it's still true today, but it made a major difference.
It's also the reason apps threaten you with fees ("this service may cost you money") when all they do is send a verification SMS. Receiving messages is free in most places but because of a handful of shitty carriers apps now have this warning embedded in them.
It’s actually a “shared cost” model, not really “called party pays”, as far as I know.
And as far as I understand, this is all downstream of US mobile numbers not having a dedicated prefix identifying them.
They have region-specific area codes just like landlines to which calls are physically routed, and from there it’s routed onwards to wherever the mobile phone might be. That could well be a long-distance leg of which the caller is unaware, so it would be surprising to bill them for it. That leaves only the called party.
This model was then probably just carried over to SMS.
US carriers haven’t charged for long distance calls for decades at least for domestic calls.
Besides with number portability, you can keep your same mobile number when you change carriers no matter what the original region was. I’ve had my same number for over 20 years and have changed carriers 5 times.
They're largely not charging end users for it anymore because the cost is just too low these days, true, but as I understand that's still how the pricing model evolved.
> you can keep your same mobile number when you change carriers no matter what the original region was
Yes, but only because all carriers have physical or at least logical/rented infrastructure in effectively all "rate centers" [1]. The call still goes to whatever rate center your number corresponds to (barring other agreements, I assume, e.g. the originating and terminating carrier having VoIP interconnectivity).
That's very different in countries that have dedicated prefixes for mobile numbers: The originating carrier can immediately detect the target network (instead of target region) from the prefix and route the call to the nearest interconnection point between the two.
This means that the terminating carrier usually carries the traffic for the longest geographic stretch, something for which they usually/historically got to bill the originating carrier via interconnection fees. Today, these fees are either gone or nominal/heavily regulated, but the more efficient routing is still a factor for reliability.
[1] https://en.wikipedia.org/wiki/Rate_center
No one pays extra for SMS - sender or receiver. I’m not aware of any carrier in the US that charges.
Explicit charges are very rare these days, but there are at least still metered plans that count both incoming and outgoing texts against a monthly maximum.
Mine either provides 120 SMS/minutes or unlimited text and call. I used to use the 120 minutes version and almost exclusively used it for phone calls. These days I'm on unlimited because of a combo discount on my phone.
Most of the world isn't using SMS/MMS so lots of places have carriers that still charge for the feature.
When I enabled RCS on my Android, I started getting ads with rich media. So I disabled it. And moreover WhatsApp is the dominant messaging app in my country. So this doesn't matter.
Ads? Where? There's no spot in Google Messages for them.
Rampant spam has forced Google to turn off RCS ads in India[0]
[0] https://www.theverge.com/2022/6/1/23150243/google-rcs-ads-in...
It's not RCS that was turned off, just "Business Messaging", meant for trusted companies to communicate with their customers.
Not on the Google Messages app itself, but inside the messages. Just like spam promotional emails.
Emails??
Rampant spam has forced Google to turn off RCS ads in India[0]
[0] https://www.theverge.com/2022/6/1/23150243/google-rcs-ads-in...
Fortunately, this doesn't really affect those of us outside of the USA, since we've long since moved on.
RCS is very popular in India, where E2EE communication with iPhone users is still a nice addition.
WhatsApp is installed on >80% of phone in india.
This is great in principle. I still prefer Signal as the top-shelf experience of iOS—Android communication.
When an iPhone sends a message to 555-1212, where does the iPhone get the public key for that number?
Apple runs servers for managing iMessage key exchange, just like Google’s RCS encryption. Both of them use device attestation to restrict access to those servers to their own apps.
iMessage has nothing to do with RCS, though. I'm also curious how key exchanges will work across operating systems on the latter.
Yes, but it seems unlikely that they wouldn’t reuse as much of that infrastructure as possible to perform the same function for the same users.
It’s not the same function.
Think about it this way: you create an RCS message and hit send. Apple has to encrypt it now but all they have is a phone number. The phone number might belong to a local carrier or one on the other side of the planet. They need the public key associated with that number, right? Who has that? How do they get it? Who owns and manages that infrastructure?
That’s the same problem they have with iMessage: you can watch this the first time you use a new number and it displays green at first but switches to blue once it retrieves the other party’s key. That happens by connecting to Apple’s servers, which seems likely to be the same thing they’d do for RCS.
Another function which is the same: you connect to the server to register your device to your account. It uses hardware attestation to verify that the hardware is what it claims, trying to make spammers have to buy physical devices and to prevent spoofing.
Their infrastructure is iMessage protocol specific, though, and that's incompatible with whatever Google does for RCS.
So either somebody has to build some new service bridging the gap, or RCS encryption is "serverless" in the way that e.g. OTR was, but unlike Signal (which needs explicit server support for managing pre-keys to bootstrap new connections while the recipient is offline, for example).
Some of their infrastructure is iMessage specific but things like account management, abuse mitigation, and device verification should have plenty of opportunities for reuse.
Does anybody know how the trust model for this looks like? Is it trust on first use together with a notification if a contact's key changes, a centralized key server (if so, who runs it, and is there key transparency), or just opportunistic encryption not protected against active attackers in the middle?
It's using MLS for encryption and key exchange, which is based in part in Signal's encryption.
I believe they'll probably be using TOFU like all the other popular encrypted messenger apps. Google's messenger (the encryption of which already uses MLS) has a verification feature where you can match key fingerprints by comparing numbers, but who knows how Apple will implement this.
Still waiting on a non-Google implementation of this so-called standard.
There have been dozens, called anything from Message+ to Joyn. Most seem to be shutting down, though, because nobody used RCS since its inception from somewhere around 2009 and renewed interest in launching RCS services around 2012.
There are a few implementations on Github. https://github.com/android-rcs/rcsjta seems to be the most complete but uses an older version of the spec. https://github.com/Hirohumi/rust-rcs-client is a modern implementation.
The spec is here: https://www.gsma.com/solutions-and-impact/technologies/netwo... if you're looking to implement it yourself.
I think Google‘s was something different. This is an actual standard that Apple is committing to implement. I was under the impression Google’s encryption was just their own layer thing they added on top it was not actually standardized.
When people asked last year about why Apple wasn’t implementing encrypted RCS I think they even said that they wanted to wait for a standard.
So an important context here is the server side implementation of RCS is Google's at every major carrier. Google bought the carrier-side provider of RCS services, Jibe, and so the entire RCS stack is still basically just Google Chat with an "it's a standard" label on it.
https://9to5google.com/2024/02/01/verizon-rcs-google-jibe/
Verizon, AT&T, and T-Mobile all use Google's RCS implementation, the only way to not send Google your messages in the US is to own an iPhone and disable RCS.
> Verizon, AT&T, and T-Mobile all use Google's RCS implementation, the only way to not send Google your messages in the US is to own an iPhone and disable RCS.
You can disable RCS on Android too.
>While Apple’s proprietary iMessage system already supported E2EE, this wasn’t extended to RCS messaging because the previous RCS standard didn’t provide cross-platform support. Google Messages also enabled E2EE by default for RCS texts, but only conversations between Google Messages users were E2EE, and not those exchanged with iMessage users or users of other RCS clients on Android.
this dances around, but does not seem to answer, the big question of whether android will get iMessage or not?
Why would it answer it? This is about RCS, not iMessage. No, Android will not get iMessage.
This is a risky clause:
> R5-32-5 An RCS client having E2EE enabled shall implement techniques to detect suspicious messages or conversations.
Potentially, but it’s fine as long as it’s done on the device and only notifies the user. Like ‘This might be spam, are you sure you want to view it’ or ‘This message might contain nudity’ if people care about enabling that kind of filter.
As long as it never will call out to any external server it doesn’t break the security.
Potentially indeed, that's why I said "risky".
It
- depends on how the clients want to implement it (it's not unthinkable that some might choose a "more effective" remote scanning)
- it makes it a lot harder to make a client, although Bayesian filters should be enough
Sounds like the standard wants phone RCS apps to do CSAM scanning as well as general analysis to see if the encrypted messages are about criminal activity. Not great.
Sounds to me like it's doing spam/phishing/virus scans on-device because cloud servers can't.
Is it possible that we'll see non-smartphone devices (eg dumbphones) being able to interop with Apple and Google through the same end-to-end encrypted protocol?
Any news on if/when one will be able to send RCS from a program or device outside the monolith?
Unfortunately, I haven't seen any concrete announcements on opening RCS to external programs or independent devices yet
Never. It is just a fancy MMS in new disguise. Carriers / patent holders will hold to it forever while praising it as the new best thing.
I believe even then only US carriers (the rest of the world has moved on from P2P SMS, and only businesses are really still sending them for SMS-OTP and marketing), and of course Google, as the only party actually invested in it (via their acquisition of Jibe [1]).
[1] https://jibe.google.com/
You can get access to send MMS though. RCS there is no one selling access yet, especially for person to person.
It seems people are, but not anyone with a big name: https://jibe.google.com/partners/messaging-partners/ I'm guessing it's provisioned this way. https://developers.google.com/business-communications/rcs-bu...
EDIT: https://github.com/android-rcs/rcsjta
Yes the Google Business stuff exists for B2C marketing type use cases, but it is a very limited feature set compared to real RCS and cannot be used for regular communications using phone numbers.
I believe GP's objection is to not being able to access RCS from a non-Google-provided app on Android, not access to the RCS network on the backend side.
Either might be useful but I'm actually more interested in the latter because I run a phone service
> We’ve always been committed to providing a secure messaging experience
This is why iMessage is such a great experience on Android. They don't even try.
I’ve been reading about RCS for maybe 10 years now, yet it’s not really available/usable for everyone? It feels like Vaporware at this point.
iOS did boycott RCS for a long time in order to convince US teens to buy iPhones rather than Android phones (due to incompatibilities between iMessage and SMS, which are popular in the US). It worked. I think there was even some leaked internal email which admitted to doing this. The US antitrust agencies ignored it; there were no legal consequences for Apple. I believe Apple finally decided to add RCS support after EU legislators threatened to force their hand.
About a billion people use it every day, but they're concentrated in specific countries. I believe India is a major RCS user for instance.
Like Signal, it works fine, but you need your contacts to also use it. That's easy on Android (Google hosts an RCS server for people whose carriers don't) but carrier dependent on iOS.
RCS video calls and payments seem to be left unimplemented by Google.
iOS and Android both use RCS
iOS as a fallback messaging system since iOS 18, before falling back to SMS
exposing which people are google voice numbers vs actual android devices
Now if only we could get Google to support RCS in Google Voice.
It’s really odd they don’t, I’m incredibly curious why.
Like so many other google products they get it going, maybe polish it a bit here and there, and then everyone wants to work on more prestigious stuff. That's why Google has had something like half a dozen iterations of an instant messaging service.
GV wasn't even an internal product - they bought up Grand Central and for a while the business offering was still branded as GC. But at one point, it was integrated into Hangouts. It's so strange...
They don't support any HD voice codecs, so call quality is shit, the integration with iOS is non-existent, the app doesn't sync in the background so every time you open it you have to wait 5-10s before you can use it...you can't even set a ringtone so you can tell a GV call from a cellular call.
GVoice gets forgotten about, I swear.
There are years between updates and then suddenly for like 6 months it'll get a slew of updates, most of which aren't user-facing. Then back to update silence. It's really odd.
I'm still amazed that google hasn't killed it.
I always wondered if it's still alive only because Larry or Sergey use it every day.
I think it only survives because it's so thoroughly overlooked. Probably nobody working on a new messaging/chat/VoIP/video conference/etc. platform within Google wants to nominate Google Voice as the thing they're replacing or reinventing.
I hope it stays that way. I'm almost certain that the minute management remembers it's there, it will get shut down, at least for non-paid (i.e. GSuite) accounts.
My hunch is that google uses it for something internally or there's some random government agency that uses it so Google can't quite retire it yet.
Or Gvoice is some backbone service that something else uses. Idk, but it has to be used for something for Google to have not killed it yet.
Well... they also need to expand to more than just a few countries. Here in Brazil there's no iPhone RCS support at all.
It's up to the mobile networks to support that (usually by outsourcing it to Google, which I'm not sure they do for free).
It's weird it's taking that long, as RCS on Android have been supported for ages here, I think even before some US carriers.
I first tried RCS in early 2019.
Based on https://en.wikipedia.org/wiki/Rich_Communication_Services, it looks like Claro should support RCS (still branded as "joyn" though, so could be an outdated version of the spec).
I don't think carriers had much of a reason to invest in RCS servers up till recently, because only Android really supported it and that came with a free, third party server. Maybe now carriers will start caring.
By online statistics, Brazil seems to be a WhatsApp country, though, so I don't think many people will be using carrier services for chat. In turn, I don't think carriers will be quick to invest in servers and software to provide RCS to customers very soon.
Still waiting for Google Fi to turn RCS on for iOS users :(
its coming
https://9to5google.com/2025/03/04/google-fi-rcs-ios-18-4/
“Why won’t Apple interoperable with RCS? (Clutches pearls)”
Well well look who is slow to role something out now /s
Of course it’s stupid RCS involves on carriers upgrading, but what do you expect with a carrier standards?
Seeing Apple openly collaborate on an interoperable standard is refreshing
it already is supporting it. I have been already receiving messages on my iphone with RCS written around them
I've disabled RCS. RCS groups are used for spam. Unknown numbers in random countries add me and many other numbers to said groups, send spam and then quit the groups.
And there is no recourse.
Same here. Disabled it on Android. Too bad. I would use it if I could enable it only for selected users.
Or, you know, Bayesian spam filtering, which Google figured out for Gmail in 2007 or so.
[dead]
Announcement discussion from 2023:
Apple announces that RCS support is coming to iPhone next year
https://news.ycombinator.com/item?id=38293082
793 points | 709 comments
To be clear, this is a different announcement. That was just RCS, this is encrypted RCS.
The big difference:
> The GSM Association announced that the latest RCS standard includes E2EE
> While Apple’s proprietary iMessage system already supported E2EE, this wasn’t extended to RCS messaging because the previous RCS standard didn’t provide cross-platform support