4 ms·

> This is why Skype relies on STUN like protocols => not possible in pure p2p. You can have rendezvous servers for holepunching on p2p networks. It doesn't sol

> This is why Skype relies on STUN like protocols => not possible in pure p2p. You can have rendezvous servers for holepunching on p2p networks. It doesn't solve the case of unpunchable NATs, but I think if one is aiming for pure P2P then it would be sufficient to inform the user about it that it is "blocked by the network" or something like that. > 2. Peer discovery in pure p2p is SLOW. I can do random lookups on the bittorrent DHT (6-8M reachable nodes) that yield their first result in 600ms and returned the bulk of the results in 1500ms. Those queries can be run in parallel without significantly impacting latency. The only limit are shoddy NAT devices that have their tracking tables saturated by the traffic. > 4. You cannot efficiently have shared states in pure p2p without an identity server. That would require the clients to bring their keys with them on every device, not very practical. Pair devices over local wifi/bluetooth/scanning QR code from screen to camera? Or generate cryptographic identities in a deterministic way from hashed passphrase? I believe ed25519 keys can be created this way. > 5. In case the network collapses, there is no way for it to go up again without supernodes. You need bootstrap nodes that can be contacted when the client has no local list of reachable contacts, that's not the same as supernodes. > Skype abandonned full peer to peer because it does not work if you want something fast, reliable, and feature rich. Each of those things is a continuum. Yes, certain tradeoffs have to be made if you want a decentralized application. But you're omitting being decentralized and not under control of a single entity as a goal itself.

silotis 9y ago
Bleep, BitTorrent Inc's p2p messaging client, already does a lot of this. It uses the bittorrent DHT for fast peer discovery and does device pairing via QR codes, including p2p state synchronization. We do use a central server for identity lookup based on email/phone number, because squaring Zooko's triangle seemed a bit too ambitious. We also use relay servers to get around NAT so uPnP is typically needed for true p2p operation, but the client still functions just fine without it. The client itself is closed source, but we have open sourced a key portion of the code which deals with the DHT. https://github.com/bittorrent/scout https://github.com/bittorrent/scout
- seanp2k2 9y ago
  The bleep app description says "Bleep is a fun and easy instant messaging app that is completely private." I find it hard to believe that without audited available source code. A quick search turned up this thread: https://forum.bittorrent.com/topic/30924-open-source/ https://forum.bittorrent.com/topic/30924-open-source/ which seems to indicate that back in 2014, it was unclear if it was going to be open source, and it was thought to be a Skype competitor. The current state of affairs seems to be text and images only, marketing it similar to Snapchat with disappearing messages and claims of privacy (but similarly no way to verify this), and it's the second hit in the iOS App Store for "bleep", having less reviews (at 8) than the top hit, "Bleep!", which is a big red button which presumably makes noise when tapped.
s73ver 9y ago
"Each of those things is a continuum. Yes, certain tradeoffs have to be made if you want a decentralized application. But you're omitting being decentralized and not under control of a single entity as a goal itself." Probably because the top goal, above whatever else they want to do, is that it has to work to let people talk to each other, and work reliably.

silotis 9y ago

Bleep, BitTorrent Inc's p2p messaging client, already does a lot of this. It uses the bittorrent DHT for fast peer discovery and does device pairing via QR codes, including p2p state synchronization. We do use a central server for identity lookup based on email/phone number, because squaring Zooko's triangle seemed a bit too ambitious. We also use relay servers to get around NAT so uPnP is typically needed for true p2p operation, but the client still functions just fine without it. The client itself is closed source, but we have open sourced a key portion of the code which deals with the DHT. https://github.com/bittorrent/scout https://github.com/bittorrent/scout

seanp2k2 9y ago
The bleep app description says "Bleep is a fun and easy instant messaging app that is completely private." I find it hard to believe that without audited available source code. A quick search turned up this thread: https://forum.bittorrent.com/topic/30924-open-source/ https://forum.bittorrent.com/topic/30924-open-source/ which seems to indicate that back in 2014, it was unclear if it was going to be open source, and it was thought to be a Skype competitor. The current state of affairs seems to be text and images only, marketing it similar to Snapchat with disappearing messages and claims of privacy (but similarly no way to verify this), and it's the second hit in the iOS App Store for "bleep", having less reviews (at 8) than the top hit, "Bleep!", which is a big red button which presumably makes noise when tapped.

s73ver 9y ago

"Each of those things is a continuum. Yes, certain tradeoffs have to be made if you want a decentralized application. But you're omitting being decentralized and not under control of a single entity as a goal itself." Probably because the top goal, above whatever else they want to do, is that it has to work to let people talk to each other, and work reliably.