Back

@1br0wn As I understand it, this is pretty limited as interoperability goes. You still have to use Apple iMessage or Google Messages.

Compared to the interoperability of XMPP or Matrix, where there is an open protocol and anyone can create a client or run a server, it feels like sending carrier pigeons between two walled gardens.

@tomstoneham @1br0wn Love that metaphor! But hopefully other messsging clients over time will implement E2EE-RCS (maybe even WhatsApp itself?!)

@1br0wn It is the server-side which prevents that, as far as I understand it. Has to be provided by mobile operator or Apple or Google. So gatekeepers all around.

@tomstoneham @1br0wn The way Apple implements it — yes, each telco has to turn it on. Google just bypasses them entirely and Apple *could* use the same mechanism. Or put more pressure on telcos to turn it on. Their choice And the Google route is similarly open to other non-telco/“OTT” services, using purely Internet data transport

@1br0wn Interesting. Google's implementation seems to need a Google account. I can't use it on GrapheneOS (and when I try it with my work Google account I am told RCS has been disabled by my administrator ).

I need to find out more. E.g. if I turn on RCS does that mean my phone is running some kind of server to make it discoverable on the network? Who manages the DNS etc.? If a phone is offline, do incoming messages default to SMS?

Do you know of a good not-too-technical resource?

@tomstoneham @1br0wn I don’t know of a single one My understanding has come together piece by piece… The key issue is that apps can choose to run their own infrastructure purely using the Internet, if they have enough scale (eg Google) or can connect to an Internet-based infrastructure. That means only data transport is needed from the mobile provider. Of course RCS as first envisioned by the telcos in GSMA… requires telco support :) and that is how Apple has (until now) chosen to implement it