
Reweaving the web: A slew of startups is trying to decentralise the online world - vasaulys
http://www.economist.com/news/business/21700642-slew-startups-trying-decentralise-online-world-reweaving-web?fsrc=scn/tw/te/pe/ed/reweavingtheweb
======
tzpardi
All these articles in the mainstream media about decentralized computing are
very nice and the Ethereum and Bitcoin PR teams are doing a fine job to
disseminate the idea of decentralized computing. At the same time, I think we
need to be more honest about one of the fundamental issues of decentralized
networking, which is that the bootstrapping of the network is not
decentralized. The bootstrapping in fact centralized in Bitcoin, Ethereum, all
existing cryptocurrencies and Streembit as well. The unique selling point of
these application are decentralization, but there is a big, fat single point
of failure risk, which is the bootstrapping of the network.

I have started a discussion at
[https://groups.google.com/forum/#!topic/streembit-
dev/Xl2DpG...](https://groups.google.com/forum/#!topic/streembit-dev/Xl2DpGpd-
vw) to start working on the problem and propose a solution for the issue.

Disclaimer/disclosure: I wrote the Streembit application which is mentioned in
this thread, so I am heavily biased towards decentralized, peer-to-peer
solutions I try to explain in this blog what we try to achieve with Streembit
at [http://streembit.github.io/2016-02-23-What-is-
Streembit/](http://streembit.github.io/2016-02-23-What-is-Streembit/).

~~~
forgotpwtomain
Is there a Spec available for Streembit somewhere? I've looked at the
documentation
([http://streembit.github.io/documentation/](http://streembit.github.io/documentation/))
but there doesn't seem to be much detail.

~~~
tzpardi
Hi, I wrote a white paper which is available at
[http://streembit.github.io/](http://streembit.github.io/) and link of the
white paper is
[http://streembit.github.io/downloads/streembit_whitepaper_v1...](http://streembit.github.io/downloads/streembit_whitepaper_v101.pdf)

We use open standards such as JOSE, JWS, JWT, JWE and the audio & video is
WebRTC that is open source as well. All crypto are FIPS compliant and the ECC
and ECDH uses recommended curves. The IoT is directly mirrors our work in W3C
WoT. I am working on W3C WoT security and move the code from there to
Streembit. The objective is with Streembit to stay based on open standards.

------
chuhnk
It's cyclical and this should be obvious to anyone in technology. We move
between eras of centralisation and decentralisation. The internet started as a
decentralised network in which we then built high capacity centralised systems
at an accelerated rate. We're now about to shift back into a new era of
decentralisation fuelled by edge/fog computing, IoT and p2p networks all on
top of the existing infrastructure.

The point is that it only occurs when we have a specific need and a niche
vertical to initially leverage it in. In one form it's bitcoin for payments.
In another form its IoT and essentially sensor networks. You can imagine
autonomous vehicles being a huge p2p network for speed as opposed to feeding
all the data back to the cloud.

~~~
qwtel
Or consider the much more "cynical" (and in my mind more obvious, if it wasn't
for our habit of seeing patterns everywhere) view that there might not be any
structure, cyclical or other, to the course of history. In that view, whether
the future of the internet will be centralized or decentralized is
undetermined and will most likely be a mishmash of both, the extent of with
will depend on inertia, ideology, economics and luck.

~~~
jeffreyrogers
I think the tendency will be towards centralization because centralization is
more efficient.

~~~
substack
Not for transferring large files. A centralized architecture is the most
expensive, slow way to do that.

------
DyslexicAtheist
Streembit[0] is missing in the discussion. It's not a new company and just a
FOSS project. I believe it has same if not better potential than Ethereum[1]
but without the risks associated with Ethereum or Bitcoin (e.g. Sybil attacks,
blockchain block size debate, time it takes for proof of work, fully
decentralized* etc). Plus it is up and running and can be tested by anyone who
wants to give it for a spin[2]. Compared to Ethereum it has optional
blockchain hooks, but uses a Kademlia[3] DHT. One can inject scripts that
achieve more complex tasks (Smart-Contracts, Code to use the blockchain
instead, centralization[4] logic, etc) on top of the Streembit network by
injecting the Javascript into the DOM.

Streembit is currently the only such project actively participating to W3 Web
of Things standardization group and already incorporates all currently
evolving standards put forward by the W3 Web of Things (WoT). We're working on
a proposal to standardize "IoT over P2P" that we can put forward to IETF.

[0] [https://streembit.github.io](https://streembit.github.io)

[2] [http://blog.valbonne-consulting.com/2016/06/09/streembit-
hel...](http://blog.valbonne-consulting.com/2016/06/09/streembit-hello-
world-1st-ever-video-call-over-a-decentralised-p2p-network/)

[3]
[https://en.wikipedia.org/wiki/Kademlia](https://en.wikipedia.org/wiki/Kademlia)

[4] despite popular believe P2P networks suffer from centralization issues in
P2P bootstrapping. Also Ethereum is not truly decentralized as the DAO attack
shows

Disclaimer: I do not financially benefit from evangelising Streembit though
I'm a voluntary contributor to the project so my position is certainly one
that I would want to see them succeeed.

~~~
the8472
> despite popular believe P2P networks suffer from centralization issues in
> P2P bootstrapping.

That's a fairly modest problem. You need a bunch of nodes with above-average
capacity to handle the bootstrap traffic and a way to occasionally update
lists of such nodes. But a bunch of 10$ per quarter virtual boxes at a hoster
of your choice and a bunch of domains with DNS SRV records can do that job.

In the absence of any/multicast-for-everyone someone will have to pay a little
money or (ab)use a handful of non-decentralized services for the bootstrapping
but that's more of a philosophical problem than a practical one.

There certainly is no single point of failure, you can have plenty of
redundancy in the bootstrap process.

~~~
tzpardi
The number of existing bootstrapping nodes do not solve the fundamental
problem of current centralized bootstrapping. Not even if a virtual box costs
$1 instead of $10. The issue is how a connecting node knows about other nodes
in the network, and the current propagation of this information i.e. the DNS
or IP of the seed nodes introduces centralization.

The closest and best solution for this problem was the early days idea of
Bitcoin to use IRC to publish the listening seed information, but IRC still
not decentralized, so IMHO decentralized bootstrapping is a real problem which
we need to solve.

I kicked out a discussion for this at
[https://groups.google.com/forum/#!topic/streembit-
dev/Xl2DpG...](https://groups.google.com/forum/#!topic/streembit-dev/Xl2DpGpd-
vw)

~~~
zzzcpan
I don't think bootstrapping per se is a problem. You only have to do it on
first install and this allows for a simple solution to distribute
bootstrapping in time, i.e. changing hardcoded bootstrapping data every N
minutes, so new users could bootstrap from different nodes, than the users
before them and so on.

A bigger problem is how software is developed. The development itself is
centralized, but even worse, traditional software development approaches
cannot predict all future problems, but rely on fixing them to keep the
software working, which means it must be delivered to users in a centralized
way too.

~~~
tzpardi
I am sorry, but centralized network bootstrapping is a very well known issue
and unsolved problem of decentralized networks.

[http://ryandoyle.net/assets/papers/Distributed_Bootstrapping...](http://ryandoyle.net/assets/papers/Distributed_Bootstrapping_of_P2P_Networks-
RDoyle.pdf)

[http://grothoff.org/christian/dasp2p.pdf](http://grothoff.org/christian/dasp2p.pdf)

[http://www.net.in.tum.de/fileadmin/TUM/NET/NET-2014-08-1/NET...](http://www.net.in.tum.de/fileadmin/TUM/NET/NET-2014-08-1/NET-2014-08-1_01.pdf)

You say: "i.e. changing hardcoded bootstrapping data every N minutes, so new
users could bootstrap from different nodes"

The fundamental issue is, changing the data where? The node who wants to
connect to the peer network, obviously cannot obtain the information from the
peer network itself (as node is not connected), so obtain the information from
where? Currently, all decentralized applications, including my system
Streembit use the techniques of obtaining the information from a centralized
source - which is the oxymoron of decentralization. If a web services or other
centralized applications provide the new node with the list of existing
listening/connected nodes then the solution is surely not decentralized.
Government agencies or cyber-criminals only need to attack the hard coded,
listening seed nodes and then the network is done and never can be back again
until a new list of hardcoded seed nodes is published via the application
source code or via other channels.

As I said above, Satoshi's original idea to obtain the seed info from IRC was
the closest to decentralization, but since IRC is centralized itself I am sure
you can see how far that is from the a decentralized bootstrapping.

We have the solutions on local decentralized networks such as mDNS and UDP
multicasting which uses protocol level solutions, and we are investigating to
solve the problem at Streembit with IPv6 anycasting.

<<< A bigger problem is how software is developed. The development itself is
centralized, but even worse >>>

I disagree. Open source software can be forked and then you can adopt as much
democratic development methods and governance as you want.

~~~
zzzcpan
> The fundamental issue is, changing the data where? The node who wants to
> connect to the peer network, obviously cannot obtain the information from
> the peer network itself (as node is not connected), so obtain the
> information from where?

Ok, you are assuming that the node already has the binary somehow. But that's
not the case. In the real world we have to ship binaries to users. And this is
where you can put your different bootstrapping data for different users.

You can go a lot farther: let users generate a binary distribution of the
software to share with each other and hardcode bootstrapping data there
obtained from a running network by that user.

> Open source software can be forked

The majority of users are not going to do that, they just don't have the
skills. At best there will be a few popular distributions of the same
"decentralized" software, with majority of installations controlled by a few
entities. At worst - just one centralized entity that controls every
installation.

~~~
tzpardi
<<< Ok, you are assuming that the node already has the binary somehow. >>>

Well, I am not assuming anything. I am talking about a fundamental problem of
decentralized networks: the current bootstrapping of networks is centralized.
Please refer to the quoted papers and there are many other research papers as
well which describe this existing problem.

<<< But that's not the case. In the real world we have to ship binaries to
users. And this is where you can put your different bootstrapping data for
different users. >>>

You are misunderstanding the problem. The point is

a) we should never ever hard code the seed information into the application
and consequently ship it with the binary. If we do rely on the current
approach then you always connect to the seeds of ETH foundation, Bitcoin
foundation and to my company's seeds in the case of Streembit which is the
oxymoron of decentralization.

b) we should have a protocol level solution for entity discovery instead of
application level solution such embedding the seed info in the source and then
compile it into the app. When I say protocol level solution I refer to mDNS
and UDP multicasting which works on local networks just fine and I am
proposing IPv6 anycast for entity discovery on global networks.

The simple truth is that Bitcoin, Ethereum and all cryptocurrencies
conveniently ignore this issue. The companies, lead developers, foundations or
whoever run the show maintain the seed nodes, but such solution is surely not
a decentralized solution.

~~~
zzzcpan
> we should have a protocol level solution

No! This is a problem that solves itself once you solve a binary distribution
problem. But none of the papers you refer to address the problem of the
centralized binary distribution and jump right to the protocol level for some
reason. It doesn't work like that.

~~~
tzpardi
I don't want to be condescending and I apologize if I sound like that, but I
think you totally misunderstand what the problem is.

What difference it makes if you disseminate a fundamental design problem (i.e.
the bootstrapping of the network is centralized) with a different type binary
distribution? Whichever method you use for binary distribution, the
distribution will deliver the very same existing problem. Again, please refer
to the quoted papers to understand why the centralized network bootstrapping
is an issue.

On the note of binary distribution, yes that is an issue as well and it would
be nice to have a decentralized binary distribution, but again, that is an
entirely different problem. BTW, I think our application Streembit can be used
for decentralized binary distribution as well.

~~~
zzzcpan
I think it's the other way around. You don't want to see that bootstrapping
depends on the binary to be present on the node somehow and for some reason
you think that solving bootstrapping makes sense even if it depends on another
completely unsolved problem. It doesn't. You solve the first problem and only
after that move on to the one that depends on this problem being solved.

~~~
tzpardi
<<< you think that solving bootstrapping makes sense even if it depends on
another completely unsolved problem >>>

No. The problem of centralized bootstrapping that is an existing and real
issue of decentralized networks (see the quoted papers and my above
explanation) does not depend on the problem of "binary distribution". In fact
it has nothing to do with "binary distribution". If a user builds the software
from source - so the user avoids any "binary distribution" \- then the user
still have the problem of centralized network bootstrapping.

It seems you don't understand that the problem of centralized bootstrapping is
a generic information technology problem of all users, regardless what was the
method of "binary distribution" if any. That's fine, it was a good discussion,
but I exit from this debate with you which is becoming meaningless now :-)
Thanks for sharing your view" :-)

~~~
zzzcpan
> If a user builds the software from source

Again, sources do not emerge out of thin air and have to be shipped to users
somehow. No matter what you do, user must get the software first to bootstrap.
And since bootstrapping always requires information from the sources it cannot
be considered a separate problem until you solve the problem of shipping that
information to users in a decentralized way.

All of the so called "decentralized" software is fundamentally broken at the
moment.

~~~
tzpardi
It seems, you are trying to decentralize the who world which I think is a)
unrealistic b) doesn't make sense. On the other hand, we are trying to solve
specific use cases with decentralized applications. For instance Bitcoin
implements a decentralized payment network to address a specific use case and
our application Streembit implements a decentralized communication framework
for humans and machines.

I am perfectly comfortable with disseminating the source via the centralized
Github, though it would be nice to have a decentralized source control system.
Users trust me and get the source from my repository. Users who don't trust me
can fork the software and modify or distribute for themselves from the repo of
a trusted person. The source distribution is centralized, but so be it. Once
the users have the source/binary via Github the application addresses several
use cases in a decentralized manner. I don't see how the centralized source
repository invalidates the runtime soundness and robustness of a decentralized
payment or communication P2P app. At the sametime, the runtime soundness and
robustness of decentralized payment or communication P2P applications
seriously affected by the centralized bootstrapping.

<<< All of the so called "decentralized" software is fundamentally broken at
the moment. >>>

Quite true, but it is broken, because of the centralized bootstrapping, and
not because of the source code is managed by a centralized repository
application. I can drive with my car to your place and give the source code to
you in person, which will be the ultimate decentralized source code
distribution, but the issue I was talking about (centralized bootstrapping)
will still exists once you run the software. I am talking about design and
runtime problems of decentralized networks, and you have been talking about
something different. Anyhow, thanks for the chat and all the best! :-)

~~~
zzzcpan
I cannot acknowledge the decentralized bootstrapping problem, I'm sorry. It
relies on the information from a centralized authority (i.e. source code) and
therefore cannot be solved until the first one is solved.

------
xg15
> _Then there is the question of how decentralised services will earn their
> keep. [...] More fundamentally, an internet that eschews control points may
> be one that affords firms less opportunity to build profits. To create a
> return that makes venture capitalists happy, the new tech firms will almost
> certainly come under pressure to get ever bigger._

This seems to me the core problem and contradiction of the current initiative:
As I understand it, the whole promise of decentralized services is that:

1) Because most of the logic is run by peers, the "upkeep" for the designers
of the system is very low, if existent at all. Ideally, the system is
completely self-sustaining (as long as there are peers) and the designers
don't have to do anything to keep it running. (In the face of bugs and hackers
this is probably utopic as you'd need at least some way to do security
patches. It should however be significantly less than to run/rent servers)

2) Because most of the logic is run by peers, its the peers who decide how the
system evolves, not the original designers. One consequence of this (and the
main reason why _users_ would want a decentralized system) is that the
designers can't change the system for political/strategic/profit reasons.

