[dfajgljsldkjag]

It's unfortunate that RCS is basically a de-facto Google walled garden in most countries. On android you can only use RCS in the Google Messages app and trying to build your own is explicitly blocked. [1] And of course the bonus that rooted devices are banned from RCS. All the propaganda Google spread to get Apple onboard (only with Google's blessing of course, Google could kick apple off if they wanted) was such a big win for them.

As a business I wanted RCS to be a simple upgrade to SMS, but instead they came up with this mess. Businesses using RCS for Business can send messages to anyone, but customers wanting to get in touch with your business can't. They can only reply to a message you sent first. And of course Google is the gatekeeper for anyone to be allowed to use it.

1. https://github.com/microg/GmsCore/issues/2994

[jjtech]

Unfortunately, I think what a lot of people don't know is that RCS actually has "client authenticity verification"[1]... the RCS server has to actively approve any attempts for a client to connect, if it's Android/iOS/etc.

There are no standards for how this should be implemented, Google uses Play Integrity and Apple uses App Attest at the current moment, with explicit proprietary support by the Jibe servers.

It's basically impossible for any solution that Google doesn't approve to function, because it's never going to be able to get App Attest/Play Integrity verification without relying on a jailbreak/vulnerability.

1. https://www.gsma.com/solutions-and-impact/technologies/netwo...

[jjtech]

