Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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.


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.


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.


I dunno, a centralized server means a centralized off-switch, that's a pretty huge drawback in terms of reliability.


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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: