[AnthonyMouse]

The issue isn't that Apple should be using SMS in particular -- SMS sucks. But they should either use some standardized protocol, or publish a protocol standard for iMessage.

Someone willing to do the work should be capable of producing an interoperable implementation.

[Jtsummers]

You'll get your wish later this year with iOS support for RCS.

[AnthonyMouse]

Not exactly.

It's a step in the right direction but it's the same problem as iMessage supporting SMS in addition to its own protocol. If the proprietary protocol supports something the open protocol doesn't, or that Apple doesn't implement for the open protocol, a competing implementation can't do it. And if it doesn't do that then why does the proprietary protocol exist?

If you're going to make your own protocol, publish a spec.

[peyton]

Isn’t iMessage a service, not a protocol? Should I be able to operate a business that sends bulk advertisements to iMessage users?

[AnthonyMouse]

> Isn’t iMessage a service, not a protocol?

It's a service and a protocol and a client application.

But it should be possible for a third party to make an interoperating client application using the same protocol, and then it could connect to any service implementing that protocol.

Obviously if you want to be selective in who can use your service then you should create a protocol that supports some kind of federation so that each user's service can forward messages to another service if the two endpoints don't use the same one. Email works like this, for example.

> Should I be able to operate a business that sends bulk advertisements to iMessage users?

Can you do this now by using a Mac with iMessage?

[naravara]

The touchy part is the end-to-end encryption. The whole point is that Apple is the trusted party there. As an iMessage user I don’t want my messages passing through who knows which other parties’ servers when I send messages to others.

The point of the blue bubble is to ensure the encryption is there.

[Sabinus]

If you're an iMessage user, don't you want your messages to non apple users to be encrypted?

Kicking them out of the system makes your messages less secure, not more secure.

[naravara]

Who verifies that the client on the other end of your line isn’t intercepting the messages after they’re decrypted?

[AnthonyMouse]

End-to-end encryption is where the client device encrypts the message and then the other end's client device decrypts the message. It doesn't matter how many servers it goes through, none of them can read it, that's the entire point of end-to-end encryption.

The hard part is associating some identity with the user's keys, but when the ID is your phone number or email address, the entity doing that is inherently your phone company or email provider. You can standardize a way to do that, i.e. to sign up you get an SMS or email with a code and have to enter the code. The client can automate that if it has access to read your SMS or email, or otherwise you enter it manually.

[naravara]

If the person on the other end is using a non-Apple client you cannot verify independently that their client isn’t peeping. It’s the client, not the servers.

But also when it comes to managing the keys and syncing across devices it’s also the servers.