4 ms·

Decentralized services have not been able to compete with their walled garden counterparts due to lack of resources and access to capital, as well as the coordi

Decentralized services have not been able to compete with their walled garden counterparts due to lack of resources and access to capital, as well as the coordination costs of federation. It's a structural and not a technical problem. I can't see how this will ever change. Most decentralized services are open source projects maintained by volunteer developers. They are competing with centralized commercial projects with deep pockets and the ability to hire not only smart developers but also artists, testers, sysadmins, designers, marketers, researchers, and project managers - some of the things you need to deliver a best-in-class service to users. The odds are stacked against the decentralized service from the beginning. Even when these projects attract commercial interest, such as Dat or Ethereum named in the article, it is not clear how their funding will be sustainable given that decentralized platforms are more difficult to monetize than centralized ones. And it's really hard to see Github as a "posterchild" for the decentralized web, since it is really a centralized service.

sukilot 10y ago
It has to use the existing gardens as scaffolding: embrace , extend, extinguish. Your new service has to interoperate/sync with Facebook (using screenscraping or API) in order to access your friends and feed, and then it's up to the users to choose to migrate, edge by edge, to the alternate network.
- deleted 10y ago
  [deleted]
- walterbell 10y ago
  Yes on incremental migration, e.g. the IndieWeb community targets content creators, allowing them to syndicate from decentralized to centralized, so that the content system of record and ownership is under the creator's control.
JohnStrange 10y ago
I don't think so. Decentralized services never took off very much because of tremendous technical difficulties with reliable NAT traversal/hole punching. Companies like Skype spent unbelievable efforts to get around these problems and kept them a closely guarded secret. There are a few more libraries now, but it's still surprisingly difficult to achieve reliable p2p connectivity without some external, centralized server to get the process started. This in combination with a few other problems with ISPs, slow upload speeds and the "intellectual property" watchdogs prevented 1-click installation. Without extremely easy and fast setup that even the dumbest person can manage, no software will achieve wide popularity. Shareware authors have already realized this in the 90s and this hasn't changed since then. So my verdict is: technical reasons, mostly, although I wouldn't exclude the possibility that there were some "dark forces" behind them in some countries. Genuine P2P has always scared the shit out of traditional companies and politicians.
- Arathorn 10y ago
  This isn't entirely true these days - ICE (RFC5245) has been out for 6 years and defines a pretty robust, open and tractable solution for firewall traversal. There are a bunch of libraries and apps out there that use it, including one built into most web browsers as part of WebRTC. If anything the exciting situation we're in currently is because the tech has caught up at last. Firewall traversal is no longer a black art; you just open a WebRTC data connection.
- infodroid 10y ago
  > 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

sukilot 10y ago

It has to use the existing gardens as scaffolding: embrace , extend, extinguish. Your new service has to interoperate/sync with Facebook (using screenscraping or API) in order to access your friends and feed, and then it's up to the users to choose to migrate, edge by edge, to the alternate network.

deleted 10y ago
[deleted]
walterbell 10y ago
Yes on incremental migration, e.g. the IndieWeb community targets content creators, allowing them to syndicate from decentralized to centralized, so that the content system of record and ownership is under the creator's control.

JohnStrange 10y ago

I don't think so. Decentralized services never took off very much because of tremendous technical difficulties with reliable NAT traversal/hole punching. Companies like Skype spent unbelievable efforts to get around these problems and kept them a closely guarded secret. There are a few more libraries now, but it's still surprisingly difficult to achieve reliable p2p connectivity without some external, centralized server to get the process started. This in combination with a few other problems with ISPs, slow upload speeds and the "intellectual property" watchdogs prevented 1-click installation. Without extremely easy and fast setup that even the dumbest person can manage, no software will achieve wide popularity. Shareware authors have already realized this in the 90s and this hasn't changed since then. So my verdict is: technical reasons, mostly, although I wouldn't exclude the possibility that there were some "dark forces" behind them in some countries. Genuine P2P has always scared the shit out of traditional companies and politicians.

Arathorn 10y ago
This isn't entirely true these days - ICE (RFC5245) has been out for 6 years and defines a pretty robust, open and tractable solution for firewall traversal. There are a bunch of libraries and apps out there that use it, including one built into most web browsers as part of WebRTC. If anything the exciting situation we're in currently is because the tech has caught up at last. Firewall traversal is no longer a black art; you just open a WebRTC data connection.
infodroid 10y ago
> 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