If VCs are now pushing startups in building decentralized products with the
traditional expectations of growth and/or profit, I don't see how we can get a
product that satisfies point (2).

My fear is that anything that comes out of such a partnership would be "flawed
by design" in the same way that DRM and many IoT products are: Such a product
would look on the surface just like a "real" decentralized system, except with
the one thing removed that makes decentralized system more useful than
centralized ones: The lack of control points. Because you'd need such a
control point to actually steer the system in a direction that satisfies
investors.

~~~
tzpardi
<<< Because most of the logic is run by peers, its the peers who decide how
the system evolves, not the original designers. >>>

I think it is the misunderstanding of how decentralized applications work. The
seeds decide about nothing during runtime. In an ideal scenario the seeds
execute the application without being able to make any decisions terms of the
business logic. That's how the trust between seeds can be established by
executing the common functions i.e. Bitcoin mining or performing the Ethereum
smart contracts by executing the application.

The issue is, we do not want the peers decide anything or be able to modify
anything term of business logic. The objective is that all seeds execute "the"
honest, published version of the software. Because such cannot be guaranteed,
fundamental security issues exist in decentralized computing, some node can
act dishonestly, and therefore vulnerability to 51% attacks and Byzantine
Generals Problem exist.

~~~
xg15
That doesn't match with my observations of the few decentralized systems we
had working so far (e.g. Bittorrent, IRC, federated messengers or the WWW seen
as a whole.)

