[shalmanese]

If I try to send you a message and your phone is off and my phone is off by the time you turn your phone on, where does the message live until you turn your phone back on? It has to live somewhere not controlled by either of us if we don't want unacceptable degradations in usability.

[lewisl9029]

Yes decentralized messaging does come with that as a serious usability penalty. But I'm not calling for all communications to be decentralized.

I'd like to see more viable options in this space for communications that truly need to be confidential, both in terms of content and metadata. Centralized services can only provide the former for as long as the centralized provider has not been compromised, and simply cannot provide the latter at all.

[chatmasta]

can't it just live on the sender's device until the receiver is online? think about sending an iMessage on the subway... "undelivered" doesn't mean that your message is sitting on Apple servers somewhere. it means it's still on your phone and you can try sending it again when you have a better uplink.

[shalmanese]

When you can't reach Apple, it's undelivered. But there's also the case where you can reach Apple but Apple can't reach the recipient. Then, the message sits on Apple's servers until the recipient can be reached.

[Natanael_L]

Encrypted on the server, TextSecure / Signal has solved that already with 3DH + axolotl.

[shalmanese]

Right, but that's not software that runs only on the client. There's still a server sitting in the middle.

iMessage theoretically also does this. The difference is how key exchange is handled, with iMessage preferring a more usable but potentially less secure approach.

[Natanael_L]

The real problem with iMessage is that public keys are unverifiable. The apparent lack of PFS is also a negative. And the iCloud backups in plaintext (although optional).

Signal have none of those particular problems.