The carriers (full members of GSMA) came up with RCS as a replacement for SMS/MMS at a network level and then didn't have the appetite to implement it.
Instead, they either A) adopted Google’s Messages as is, B) adopted Google’s Messages in white label form, slapping their logo on it, or C) made “their own thing” running on Google’s Jibe servers.
With very few exceptions, it all goes through Google. And Google uses this to pretend that their proprietary iMessage competitor is “the” RCS standard.
The actual RCS standard is dead for all intents and purposes because nobody uses it like that, except for Apple in the short term.
Apple adopting RCS means that there is another player to balance this field. A much-needed player, and the only one that's relevant (other than maybe WeChat and WhatsApp)-
> With very few exceptions, it all goes through Google.
Yeah, because the mobile end-device for RCS is currently always an Android device. If there would be support from Apple, an RCS-server of Apple could handle the communication to Apple-Devices.
The idea of every carrier owning his own RCS-server was anyway already dead before the first client was released. The number of carriers never increased after the initial rollout of the major working-group members, simply because there is no way to charge for the service and monetization of such a small userbase with other services was not sustainable.
It's worth to put this into time-context here: When work on RCS (or "RCS-e") was initiated, WhatsApp was already well-established and leading the European market.
Clarification - many of the carriers are using Google-hosted RCS servers as well. I don't think Apple especially likes the idea of iPhone user metadata (and message contents) going through Google-hosted chat servers every time they message an Android user.
> If there would be support from Apple, an RCS-server of Apple could handle the communication to Apple-Devices.
The issue there is you need something that authoritatively resolves a phone number as being routable via a particular server, and (ideally) to a public key for encryption.
This is the hard problem for chat services - knowing how to route and how to protect data. If there is a problem, then you have some other party monitoring your communications or even manipulating them.
If the same phone number could be authoritative to either Google or Apple RCS servers, then some other component has to make that call.
Every time an iPhone user sends an SMS or MMS to an Android user, it ends up on an Android phone, which Google could snoop on if they so desired.
And, regardless, if Apple implements Google's E2EE extension to RCS, it doesn't really matter whose servers they go through.
Maybe that will change now that Apple is adding support.
RCS is still standardized and maintained by the GSMA
Yeah. And that version of RCS is prone to wild incompatibilities and still lacks E2EE. The only way carriers have figured out how to interoperate with each other is to adopt Google's server and client.https://www.engadget.com/att-starts-using-googles-jibe-platf...
This is applicable ESPECIALLY to large-scale carriers of US, which are big enough to customize every spec and force their suppliers to adopt it.
The only reason why Google's RCS works better than any attempt before that, is that Google is forced to unify the implementation. It's not their spec, they are part of the RCS working-group like everyone else, but by stepping in they instantly reached a cross-carrier rollout-scale where they can't comply to every custom requirement of ATT, Verizon, Vodafone, T-Mobile unless they all agree to make it part of the standard.
Everyone can make his own app, it's just that he would need to develop a whole RCS-client for it to interact with (Google's or carriers') RCS-Servers as well. So what is missing is Google offering their RCS-client with open API's for other apps (than Google Messages) to use.
To be fair, maintaining interoperability of those apps with the underlying client would then be a huge endeavour, Google Messages itself is already updating quite frequently...