To take the WWW as an example, the W3C once tried to unilaterally update the
system with XHTML2 and utterly failed, because none of the peers were adopting
the change. But even the browser vendors don't have (or didn't have at least)
the full control: they were bound by backwards compatibility of existing sites
and by the threat of new browsers or forks emerging. Finally, the peers can
change what they are executing by using extensions or forked browsers.

------
sverige
The narrative for the last few years, at least in the mainstream media, is
that Google Facebook Twitter Microsoft et al. are too big for anyone else to
replace them. It's the old "inevitability" argument - if your new thing gets
too big, they'll just buy you up.

Let's hope people continue to try to create services that a big percentage of
people use and then resist to sell to the big data companies.

~~~
doctorshady
This probably won't be a popular opinion, but it seems like
Google/Facebook/etc are entrenched too deeply in this incarnation of the web
to be displaced any time soon.

They seem to understand where they are too - it goes beyond just buying out
competitors. Look at Facebook's Internet Lite plan for India.

~~~
sverige
> Look at Facebook's Internet Lite plan for India.

Which was a spectacular failure...

~~~
doctorshady
Right. My point was more that they're willing to go to some fairly extreme
measures to try insuring their market dominance.

~~~
sverige
And it sounds like we share the hope that they'll never fully succeed.

~~~
doctorshady
Definitely can't disagree :) . I've had my reservations about the direction of
the internet before, but a Facebook walled garden internet just sounds plain
scary. Or worthless.

