Hacker News Reader

> Looks like a Skype clone from 10 years ago to me. I cannot see this working in the long run. Many people naively think that Skype switched from full p2p to partially p2p to server centric because of some evil plot designed by Microsoft. This is all wrong. Skype abandonned full peer to peer because it does not work if you want something fast, reliable, and feature rich.

Frankly my experience of Skype now is that I long for Skype from 10 years ago. Purely from a user perspective so I cannot comment on improvements to the backend infrastructure, but these days I find Skype takes up more of my machines resources, runs slower and is less reliable than it has ever been.

Each version works a little less. It's great! God forbid I can find the chatbox, I might use it!

> 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.

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

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/ 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.

"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.

> 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.

Not sure I understood it correctly, but don't they want to solve this with a blockchain?

Exactly what I mean. Either you have a central server, or you use some kind of distributed store among the peers, but then every client needs to bring his private key on every device. You cannot check your messages on a friend's computer, on your tablet or whatever.

No, you could also store the private key encrypted with the users password in the blockchain. The only difference to a central server is that you lose the ability to regain access to your account if you lose your pw.

For something that would aim to be used by the general public, that's a huge problem.

10 years ago we didn't have gigabit connections in our homes, and or at our offices. Now that many of us do, P2P is not only viable, but likely better in many cases than supernode based architecture. Ring will likely be around longer than Skype. As long as it is distributed by Linux distros' package managers, it will remain usable. Skype will eventually be shuttered.

While your argument is quite strong, I wouldn't completely dismiss proprietary software such as Skype. Initial Skype release: 2003, so 14 years ago. It has staying power.

Heck, Yahoo messenger (1998, 19 years ago), ICQ (1996, 21 years ago) and even AIM (1997, 20 years ago) are still around. And Skype has higher usage than those did: http://www.whoishostingthis.com/blog/2014/10/22/instant-mess...

Hardly, today's Skype is more of a rebranded MSN Messenger than the Skype from 14 years ago.

I still use the same account...

This is why I really like the federated client-server model. It's a pretty good compromise between centralized and peer-to-peer. Much easier to wrap your head around than p2p, while only a little more complicated than something centralized.

Like FaceTime, Skype abandoned peer to peer connections (via secondary hosts for NAT traversal) because there is a ridiculous patent on that when used for voice or video connections. It worked fine.

The old Fasttrack of Kazaa, which Skype was originally based on, already had static servers for getting the supernode list.

Since the supernodes were just regular customer machines and the system 'borrowed' their bandwidth under the covers it's not a big surprise they switched to hosting them themselves when they switched from illegal file sharing to legal communication. Hosting became cheap anyway.

You can automatically promote real servers with good uplink and public IPs to be supernodes. This eliminates the whole NAT penetration brain damage (going IPv6 is a possible workaround).

In that case, how do you distribute the IPs of supernodes to new clients, other than hardcoding them into the download binary?

Tor has the same problem; it solves it partially by hardcoding directory authorities, and partially with bridges that are distributed offline.

Skype did that, Windows (lol) nodes with good up times and bandwidth were autopromoted as supernodes. This makes the network unfair tho, and encourages these users to use alternatives clients to prevent being a supernode (wasted bandwidth and cpu: who wants this?)

You could refrain from becoming a supernode by disabling "Allow direct IP connections" in the Skype settings - but personally I didn't mind.

That's exactly what got Skype banned on our university's network back when it still used to do that, because otherwise supernode traffic would have taken a significant portion of the uplink bandwdith.

I've been playing around with this:

https://app.zyptonite.com/

The login infrastructure uses a standard auth service, but once that gets going, seems like traffic goes directly from client to client. Avoids the peer discovery but once both (or more) clients know where everyone is, the transport is from client to client (at least it looks that way from tcpdump).

Couldn't some of this be achieved on sort of volunteer basis, like how you can run an exit node for Tor?