[throw0101a]

> At least SMS is a standard where as Google has their own proprietary [RCS] version.

AFAICT, the only thing "proprietary" about Google's RCS client implementation is E2EE: otherwise it's a fairly standard RCS client that can talk to any other RCS client.

I'd be happy if Apple did the same thing with iMessage (app): standard SMS/RCS client when sending to non-iMessage people, and 'fancy' client (blue bubbles) between iMesssage users.

[threeseed]

Glad we can agree it's proprietary.

So the question is if Google was willing to deviate from the standard for encryption what else will they do in the future.

[throw0101a]

> Glad we can agree it's proprietary.

No. If I telnet to tcp/25, do a "EHLO foo", and in addition to:

    250-ENHANCEDSTATUSCODES
    250-PIPELINING
    250-8BITMIME
    250-SIZE 27962030
    250-DSN
    250-ETRN
    250-DELIVERBY
    250 HELP

There is a line:

    250-X-GOOGLE-CRYPTO

Or even:

    250-X-APPLE-CRYPTO

That does not mean that Google (Apple) is running a (completely) proprietary SMTP server. They have a proprietary option/capability, but if my Postfix can send a regular RFC 821 message then they have a non-proprietary base implementation that they have extended.

If I can send SMS messages between iPhones and Androids, then I'm content. If I could send (non-extended) RCS messages between iPhones and Androids, then I'd be content. If either company wants to add 'extra' features between their own clients, go right ahead.

And, using the above analogy, it would be best if there was a "250-STARTTLS" RCS-equivalent that anyone could implement.