------
dwaltrip
This is an important topic. I think that centralization is more of a risk in
the digital realm, as single button presses can affect the lives of hundreds
of millions of people in serious ways, especially as tech gets more entangled
with all aspects of our lives, including very personal things.

Side note: I found it amusing how the article pretended that decentralized
downlownding of copyrighted media stopped after Napster, and that:

> these technologies ended up being limited to a few services, such as Skype.

I'm having trouble interpreting the section with this quote as anything other
than the author being hugely misleading. According to Wikipedia, BitTorrent
alone has at least 150 million users.

------
apatters
I wish the article had spent more time discussing the root causes of the
centralized Internet and ways to address them. This is the most interesting
problem in tech right now in my opinion and many people are working on it from
different angles but I've yet to see anything which really struck me as a
killer app for the "re-decentralized" web.

We have to look at why these centralized services have succeeded: for instance
the network effects, the economies of scale, their business models are
attractive to ambitious VC investments, they have better UX because they have
more resources, and so on. Then you can either try to build something which
matches these advantages, or you can try to do an end-run where you offer the
market something more important.

Privacy and security are things the market is starting to value but I don't
think these alone can woo everyone away from the network effects, better UX
etc. of the centralized giants.

Anything which brings people out of an ad-heavy experience has a lot of appeal
right now. I think we'll see more freemium and paid services in the future
which is good because the economies of scale in the ad business are brutal to
small businesses.

