> And you can't even implement it yourself because it requires special permissions on Android
That depends on your carrier, which is even worse. There are several ways to activate RCS for a phone number, as this standard is meant for carriers rather than app developers, and the carrier gets to choose which one they want.
I think the reference implementation died around the time carriers shut down their RCS servers because nobody was using them. https://github.com/Hirohumi/rust-rcs-client seems to be the most reason open RCS client at the moment (with an Android demo app).
The real need and opportunity for an RCS messenger is on the LineageOS/custom ROM scene, where these permissions are available (you can sign the ROM yourself, after all).
As for the Google stuff, RCS being routed through Google is an anomaly that will hopefully be fixed as carriers add support to it so native Android <-> iOS messaging isn't completely terrible. Progress has been slow outside of countries that still use SMS (like the USA) but eventually we'll be back to normal carrier-based carrier message exchange once things calm down a bit.
On the Android side of things, I don't expect things to change soon, as most of the restricted fields were at one point available to developers and were mostly used to stalk users across installs without their knowledge for tracking and "telemetry" purposes. A country where people actually use SMS/RCS will have to crack down on Google's lack of an RCS API.
The problem with all these problems is that it makes RCS noticeably worse in both normal use and for your privacy than a regular web chat via some other system. And I do not see a path for it that escapes that.
I'm very happy that they're essentially using MLS, that's a real benefit[1]. But other chat apps can (and some do) do that too, without actively driving every single carrier globally to give Google all of your messaging activity. We're better off having diversity.
This all could reverse course and become acceptable, but I don't see how it would happen in practice. It seems much more likely that everyone will just give up and say "yeah that didn't work".
1: Though without alternate impls they can just silently MITM it and how would you know? RCS users: have you ever verified your messaging keys out of band? Do you know how? I can't find it in Messages. The "Universal Profile https://www.gsma.com/solutions-and-impact/technologies/netwo..." for RCS that describes a ton of things compliant apps have to do (many of which Google Messages does not seem to do, as far as I can tell) has no instructions at all to show users their keys or provide a common way to verify them (as far as I can tell). Client diversity provides a way to detect some attacks here, but there is currently almost no client diversity, and instead it seems to be shrinking towards just Google Messages, using Google's servers.
^ They are correct, the MLS / E2EE part of RCS is quite new and not yet implemented ~anywhere. So it gets no points until widespread, and this is now a decade after RCS's introduction. I think we can expect it to take a long time yet, if at all.
> eventually we'll be back to normal carrier-based carrier message
Why would you want to go into this closed model, where you’ll likely be charged per-account? How is this any better than XMPP, email, or any other IM protocol out there?
> generally included in the plan you pay anyway for data access.
Er, what? The main reason why most of the world moved from SMS to internet-based messaging is because SMS was far more expensive.
> having it for emergencies is nice
In what kind of emergency could SMS be useful?
> just to bootstrap an alternative, secure channel.
But you need to exchange SMS numbers to do that. You might just as well exchange emails, XMPP, or whatever other protocol your going to use later and skip SMS entirely.
Because SMS is horribly limited. 140 chars per message* (less if chars are not plain vanilla ASCII), no support for attachments, group messages, reliable delivery receipts, emoji reactions, etc etc.
* There's a terrible hack called concatenated SMS that strings together multiple messages to build one longer message under the hood, but if any of those parts go missing along the way, the whole thing gets dropped on the floor.
For the proposed use case, you don't need those things, except maybe the 140 character thing, but I've never found that limiting, since phones stitch them together nowadays (and have for the past 15 years?).
Sure, RCS has those functions, but half of them are broken 60% of the time, and you don't need those anyway for bootstraping into wherever you actually want to talk, and for short messaging.
RCS brings nothing to the table if all you need is to tell mum she needs to come pick you up. On the contrary, it might fail you because it tried and failed to send that message over a 4G connection you barely have, rather than sending it as an SMS and then actually arriving. And you're never going to use it for group messages, attachments or with emojis unless its an actual service you intend to use for serious purposes, which is exactly what the comment I was responding to said you weren't going to use RCS for anyway.
I disabled RCS (and iMessage back when I had an iPhone) for exactly these reasons, but still use SMS as a fallback with people I don't actually know and never intend to talk to again, and see no reason to upgrade to RCS even if it wasn't broken, since for my use cases, the extra feature set isn't needed. If I need more fancy features, its for use with people I actually know, and thus people I can get in touch with on not-SMS.
Mostly because my understanding is that RCS is meant to be a drop-in replacement for SMS and if you’re on a device that supports it (or your carrier-specific configuration of RCS) you don’t actually have a choice and your “SMS” is actually RCS and you must use it and hope it works.
Given that there's a 'Disable RCS' toggle (and a 'Resend as SMS' toggle for that matter) that seems to re-enable SMS and eliminate the RCS weirdness, this doesn't really seem to be true. I guess it could be in the future when carriers disable whatever path SMSes are currently going through, leaving you only with RCS that might still be borked.
I'm not entirely sure what you're claiming here, but broadly speaking no, this is not correct.
RCS is, by spec and in practice, intended to fall back to sms/mms if it doesn't work for some reason (e.g. you're roaming and not connected to your carrier. or have opted out. or they're having an outage. or...).
And there's an opt-out (partly because it kinda requires syncing your contacts to the RCS servers... technically only for "online presence" and for any individual you contact to check their RCS status (which is completely reasonable) but do you know where that presence toggle is in Google Messages? I don't).
The fallback is not really automatic or anything, RCS's feature-set is gigantic and allows senders to have far more control over the message's presentation (https://developers.google.com/business-communications/rcs-bu... currently has visual examples of this). It's rather clearly a "built for businesses" system, at least in part. But "RCS might not be available" is very much a core expectation for the stacks as a whole - the world is a big place, and there are many old phones and out of date apps, even if every carrier gets on board. (this is very likely one of the reasons why everyone's just piling into Google's stuff)
If they ever get things working, they might try to force it everywhere, but that's probably like a decade or three away at a minimum. Accurately predicting industry and legal trends on that kind of horizon is basically impossible. They might be planning on it (I have no evidence either way), but achieving is an entirely different matter.
That depends on your carrier, which is even worse. There are several ways to activate RCS for a phone number, as this standard is meant for carriers rather than app developers, and the carrier gets to choose which one they want.
I think the reference implementation died around the time carriers shut down their RCS servers because nobody was using them. https://github.com/Hirohumi/rust-rcs-client seems to be the most reason open RCS client at the moment (with an Android demo app).
The real need and opportunity for an RCS messenger is on the LineageOS/custom ROM scene, where these permissions are available (you can sign the ROM yourself, after all).
As for the Google stuff, RCS being routed through Google is an anomaly that will hopefully be fixed as carriers add support to it so native Android <-> iOS messaging isn't completely terrible. Progress has been slow outside of countries that still use SMS (like the USA) but eventually we'll be back to normal carrier-based carrier message exchange once things calm down a bit.
On the Android side of things, I don't expect things to change soon, as most of the restricted fields were at one point available to developers and were mostly used to stalk users across installs without their knowledge for tracking and "telemetry" purposes. A country where people actually use SMS/RCS will have to crack down on Google's lack of an RCS API.