7 ms·

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 fro

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.

inglor 6y ago
For multiple reasons but first of all because it would require both devices to be connected and online. 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.
raspyberr 6y ago
P2P requires both clients to be running at the same time in order to communicate. If you friend's phone is off and you send a message, they won't get it when they turn their phone on.
- myself248 6y ago
  Seems to me like there should be a DHT way to solve this. When you boot up, you take your place in the table and query your neighbors for messages. If someone's unreachable when a message is sent, you hand the message to their neighbors to hold it until they appear.
  - untog 6y ago
    Which requires you to trust your neighbours. To which you might say: aha! Just use end to end encryption! And sure, you can. But at that point, what benefits are you getting over using E2E with a centralised system? Very few. And you’re getting a bunch of drawbacks in terms of reliability too.
    - myself248 6y ago
      I dunno, a centralized server means a centralized off-switch, that's a pretty huge drawback in terms of reliability.
      - afiori 6y ago
        which is why centralized/peer-to-peer is a false dichotomy the solution to many of the problems of both of them is (forkable) federated networks
    - maqp 6y ago
      E2EE only protects content. Metadata is also very important and where as p2p apps like Briar, Ricochet, Cwtch and TFC hide it from all, centralized and decentralized apps have one or more weak points that allow eavesdropping on larger amounts of metadata.
- userbinator 6y ago
  Depending on whether you expect IM to work like physical mail or a phone call, this may be the expected behaviour. 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.
crazygringo 6y ago
Because: 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
- IgorPartola 6y ago
  In before someone suggests storing encrypted messages in a public blockchain. This is a really good overview of the challenges with these messaging systems. Store and forward has been our MO since email and Usenet were invented because always on always connected devices that aren’t restricted by some network obstacle are not really feasible or even desirable most of the time. I do wonder what alternatives we have to something like a trusted online service to store and forward messages or a public blockchain. Some kind of crypto based system where nobody but the owner of a private key can even locate the message? A decentralized system where multiple copies of multiple fragments of your message are stored so nobody can piece together your (encrypted) message without controlling the majority of the nodes?
  - raspyberr 6y ago
    Do you have an opinion on Skype like centralised coordinator that then sets up P2P connections?
    - IgorPartola 6y ago
      This really isn’t my field, I am more of a full stack developer who mostly works on web apps with a heavy interest in networking. So definitely not an authority on the subject. 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.
kyshoc 6y ago
> why aren't most messaging apps peer to peer [...] it's literally the point of messages: sending from one person to another. 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").

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.

inglor 6y ago

For multiple reasons but first of all because it would require both devices to be connected and online. 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.

raspyberr 6y ago

P2P requires both clients to be running at the same time in order to communicate. If you friend's phone is off and you send a message, they won't get it when they turn their phone on.

myself248 6y ago
Seems to me like there should be a DHT way to solve this. When you boot up, you take your place in the table and query your neighbors for messages. If someone's unreachable when a message is sent, you hand the message to their neighbors to hold it until they appear.
- untog 6y ago
  Which requires you to trust your neighbours. To which you might say: aha! Just use end to end encryption! And sure, you can. But at that point, what benefits are you getting over using E2E with a centralised system? Very few. And you’re getting a bunch of drawbacks in terms of reliability too.
  - myself248 6y ago
    I dunno, a centralized server means a centralized off-switch, that's a pretty huge drawback in terms of reliability.
    - afiori 6y ago
      which is why centralized/peer-to-peer is a false dichotomy the solution to many of the problems of both of them is (forkable) federated networks
  - maqp 6y ago
    E2EE only protects content. Metadata is also very important and where as p2p apps like Briar, Ricochet, Cwtch and TFC hide it from all, centralized and decentralized apps have one or more weak points that allow eavesdropping on larger amounts of metadata.
userbinator 6y ago
Depending on whether you expect IM to work like physical mail or a phone call, this may be the expected behaviour. 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.

crazygringo 6y ago

Because: 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

IgorPartola 6y ago
In before someone suggests storing encrypted messages in a public blockchain. This is a really good overview of the challenges with these messaging systems. Store and forward has been our MO since email and Usenet were invented because always on always connected devices that aren’t restricted by some network obstacle are not really feasible or even desirable most of the time. I do wonder what alternatives we have to something like a trusted online service to store and forward messages or a public blockchain. Some kind of crypto based system where nobody but the owner of a private key can even locate the message? A decentralized system where multiple copies of multiple fragments of your message are stored so nobody can piece together your (encrypted) message without controlling the majority of the nodes?
- raspyberr 6y ago
  Do you have an opinion on Skype like centralised coordinator that then sets up P2P connections?
  - IgorPartola 6y ago
    This really isn’t my field, I am more of a full stack developer who mostly works on web apps with a heavy interest in networking. So definitely not an authority on the subject. 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.

kyshoc 6y ago

> why aren't most messaging apps peer to peer [...] it's literally the point of messages: sending from one person to another. 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").