Anything we do to create more robust p2p and client-side encryption platforms
is important. When building an app today it's just much easier to run it on a
server and keep all the data on a server. p2p storage, identity and so on
needs to become just as easy.

And finally we have to ask how this re-decentralized stuff is going to attract
investment and build big businesses, because if the big money is always on the
other side it's going to be very hard to win.

To be honest I think the technical challenges are fascinating but it really
needs to start out with the business model and investment challenges, if you
can figure out how a lot of money can be made off of a decentralized search
engine or social network, now you have some real allies and resources and
marketing behind you. This requires us to think about why open source business
models are typically not as lucrative as proprietary walled gardens, and why
they have a hard time getting traction in b2c.

~~~
DyslexicAtheist
>> _as a killer app for the "re-decentralized" web._

IPv6 anycast looks quite promising[0][1][2] to help solve the problem with
fully decentralizing bootstrapping of P2P nodes. This is a central issue
currently affecting all p2p like networks including Ethereum, BitTorrent,
Gnutella, Bitcoin, ...

main issue is probably lack of IPv6 anycast support (??) due to
misinformation, broken middle boxes, and and lack of understanding in how to
properly configure your network correctly for IPv6 (there are so many features
making it also more secure, yet the impression I get is that people don't want
to learn about it and in practice just aim for IPv4 maximum compatibility ...
).

