4 ms·

> my verdict is: technical reasons, mostly This conclusion is not really supported by the facts. The failure of decentralized VOIP services to achieve mass ad

> my verdict is: technical reasons, mostly This conclusion is not really supported by the facts. The failure of decentralized VOIP services to achieve mass adoption was not due to technical reasons. Let us remember that SIP was standardized in RFC 2543 in 1999 and had a head start over Skype. The first STUN (Session Traversal Utilities for NAT) RFC 3489 to help solve the NAT traversal problem was published in 2003, the same year as the first release of Skype. There was no technical reason stopping the SIP community from building reliable VOIP clients to compete with Skype. One might object that due to NAT, SIP required most users to use a STUN server. But this is not a technical problem: it is similar to the situation with XMPP, which required users to register and then connect to an XMPP server, yet XMPP is still a decentralized protocol. Besides, decentralized services encompass a lot more than just VOIP. For example, they includes instant messaging, file storage, and social networking. The first Jabber/XMPP protocol RFC was published in 2004, even though the server software had been open sourced since 1999 or so. The decentralized file storage service Tahoe-LAFS was first released in 2007. The micro-blogging service and Twitter-alternative GNU Social was launched in 2008. The Diaspora decentralized Facebook-like social network was launched in 2010. None of these services were able to compete with their commercial counterparts, yet there was nothing technical stopping them from doing so. These services and their spiritual descendants have failed to gain mass adoption because they didn't have the same resources as their centralized commercial counterparts, and so could not offer users a better or comparable product in terms of quality, features, usability, reliability, or even "cool factor". There is a parallel here with the mythical Year of the Linux Desktop, which never seems to arrive.

jonathanstrange 10y ago
> This conclusion is not really supported by the facts. Oh yes, it is. I have to wholeheartedly disagree with almost everything you've said, I'm afraid. STUN requires a centralized outside server. As I said, by now there are better libraries that didn't exist ten years ago, but even they fail often. NATs behave very differently form implementation to implementation, some don't even get UPnP right, and it takes a lot of resources to get p2p reliable without special user interaction (e.g. with their home router) and without any server outside. AFAIK, there not no single library or method that works reliably without a server outside of the NAT. Also don't forget that I was talking about why decentralized p2p didn't take off, so we're talking about a of 1996-2010 not about now. Adoption of technology does not work the way you describe, it works similarly to language change. It doesn't have much to do with resources of companies. Here is how it works in reality: 1.) If there is already an easy to use service that covers the functionality, new ones will likely fail. (Just like possible word compositions are often blocked when there is already a word for sth.) 2.) If end users cannot get it running within a few seconds, the technology will likely fail. (If it is intended for a mass market, I'm not talking about specialized tools or b2b software, of course.) Decentralized p2p failed because of 1.) and 2.), and the reason for 2.) was primarily the lack of a cross-platform, reliable way to punch holes through NATs. All of the examples you give fall under 1.) or 2.) respectively. On the other hand, Bitcoin is a typical example of p2p that satisfies both conditions, and that's why it was successful. But there are are more conditions (though not the ones you suggest). One major factor was also that for an ISP, it's most desirable not to see strange server traffic from their ordinary, non-business end-consumers. So even if you succeed with NAT and complicated network topology issues, ISPs might still mess with the traffic or even block it. In fact, some infamous ISPs even disallowed running servers at any non-standard ports for some time, and used other methods to limit the Internet to passive web consumation for their customers. My ISP in the late 90s, for example, used PPP over ADSL for no technical reason, and switched off the connection once a day for no technical reason other than making it a bit harder to get a continuous server to work. And let's also not forget that most consumers nowadays are behind ADSL, where upload speed is usually limited 10 times less than download speed. That alone makes p2p harder. Again, all mostly technical reasons. By the way, the Linux Desktop is also not successful for mostly technical reasons, contrary to what you claim. First, there is the application barrier maintained by commercial companies - a technical issue that could easily be overcome if besaid companies would work on interoperability standards (they do the opposite, of course). Second, there are numerous issues with usability on Linux that will never be resolved, because they would require everyone in the Linux world to pull on the same string at the same time. But these issues are still technical in the sense that there would be technical solutions to them, if there was some sort of "benevolent Linux dictator" who could force every programmer to use a given API like Apple forces their developers.

jonathanstrange 10y ago

> This conclusion is not really supported by the facts. Oh yes, it is. I have to wholeheartedly disagree with almost everything you've said, I'm afraid. STUN requires a centralized outside server. As I said, by now there are better libraries that didn't exist ten years ago, but even they fail often. NATs behave very differently form implementation to implementation, some don't even get UPnP right, and it takes a lot of resources to get p2p reliable without special user interaction (e.g. with their home router) and without any server outside. AFAIK, there not no single library or method that works reliably without a server outside of the NAT. Also don't forget that I was talking about why decentralized p2p didn't take off, so we're talking about a of 1996-2010 not about now. Adoption of technology does not work the way you describe, it works similarly to language change. It doesn't have much to do with resources of companies. Here is how it works in reality: 1.) If there is already an easy to use service that covers the functionality, new ones will likely fail. (Just like possible word compositions are often blocked when there is already a word for sth.) 2.) If end users cannot get it running within a few seconds, the technology will likely fail. (If it is intended for a mass market, I'm not talking about specialized tools or b2b software, of course.) Decentralized p2p failed because of 1.) and 2.), and the reason for 2.) was primarily the lack of a cross-platform, reliable way to punch holes through NATs. All of the examples you give fall under 1.) or 2.) respectively. On the other hand, Bitcoin is a typical example of p2p that satisfies both conditions, and that's why it was successful. But there are are more conditions (though not the ones you suggest). One major factor was also that for an ISP, it's most desirable not to see strange server traffic from their ordinary, non-business end-consumers. So even if you succeed with NAT and complicated network topology issues, ISPs might still mess with the traffic or even block it. In fact, some infamous ISPs even disallowed running servers at any non-standard ports for some time, and used other methods to limit the Internet to passive web consumation for their customers. My ISP in the late 90s, for example, used PPP over ADSL for no technical reason, and switched off the connection once a day for no technical reason other than making it a bit harder to get a continuous server to work. And let's also not forget that most consumers nowadays are behind ADSL, where upload speed is usually limited 10 times less than download speed. That alone makes p2p harder. Again, all mostly technical reasons. By the way, the Linux Desktop is also not successful for mostly technical reasons, contrary to what you claim. First, there is the application barrier maintained by commercial companies - a technical issue that could easily be overcome if besaid companies would work on interoperability standards (they do the opposite, of course). Second, there are numerous issues with usability on Linux that will never be resolved, because they would require everyone in the Linux world to pull on the same string at the same time. But these issues are still technical in the sense that there would be technical solutions to them, if there was some sort of "benevolent Linux dictator" who could force every programmer to use a given API like Apple forces their developers.