Hacker News Reader

Comment by rickdeckard | Hacker News Reader

RCS is still standardized and maintained by the GSMA, of which Google is a member. Google acquired Jibe in 2015 in order to get their RCS server and client architecture (Jibe was a leader in shaping the RCS-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...

View on HN

The problem is that Google has a de facto monopoly on RCS.

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.

Monopoly is the wrong term here, the root-cause of this situation is that Google is now maintaining the largest OS-implementation of RCS by far, only followed by Samsung, and then some carriers who also use RCS for other platforms (web-apps, STB,...).

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.

> Monopoly is the wrong term here, the root-cause of this situation is that Google is now maintaining the largest OS-implementation of RCS by far, only followed by Samsung, and then some carriers who also use RCS for other platforms (web-apps, STB,...).

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.

> 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.

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.

>The actual RCS standard is dead for all intents and purposes because nobody uses it like that, except for Apple in the short term.

Maybe that will change now that Apple is adding support.

I wonder if Apple might run its own RCS servers

  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...

The only way for carriers to interoperate with each other is by having an intermediary party which limits their freedom of customizing any given specification.

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.

The way it works is ugly for the privacy oriented folks. Turning it off and block by the firewall is a must. Just like "Private" DNS. Both are unfortunately forced.

Reply on news.ycombinator.com