[0]
[http://ryandoyle.net/assets/papers/Distributed_Bootstrapping...](http://ryandoyle.net/assets/papers/Distributed_Bootstrapping_of_P2P_Networks-
RDoyle.pdf)

[1]
[http://doc.tm.uka.de/2009/ipv6-contest-p2p-bootstrap.pdf](http://doc.tm.uka.de/2009/ipv6-contest-p2p-bootstrap.pdf)

[2]
[https://www.ipv6council.de/fileadmin/summit09/presentations/...](https://www.ipv6council.de/fileadmin/summit09/presentations/IDEA-
pv6contest-p2p-bootstrapping.pdf)

~~~
the8472
> main issue is probably lack of IPv6 anycast support (??)

It requires root or user-namespace shenanigans to assign the v6 address needed
by the p2p client.

And access to BGP tables.

And they don't estimate how long such a bootstrap process would take, since
for small networks it would potentially have to scan millions of candidate
addresses.

------
Ericson2314
Heh, searched for IPFS and was disappointed they didn't because it didn't come
up. But turns out it did, they just misspelled it "IFPS".

~~~
oolongCat
Even searching for IPFS the first result on google for me is,

[https://www.ipfs.com/](https://www.ipfs.com/) lol

------
ralala
For most of the P2P overlays there are multiple serious attack possibilities
(Sybil attack, routing table poisoning).

Some years ago in the university I wrote a paper about that in a seminar to
summarize the possible counter meassures, but from what I remember, there were
no really practical solutions. I think the most promising one is the use of a
centralized certificate authority, which reintroduces some of the problems p2p
wanted to solve. Does anyone know if new ideas have come up in the last years?

~~~
the8472
[http://doc.tm.uka.de/SKademlia_2007.pdf](http://doc.tm.uka.de/SKademlia_2007.pdf)

Combine that with using the global overlay only for bootstrapping of common-
interest sub-networks and you'll limit the incentives that an attacker will
have to attack the global overlay while also reducing the effectiveness
because a single non-fake contact will be sufficient to join the subnetwork.

It's not an absolute defense (sybil-resistance without central authority is
hard) but in practice it won't be worth it for attackers.

~~~
ralala
I think it's still important to find a good balance for the computational cost
of the crypto puzzle.

Attackers will probably have a lot of computational resources (think of AWS,
botnets, GPU computations), while typical users don't (mobile phones).

I haven't had time yet to look into the IPFS details yet, but thanks for the
reference.

------
joelg
"Most are based on open-source software, which anybody can use without charge,
so startups will have to make money with add-on services, such as updates,
maintenance and subscriptions."

I hope that in the next century, we'll chuckle with nervous laughter at how
absurd the loaded assumptions in quotes like this were, and at how reasonable
it seemed at the time.

~~~
woah
Why?

------
qq66
Is there anyone making consumer SaaS applications that I can deploy myself?
For example, being able to run Dropbox, Spotify, Evernote-style applications
backed by my own server in my house.

------
aphextron
Economist paywall. Can someone post the article?

~~~
pmontra
Click on web at the top, find the link and open in private window. It let me
in through the main door without paywall tough.

------
zfnsgmdydmy
Ah, tech startups. Because there's truly never enough silly solutions to
problems that don't exist.

------
stephengillie
Can the title be corrected? It has a plural noun leading into a singular verb.

Unless we're supposed to parse "slew of startups" as singular...

~~~
rosser
> _Unless we 're supposed to parse "slew of startups" as singular..._

Yes, that's how that works, grammatically. The noun in that sentence is the
slew, which, in this instance, happens to be of startups.

