5 ms·

Disclaimer: ex Skype employee. 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 Skyp

Disclaimer: ex Skype employee. 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. 1. Asking users to enable upnp is a joke. I would never do that, and anyone doing so should consider the security implications of doing so. Unfortunately, since they want to stay pure p2p they have no other possibility to solve the "both clients behind a NAT router" problem. This is why Skype relies on STUN like protocols => not possible in pure p2p. 2. Peer discovery in pure p2p is SLOW. Skype understood that and switched to hosted "supernodes" with their IPs hard-coded in the client. It's the only way to have reliable peers to introduce you to the network. 3. You WANT dedicated peers with good connection and 100% uptime. 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. 5. In case the network collapses, there is no way for it to go up again without supernodes.

eleitl 9y ago
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).
- marksomnian 9y ago
  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.
- Galanwe 9y ago
  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?)
  - Rjevski 9y ago
    You could refrain from becoming a supernode by disabling "Allow direct IP connections" in the Skype settings - but personally I didn't mind.
- mmarx 9y ago
  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.
laumars 9y ago
> 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.
- such_a_casual 9y ago
  Each version works a little less. It's great! God forbid I can find the chatbox, I might use it!
jhasse 9y ago
> 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?
- Galanwe 9y ago
  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.
  - jhasse 9y ago
    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.
    - s73ver 9y ago
      For something that would aim to be used by the general public, that's a huge problem.
k33n 9y ago
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.
- oblio 9y ago
  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-messengers/ http://www.whoishostingthis.com/blog/2014/10/22/instant-mess...
  - Nullabillity 9y ago
    Hardly, today's Skype is more of a rebranded MSN Messenger than the Skype from 14 years ago.
    - oblio 9y ago
      I still use the same account...
Zash 9y ago
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.
the8472 9y ago
> 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
jrs95 9y ago
Couldn't some of this be achieved on sort of volunteer basis, like how you can run an exit node for Tor?
caraboga 9y ago
I've been playing around with this: https://app.zyptonite.com/ 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).
tinus_hn 9y ago
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.

eleitl 9y ago

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

marksomnian 9y ago
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.
Galanwe 9y ago
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?)
- Rjevski 9y ago
  You could refrain from becoming a supernode by disabling "Allow direct IP connections" in the Skype settings - but personally I didn't mind.
mmarx 9y ago
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.

laumars 9y ago

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

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

jhasse 9y ago

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

Galanwe 9y ago
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.
- jhasse 9y ago
  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.
  - s73ver 9y ago
    For something that would aim to be used by the general public, that's a huge problem.

k33n 9y ago

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.

oblio 9y ago
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-messengers/ http://www.whoishostingthis.com/blog/2014/10/22/instant-mess...
- Nullabillity 9y ago
  Hardly, today's Skype is more of a rebranded MSN Messenger than the Skype from 14 years ago.
  - oblio 9y ago
    I still use the same account...

Zash 9y ago

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.

the8472 9y ago

> 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

jrs95 9y ago

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

caraboga 9y ago

I've been playing around with this: https://app.zyptonite.com/ 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).

tinus_hn 9y ago

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.