Sure metadata could be important, but I'd argue it's only useful in identifying who some agency might want to wiretap next. Without the actual content of the ca

Sure metadata could be important, but I'd argue it's only useful in identifying who some agency might want to wiretap next. Without the actual content of the calls you don't know if somebody is talking to a collaborator or ordering in. >Also, "reliability" doesn't make sense as a reason to centralize skype. I've written a P2P app or two. The NAT issues that you handwave are a huge problem. It's not just the connectivity of nodes, it's the symmetry in which nodes are reachable. NAT and general internet weirdness make this a much harder problem than it needs to be. I had to do a significant re-architecting when I ran into these issues during internal testing, and I had less than two dozen users! The next problem is latency. By the time you wait to discover a suitable supernode and for your "hello" message to reach your target peer, you will have already connected and started communicating with your peer if you use a centralized "registry" server. This is compounded by churn. Even if there's a single intermediate hop in your routing, your chances of a successful message delivery drop drastically when a peer can leave anytime. Think about how you use your laptop and how long you keep it running and how abruptly you close it. The move towards laptops away from desktops means average node uptime is reducing sharply, without even considering the move to mobile. This is further compounded by the need for presence for the case of Skype. You don't want to find a peer is unreachable after you start a call. This implies the need for a global state. But without central server, this can only be achieved with DHT, where the first two problems are even worse. Note the existing DHTs are all used for long running "sessions" where the session is the availability of a torrent. User presence is a lot more ephemeral. And there's the original problem for P2P apps, of course: bootstrapping. Peers don't come online knowing all their other peers on the Internet. There has to be a way for them to discover each other, which, without Internet-wide multicast, means a central server. If you're going to have to solve this problem, you might as well solve the others. There is actually a thread on p2p-hackers mailing list about this exact issue. Many experienced P2P devs agreed that whenever you can get away with a centralized solution, you should go for it. In this context, partially centralizing Skype as they did makes complete sense.