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.
Plus, Google's implementation of RCS adds extra features (like encryption) that aren't part of the standard. So even if you create your own operating system that implements RCS, it will still be incompatible. So that's another reason it's not really open.
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.
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.
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.
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.
There is an RCS test app, we could theoretically modify that, but I guess nobody has for some reason. I don't particularly want people to use it, Matrix makes so much more sense.
It is an open standard. The end-to-end encryption is not an open standard, nor are the stickers, those are both proprietary to Google Messages but the rest is open.
Yes it is, it's been developed by the GSM Association, but Google does have de facto monopoly in the market right now by their Jio Jibe virtual carrier. RCS can be freely implemented by carriers and device manufacturers independently of that, but so far only Samsung, T-Mobile USA and Verizon did so — everyone else uses Google's Messages. Importantly, different RCS implementations can talk to each other, just like email servers, or Lemmy instances.
Apple has been encouraged to enable RCS compatibility in iMessage in a loud campaign by Google, but they are obviously not very eager to do that, as their own research shows the closedness of Apple ecosystem and messaging system is a main driving factor of sales. This has been revealed in the Apple vs Epic Games case hearings
It's kind of open. It's pretty much open for carriers to implement on the server side, and for OEMs to develop on the client side. There is an open source client in AOSP's RCS Test App, but for one reason or another, as far as I know nobody's attempted to implement it in an actual usable client app. I don't believe there's a server reference implementation. And, in the US, all the carriers' RCS services are run exclusively by Google, so there's no real point in attempting to set up your own server. Apple might be able to navigate the politics with carriers and with Google to make something work, if it wants to, but it's really not a standard for us to play with.
It may be open as concerns specs, but in most countries you'll pay much for using provider services instead of internet.
On the other hand it's closed, because no one except big mobile comms can offer this service. It's better to avoid it. The only way to have free communication standards is to use the good old internet instead of the infrastructure of the provider.