Now that I think about it, why aren't most messaging apps peer to peer? Shouldn't that be the standard? I mean it's literally the point of messages: sending from one person to another.
a) Often the intended recipient isn't online when the message is sent, and it may happen that there is never a time when both sender and recipient are online simultaneously (e.g. sender's device only turns on to send the occasional message, receiver's device is usually off but turns on occasionally to check if there are messages)
b) Often one or both devices can only connect to, but can't be connected to (because behind a NAT, a mobile device, firewall, etc.)
c) Communication is often desired between accounts rather than devices -- I may want to send/receive on my work computer, home computer, phone, and watch
I think that’s basically the sort of system that most places employ. It’s nice because it’s easy to set up but you really need to trust Skype. Say they actually try to use end to end encryption. How does that work? Well, you could say “I am Alice and I want to establish a connection to Bob. Here is my public key he can use to send me messages and I’d like his public key so I can send him his.” That of course would need to happen in addition to establishing a network connection. So no if Skype is a good actor they will pass my public key to Bob, get his and send it to me as well as coordinate us establishing a direct connection.
But what if Skype is a bad actor? Well they could take my public key and send Bob one of their own. Then they could also send me their own. Now they can listen in on my conversation. They can also in a similar fashion make it seem like I’m connected directly to Bob’s networked device but really just relay the connection through their servers. Neither Bob nor I would have any way of knowing that without having exchanged public keys prior and having verified them. So this system is basically insecure against Skype wanting to listen to my conversations or being compelled to do so by a state actor.
My only big issue is that the iOS client doesn’t support multiple simultaneous identities.
What happens if someone with old Riot client creates a room and someone with e.g. RiotX joins it, will it force E2EE on? Or will it fall back to non-E2EE messaging?
IMO it should be the case that it's always E2EE, no other options. Until that's the case I think Matrix ecosystem isn't keeping up with centralized solutions like Signal.
If there are other applications that can run over the protocol, I'm interested in learning about them.
You could connect to a pub — an automatically-friendly bot account; see a list at https://github.com/ssbc/ssb-server/wiki/Pub-Servers — scuttle.space seems to be active right now.
If you're happy posting your SSB ID publicly, I'll follow you, and that may help. Or you can use the #new-people tag if you want to introduce/announce yourself :)
It's feasible once you reach the point where it's worth the effort of implementing.
Yes, but a sensible router will also firewall all incoming connections unless the port is explicitly opened.
(The current networks are often not set up to handle malicious incoming internet traffic, and new protocol is not going to change this)
Messaging apps are more like postal services — "please deliver this message to $person" — you're describing driving across town to drop something in a mailbox directly. A peer-to-peer messaging system wouldn't have many benefits over an E2E-encrypted one (in a centralized E2E-encrypted service you already enjoy technical guarantees that the courier can't peek inside the metaphorical envelope), but would have several usability drawbacks that would drive away casual users, which the sibling comments mention.
Driving away casual users has its own problems: you might drive them away to insecure services ("ah fuck it, this thing doesn't work, I'll just DM them on Twitter"), and the lack of casual users will make your remaining users stand out in traffic analysis (e.g. state agency says "hmm, askxnakjsn is using SuperEncryptoP2PMessenger, better go make sure they aren't a dissident").
The common alternative to overcome this is to pass the messages through the server and encrypt/decrypt them on the device (aka e2e encryption). I acknowledge that might not be secure enough for certain use cases.
It seems the majority here seem to be expecting the former, although I think of IM as more like the latter: if the recipient is not available, then the message is simply dropped, much like I can't call someone who is not answering the phone.