Through a complex interrelationship of distinctly controlled networks that advertise routes and addresses and allow traffic based on complex business relationships (peering). The only case where that's not happening is where we both have the same ISP, and ycombinator happens to be hosted there as well. Running a traceroute from myself to news.ycombinator.com, I count two distinct networks not including my local one, and not including cloudfare. If those networks stopped talking to each other, my packets to hacker news would find another route, assuming my first hop had access to other networks (given time for the networks to determine a new route and my first hop had access to other peers).
We're talking about the web as an application layer protocol. By your definition everything that happens on the internet is decentralised. That's not untrue if you look at it from the point of view of TCP/IP, but that's tangential to the conversation we're having.
You seem to be conflating the web with the internet.
But even by that definition, the web isn't a single application, it's many applications, some of them compartmentalized (search, social), some of them not (email), and some in between (websites/blogs). If an application were centralized, I would expect a single provider you had to use, but instead, where it at least compartmentalized, you have a group or providers. Can you name a single service/application that you expect more than 5% of people use that has only a single provider? For search, you have Google, Yahoo, Bing, and other smaller players. Google is dominant here, but still has less than 68% of the market. For social, Facebook is the dominant player, but you yourself used a different social network to communicate on this subject, and there are many other providers with popularity that ebbs and flows. It's the same with anything I can think of. I'm not sure how this is considered centralized under any definition.
Yep, the web is a distributed system. Yep, the web offers many services, and many providers offer the same class of service.
However, each and every one of those services are centralised in a technical sense on account of HTTP. Why might an alternative be useful? Consider the solution the Google service we're addressing is putting forward cf. Content Addressable Networking systems[0]. I can't spend any more time explaining, sorry. This might help- note the levels of centralisation in each generation of P2P systems:
So, I think I'm starting to understand your argument, which is that the web is composed of many services which each is implemented relying on an underlying centralized authority, and you want that to change? If that's the case, then I understand the need, and agree with that poiint of view. But I think to say "the web" or "the internet" is centralized is very big stretch. I wouldn't call a bunch of decentralized services with little shared infrastructure and ownership "centralized".
I'm definitely not saying the internet is centralised! Perish the thought. I never mentioned it- the discussion was to do with the web specifically.
Forget the web as a whole and consider a single service such as HN. That graph has |clients| >> |servers|. More than the cardinality the client and server nodes are different in kind.
I consider a decentralised architecture to be one where the nodes can in principle participate equally.
You are arguing that the web is decentralised because there are many services to choose from. I don't disagree, but that's above the application layer protocol- which is what I thought we were discussing. In that case decentralisation happens above the application layer. So in humans? By that definition BBS's were decentralised because I could call a different one.
In other words, yes the web is decentralised because I can choose from many Forex APIs. But at the logical application layer of HTTP, OANDA is a centralised service. HTTP addresses point to specific nodes which may or may not be individual servers at the network layer, but from the point of view of HTTP that's what you address. In a decentralised application layer protocol I would expect to that not to be the case.
That Google is proposing this service is proof that individual web services are centralised. There's a single point of failure.
We're talking at different layers. It's just semantics from here on in.
No, I'm not arguing the Web is decentralized, at least not as you are using the term. I'm arguing it's not centralized. That's an important distinction, which I tried to cover in a response in a different thread[1]. We wouldn't be having this conversation if you had the web needs to be more decentralized, but you stated the web is centralized. not(decentralized) != centralized. This problem was then compounded by our discussion about services, where you are referring to services as individual protocol definitions, and I'm referring to them as implemented in the wild. While a protocol definition may call for it to be implemented in a centralized (n-1 client server relationship across direct communication), I'm referring to the ecosystem which provides many, many instances of this, which adds a layer of redundancy and decentralization to the service as it exists in reality. That's not as good as a well defined decentralized protocol definition, but it is a manner of decentralization. So again I think we were arguing points that are, for the most part, correct, but using confounding terms.
I think you would have communicated your intent better if you said the web is not decentralized enough. I've been arguing the web is not centralized, you've been arguing the web is not decentralized (but by saying the web is centralized), and the problem is that both are true. The current situation is in-between those two extremes. Arguing that the web is centralized, when it isn't unless you define your scope to be so narrow as to not really encompass what most people think of when you say "web" is counter productive, when your point is a good one, and whether the web is "centralized" is irrelevant. What matters is whether there are benefits to being less/more centralized (or more/less decentralized) from the current state.
Edit: As a suggestion for how to refine your original statements so they are more accessible and understandable to those reading them, I suggest changing "the web is centralized" to "the protocols the web relies on require single centralized authority". It's more verbose, but it doesn't require cognitive leaps in just one of multiple possible directions to get what you are trying to express.
To take Google as an example: 92% market share in Europe in 2014 [1], 81% of the global market for smartphones (Android) [2] - 96% if you also add the single relevant competitor iOS. None of this is technically centralisation. (And won't ever be, as you could always "decentralize" the web by running your own personal search engine on your home box. As long as someone is using it, google doesn't have 100% market share.) However, it doesn't make much of a difference when you want to develop an app that doesn't get accepted into the iOS or Android app store.
But all if this is obviously beside the point that the OP made. Even if you don't want to develop a search engine or a phone app, you still have to tie your users to a central "cloud" service and web site so you can get discovered by google. That's a huge disincentive for p2p services.
That's a great argument for how dominant Google is in the smartphone OS category, but that doesn't really say anything for whether the web is centralized. Even with 100% market penetration, there are people that opt to not use Google's included apps (such as Facebook and their messenger app).
