Is RCS an open standard? I’ve seen some people say it is and others it isn’t and now I’m very confused. Can you please give me a definitive answer?
Is RCS an open standard? I’ve seen some people say it is and others it isn’t and now I’m very confused. Can you please give me a definitive answer?
The confusion stems from the fact there no APIs in Android that let apps use RCS. Only Google can use it on Android and no other apps can use it. Anyone can make an SMS app. Only Google can make an RCS app.
It is an open standard, meaning you are free to create your own operating system for phones that implements RCS. But Google doesn’t let you use it on Android, so in practice it’s closed.
That seems incredibly dumb and backwards. I guess doing it this way helps them expedite its death like all their other products lol
I was about to say the dumb and backwards part was not having basic stuff like encryption in the standard. 🤷
It would also let them claim that its an open standard that anyone can use and they’re contributing to open source, even if no-one could effectively use it in the same way that they implemented it.
It’s XMPP all over again.
This seems to imply that you need a fork of Android, if you’re to build a messaging app that uses RCS.
But my understanding is what you really need is essentially an RCS server.
Doesn’t Samsung messages use it too?
IIRC Samsung has partnered with Google and uses Google’s relay.
It’s disappointing it takes a partnership.
Google is the exclusive RCS provider for all carriers in the US and many other countries. The desire for an AOSP android API is for developers to be able to write clients the way they do SMS clients, not to replace Google’s servers—that’s a pipe dream. IIRC, Google actually helped Samsung develop RCS support in their app. I’m not sure why it’s so difficult to implement.
To add to this, even if it were really fully open, like, say, Lemmy is, because it requires servers there’s the issue of being allowed on someone else’s server and whether servers are modified, and whether server owners want to interoperate and so on.
In some ways the RCS debacle has been similar to the Fediverse debacle about federating with Threads, or with undesirable servers. Even if the protocols are open there can still be bad actors.
Matrix is the federated messaging network. It’s also end to end encrypted, although people have pointed out issues with server security and with metadata—which is why they’re working on peer to peer tech.
RCS is not similar to any federated technology at all. It’s operated exclusively by Google in the US and most other countries. The technology was created, from the ground up, for carriers. But even carriers couldn’t actually make it work in practice, so they asked Google to take over. It’s a fucking albatross. We, as a society, need to drop it.
Most of RCS can be (and has been) implemented by alternative apps, actually. Several carriers have made their own RCS apps for use with their RCS servers, because phones didn’t have support. There are issues (the lack of notification signalling, for one) but they can be worked around. There was a library for this, but it got abandoned years ago and won’t work well with modern RCS users.
What’s keeping most people from developing these apps is that the standard is quite large, and that a phone number can only be registered with one server, which usually means “Google’s server”. Install an RCS app and the Google Messages app breaks, uninstall the app and Google Messages won’t magically have the keys to decrypt your messages or even receive messages in the first place.
People want Google Messages to just expose an API like they did on SMS and MMS because implementing RCS would be a massive pain. There’s some partial support, but only for reading and not for every type of message. If Google’s messenger would just expose an API, everyone could use the normal system API and you wouldn’t run into issues like “after deleting Signal nobody can text me anymore”.
Then there’s the issue that most carriers don’t bother implementing an RCS server, so most RCS users are actually on Google’s server. Authenticating with RCS servers is complex enough, but adding a non-carrier to the mix with its own weird RCS extensions only makes things worse.
Google’s weird protocol extensions are somewhere between “Google doesn’t publish any details” and “basically Signal+MLS packed in a base64 blob”. After implementing RCS, I don’t think implementing encryption would be that much of a challenge, but it would involve some reverse engineering which really shouldn’t be necessary.
So what, if RCS becomes the standard I’m going to lose the ability to choose what messaging app I use? I very much don’t like that.
Yes and no.
You don’t need to make your own OS, but you do need to implement support for the RCS protocol within your app, rather than piggyback on Googles APIs.
I don’t like it, but there’s no legal requirement for google to provide those APIs, like they did with SMS etc.
That’s fair but that also means their “RCS” is really just a name they slapped on their latest proprietary messaging platform.
We know they’ve been trying to get ahead in the messenger game for many years, now maybe they figured if they use the RCS angle it might get some traction.
Or maybe I’m completely off, who knows. Google’s approach to messaging has always baffled me. They could have had a ton of traction and market share by now if they’d have just stuck with one. Why they keep tearing them down and building another one, and why they think this latest one will do any better, I have no idea.
You can interoperate with googles RCS.
If you are willing and able to enter a partnership like Samsung, you can do it fully (including encryption support etc).
Google are determined to not make it easy, and I agree with you, it appears to be yet another messaging land grab.
Trying to put myself in their headspace for a moment, one justification for making it hard is to stop thousands of apps coming out declaring “full RCS support!” through the APIs, then screwing the pooch (through poor security or deliberate back doors or or or).
Right now Google are desperately attempting to make RCS happen, after almost a decade of trying and failing to make various carriers play ball.
They do not want any bad press about how feature poor/insecure/slow/buggy it is right now.
Samsung can interoperate. We cannot. We cannot enter into partnerships with Google. We are people, Samsung is a massive corporation. You understand the difference, right? Google will not let us access their servers. They’re not making it difficult, they’re not making it possible at all.
https://github.com/Hirohumi/rust-rcs-client
Someone has written an open source RCS client prototype, but it has been only tested in China, where carriers do provide their own RCS servers as they are supposed. The author has not tested it with Google’s servers, which are probably blocked in China.
If you want to use SIM card based authentication, you need to have the app installed as a system app. That however is not an option for Google’s servers anyway, since they need to be able to work without carrier co-operation. Google uses SMS based authentication instead.
There does not necessarily need to be anything in Google’s servers that would reject non-Google RCS implementations: the SMS based authentication is defined in the spec, too.
Personally, I would not want the Google’s proprietary implementation to serve an API, but there to be a fully open source client instead.
you don’t just need to support the protocol, you need a server to communicate with your client, and Google is not here to federate its RCS service with Bob’s summer Github project.