Personally, I prefer it over downloading yet another client, dealing with additional credentials, wondering about who can access my messages, and so on and so forth…
And all that just to message the handful of people that I know who use <popular in other country third party app>.
Nobody wants this. Universal access means universal access for spammers. iMessage won over SMS because of cost and spam filtering.
Not nobody.
> iMessage won over SMS because of cost and spam filtering.
Really? I've never used imessage.
Within the scope of messaging network effects, nobody.
> Really?
Yes. iMessage spam is rare and stamped out fast. Open protocols tend to have spam problems the moment they begin scaling.
RCS is exactly what it says on the box: A modern successor to SMS. That does not make it a good modern instant messenger.
No one wants to support it. Even telecoms don't want to support it.
Any chance at all it has something to do with the fact that they've acquired an RCS infrastructure provider that they can sell to telcos?
There are a couple other options of course, but I am not sure they are better:
* Fully federate this, a la Matrix or XMPP. I really wish this was a practical option, but without legislation I doubt any company wants to go willingly in this direction. Even if they did, it'd be difficult to contain spam at scale. It also creates 'first contact' issues; love it or hate it, the general public seem attached to the idea of phone numbers and it seems to work relatively well and unambiguously. It is also the most technically complicated and most brittle and unpredictable for users.
* Phone / OS maker operates it for their devices. You don't seem to want Google running things, so this seems markedly worse than what they have actually done which is give you options (most people can at least choose a carrier, and carriers can choose implementations). It's unclear how operating costs are recouped here, especially for low-end devices. Does this lead to feature stratification? I hope not, but probably. It's a global single point of failure, both from a technical point of view as well as a policy/jurisdiction one (can $country LE subpoena my records because the company operating the service is ${country}an - or perhaps merely operates in $country, for example?). Also unclear how users are 'found', but maybe it's a bit easier than in a fully federated system.
* Phone / OS maker partners operate the service, giving users a few choices. Not really sure why anyone would go in for this, but it's basically the same as if the phone maker operates it.
None of these are great options, but I think the carrier is probably the least-bad one. You have an agreement with them. You have the legal protections offered in your home jurisdiction, with clear jurisdiction over the whole thing. They already have a ton of data on you and access to your traffic. You have a neck to wring if the service doesn't work properly.
They really should have standardized E2EE though, not including it is ridiculous.
(And even Google doesn’t really have any love for RCS, they crawled back to it as a fallback plan with their tail between their legs when their own proprietary lock-in messaging apps didn’t work out. Which makes their attempts to shame Apple into adopting it pretty hilariously disingenuous.)
For what it's worth, they've worked tirelessly to ensure their failure.
To be fair, that wasn't Google's plan, that was the GSMA's plan. GSMA created the RCS spec, failed to get more than a handful of their members to use it, and kind of abandoned it to the wolves. For reasons I don't quite understand, Google decided it'd be a good idea to take it up, and then push it harder than any of their previous messaging services; but it's not like they came up with it.
Google has made some proprietary extensions to RCS to support end to end encryption but this is not the same thing.
RCS is better than SMS no doubt but lets not pretend it is on the same level as iMessage. Lack of end to end encryption alone makes RCS a dated standard
https://www.techradar.com/phones/iphone/breaking-apple-will-...