As an aside, the IMS stack used to implement SMS/MMS/RCS on Android is super cursed. A lot of the heavy lifting is handed off to the OEM, for example, Pixel devices hand it off to the Qualcomm modem. (Meaning Android the OS doesn't even have any control over how the raw SIP messages are sent: they're inside an IPSec tunnel set up by the modem that it can't see inside)

iirc Samsung devices do it differently and they implement it in userspace using StrongSwan?

That's why it's super annoying to handle SMS/MMS using the standard/legacy APIs, because depending on what device the user has, the implementation may behave radically differently with regards to PDU parsing and such.

RCS makes the whole situation worse because it sets up an entire secondary IMS stack inside the Google Messages app, and then uses weird APIs to try to tie it back into the main stack, even though obviously the modem implementation doesn't understand RCS... it's a mess.

[joecool1029]

> Pixel devices hand it off to the Qualcomm modem.

Older ones maybe, newer ones use Samsung Shannon modems.

> iirc Samsung devices do it differently and they implement it in userspace using StrongSwan?

Just to be cursed the entire IMS stack for Samsung on both qcom and exynos is custom. It’s why no custom roms have support for voLTE on their devices. They also had their own RCS that they sunset in favor of Google Messages.

Apple’s implementation is cursed too and not only did they use an older specification but they didn’t fully implement required responses to registration issues, I wrote about it here: https://wt.gd/working-rcs-messaging

[notRobot]

> never going to be able to get App Attest/Play Integrity verification without relying on a jailbreak/vulnerability.

Even with jailbreak/rooting, hardware attestation is nearly impossible to spoof.

[jeroenhd]

> trying to build your own is explicitly blocked

Google doesn't offer an RCS API, but making your own API is not blocked, especially not on phones running MicroG.

For standard ROMs, RCS apps are not feasible because carriers expect interaction with the SIM module, and only privileged apps can do that. Google Messages blocks root access (probably because the RCS spec says they have to if they ever implement the money exchange feature for RCS) but that just locks out Google Messages.

LineageOS, GrapheneOS, /e/, and all the others could build their own RCS client. They may not be able to register with Google, but they can make an RCS app nonetheless. Rooted devices can also promote third party RCS apps to gain system permissions, so they would be able to use the same RCS apps. Thing is, like all telco protocols, RCS is a long spec with a billion features and acronyms made up of acronyms of even more acronyms, plus you can't easily set up your own server (though in theory a sister project for an open RCS server might be useful for the open 5G project).

I get why people want Google to just stuff their RCS library into open source Android the same way they do SMS/MMS, but to say it's impossible to write a client for, especially when running at the permission level MicroG runs at, is not the whole truth.

As for the whole "Google is the gatekeeper" thing: there are more RCS-for-business providers out there. Google's is probably the easiest to use by far, but Twilio has RCS too, as well as smaller companies such as LINK Mobility and Esendex. Sure, the people whose carriers don't support RCS might receive these business messages through Google's servers, but there's no need to pay Google a dime to make use of the RCS for Business specs.

[dfajgljsldkjag]

> They may not be able to register with Google, but they can make an RCS app nonetheless.

They can make a "standards compliant" RCS which will be able to connect to literally zero carriers or servers on the planet.

In fact Google Messages "RCS" doesn't even implement the RCS standard. They use a proprietary protobuf api exclusive to Google. Google messages can't connect to any "RCS" servers except Google's.

> Twilio has RCS too

Twilio, Bandwidth etc. are gatekept by Google and are basically just a middleman reselling Google's product.

[joecool1029]

> Bandwidth

Still find it endlessly amusing that they run Google Voice for Google and it still doesn’t support RCS.

[jeroenhd]

> They can make a "standards compliant" RCS which will be able to connect to literally zero carriers or servers on the planet.

I call bullshit. If iPhones can connect to RCS, so can other phones.

Their app does use a weird protobuf spec of their own design, but that's for synchronising messages across devices/their web UI. RCS doesn't really do multi-device the same way iMessage does so they had to add another layer. That's not part of RCS.

[hocuspocus]

The iOS client sends an app attestation token during registration.

Jibe could let any compliant client connect doesn't mean it does in practice. Case in point: Harmony OS.

[cyberax]

> LineageOS, GrapheneOS, /e/, and all the others could build their own RCS client

And it will be useless. They likely won't be able to connect to their mobile network's RCS or to Google's RCS. A user with an official Android phone will be able to reach you only over regular SMS.

The way RCS works, the mobile _operator_ uses your corresponder's phone number to look up their RCS server. So that's also why RCS connectivity is so patchy, not all cell phone operators peer with each other.

> I get why people want Google to just stuff their RCS library into open source Android the same way they do SMS/MMS, but to say it's impossible to write a client for, especially when running at the permission level MicroG runs at, is not the whole truth.

It is. The Google's RCS endpoint requires attestation that is available through Play API only.

My personal advice is to avoid RCS at all costs, and use something that is not infested by mobile phone operators or Apple.

[jeroenhd]

> They likely won't be able to connect to their mobile network's RCS

And why is that? Assuming your carrier bothers to run RCS, the protocol works just like MMS and SMS do. If your operator doesn't peer with other operators then you'll have the same issues getting any kind of multimedia delivered from phone to phone.

> It is. The Google's RCS endpoint requires attestation that is available through Play API only.

Annoying, though hardly unexpected at this point. Still, that only poses a problem for Google's RCS servers, not for RCS itself.

[jjtech]

> Assuming your carrier bothers to run RCS, the protocol works just like MMS and SMS do. If your operator doesn't peer with other operators then you'll have the same issues getting any kind of multimedia delivered from phone to phone.

Except, SMS/MMS can be implemented by any standard IMS stack and it will function on any carrier (in theory, ignoring implementation bugs/incompatibility);

RCS has an explicit provision in the standard for "client authenticity" checks which in practice means App Attest/Play Integrity signatures.

(see also: my comment above)

[cyberax]

> And why is that? Assuming your carrier bothers to run RCS, the protocol works just like MMS and SMS do.

Correct. And it took more than a decade to get MMSC interoperability. It's still not perfect even now.

And mobile network operators were incentivized to enable MMSC peering because it was typically a pay-per-message service with hefty fees.

> Annoying, though hardly unexpected at this point. Still, that only poses a problem for Google's RCS servers, not for RCS itself.

That's a distinction without difference in the US.

[jeroenhd]

> And it took more than a decade to get MMSC interoperability. It's still not perfect even now.

That's an understatement, my carrier has disabled MMS years ago. Still, that's not an issue with the MMS protocol, just an issue with carriers.

> That's a distinction without difference in the US.

The American carriers including Jibe in their network still speak RCS to clients. Google's Jibe is the most prevalent remaining RCS server but carrier Jibe isn't using the proprietary protocol that Google Messages uses (otherwise it wouldn't work on iPhones).

Looking at https://support.apple.com/en-us/108048, https://support.apple.com/en-us/118609, and https://support.apple.com/en-us/109526, carrier-based RCS is available in quite a few places. Nowhere near as prevalent as SMS/MMS hubs once were, but that has to do with the fact that in many countries SMS and MMS have been replaced by third-party apps over a decade ago.

[cyberax]

> That's an understatement, my carrier has disabled MMS years ago. Still, that's not an issue with the MMS protocol, just an issue with carriers.

If a protocol requires something specific from carriers, then it's an issue with the protocol.

> The American carriers including Jibe in their network still speak RCS to clients.

Sure, and? It's still useless for me because it can't be used without Google Play.

[hocuspocus]

US and about 180 other countries too.

RCS networks outside Jibe:

- China

- South Korea

- Japan with +Message, on its way out for Jibe

- Jio in India (very strange case as Android subscribers can use Google Messages on Jibe)

[hocuspocus]

Global RCS == Jibe.

Google killed off all interconnected hubs.

[hocuspocus]

> LineageOS, GrapheneOS, /e/, and all the others could build their own RCS client. They may not be able to register with Google, but they can make an RCS app nonetheless.

Building a spec compliant RCS client for the love of the game, I guess.

> but there's no need to pay Google a dime to make use of the RCS for Business specs.

Assuming we're talking of global RCS and not domestic deployments (China and Korea mostly) you pay Google indirectly in all cases as Jibe is monetized via A2P revenue share.

[navigate8310]

> Businesses using RCS for Business can send messages to anyone, but customers wanting to get in touch with your business can't.

Basically for blasting spam and ads, which RCS is already notorious for.

[tadfisher]

Ironically this is because of federation; if your carrier just uses Jibe (e.g. if you live in the US) then you don't deal with spam because Google has effective tools and a profit motive.

Also ironic: Google spent a decade forcing the world's carriers onto the worst messaging standard, only to end up where they started with Google Talk and XMPP; they are the only ones with significant market share on the protocol.

[rkrueger11]

> customers wanting to get in touch with your business can't Not technically true, though it can be more difficult. It's similar to how Apple Messages for Business works where you have to be given a URL (or QR code) to start a conversation with a business using RCS.

[sitzkrieg]

to your point i had problems with RCS in an entire organization because you must allow *.goog for rcs to work correctly