Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Avoiding Internet Centralization

mnot.github.io

Post reply on HN
Print view View original

21–30 of 111 posts

Re: Avoiding Internet Centralization

#21

Post by rvz »

gefhfff wrote: post #5

A recent example is "Message Layer Security". While Wire and Matrix are working on a decentralized version the IETF is, unfortunately, working towards one based on a central entity. Source: https://news.ycombinator.com/item?id=25102916 https://matrix.org/blog/2021/06/25/this-week-in-matrix-2021-...

Interesting to see Wire, and Matrix making an effort in this. Unlike Signal which still requires your phone number and is completely centralized to their servers whist promoting their 85% pre-mined cryptocurrency that they can dump at any time.

Re: Avoiding Internet Centralization

#22

Post by Arathorn »

gefhfff wrote: post #5

A recent example is "Message Layer Security". While Wire and Matrix are working on a decentralized version the IETF is, unfortunately, working towards one based on a central entity. Source: https://news.ycombinator.com/item?id=25102916 https://matrix.org/blog/2021/06/25/this-week-in-matrix-2021-...

As far as we know, the Wire version is still logically centralised, using a centralised sequencing server.

On the Matrix side we’re working on fully decentralising it (as per https://matrix.uhoreg.ca/mls/ordering.html). There’s also a cool similar project from Matthew Weidner: https://dl.acm.org/doi/10.1145/3460120.3484542

It’s a bit perplexing that mnot’s draft cites XMPP as decentralised, given MUCs are very much centralised to a single provider which entirely controls that conversation, and if that provider goes down the conversation is dead. But I guess that’s because XMPP is submitted to the IETF, and Matrix isn’t yet.

Re: Avoiding Internet Centralization

#23

Post by lotsofpulp »

walrus01 wrote: post #11

Something not really covered is this concept: "Maybe don't let one telecom company acquire too much control". Look at the history of everything that was acquired by either Qwest/CenturyLink or Level3, and then the merger of Level3. You can't tell me that the existence of Lumen, the combined Centurylink-Level3 entity is good for anyone, except for their shareholders. It's the very definition of too much centralization…

Also need fat upload pipes (i.e. fiber) to individuals’ homes so they can operate their own backup and peer to peer services.

When 90%+ of people have no upload capacity at their house, and are behind tons of CGNAT, then onedrive/iCloud/google drive become the only solution for storing your things you can access later. Same with chat protocols.

Re: Avoiding Internet Centralization

#24

Post by midasuni »

foxfluff wrote: post #13
superkuh wrote: post #2

> 5.2. Encrypt, Always: When deployed at scale, encryption can be an effective technique to reduce many inherited centralization risks. ... The problem here is the word "Always". Encryption is good for just the reasons they say. But only encryption, always encryption, not having an option for plain text is highly centralizing in itself. This is because the current status quo for encryption is to use TLS based on cert…

LE also forces you to rely on DNS, which is highly centralized..

How is DNS centralised?

Re: Avoiding Internet Centralization

#25

Post by betterunix2 »

walrus01 wrote: post #10

1970: we're going to build an unbreakable worldwide network to survive a nuclear war 2021: AWS and amazon US-EAST-1 is down, this means my coffee maker doesn't work

Uh...

1970: Early networks suffered from congestive collapse problems, routing protocols were slow to converge, computed suboptimal routes, and had count-to-infinity problems, only a handful of transit networks existed, domain names were managed by one dude broadcasting a file to everyone, little to no security infrastructure, etc.

2021: We have robust congestion control and queue management, scalable routing protocols that find optimal routes and have no count-to-infinity problems, DNS, large numbers of transit networks with a high level of redundancy, and at least some security infrastructure in key places (DNSSEC, RPKI, etc.).

Don't confuse web infrastructure and hosting services with the Internet itself, which is the network and which has never been more distributed or more robust than it is today.

Re: Avoiding Internet Centralization

#26

Post by walrus01 »

betterunix2 wrote: post #25
walrus01 wrote: post #10

1970: we're going to build an unbreakable worldwide network to survive a nuclear war 2021: AWS and amazon US-EAST-1 is down, this means my coffee maker doesn't work

Uh... 1970: Early networks suffered from congestive collapse problems, routing protocols were slow to converge, computed suboptimal routes, and had count-to-infinity problems, only a handful of transit networks existed, domain names were managed by one dude broadcasting a file to everyone, little to no security infrastructure, etc. 2021: We have robust congestion control and queue management, scalable routing protoco…

It wasn't supposed to be serious, but for anyone that's ever seen a catastrophic level3 failure as a peer or large customer of AS3356... It's less resilient than you think. There are way too many eggs in one basket in some places.

Re: Avoiding Internet Centralization

#27

Post by cj »

betterunix2 wrote: post #25
walrus01 wrote: post #10

1970: we're going to build an unbreakable worldwide network to survive a nuclear war 2021: AWS and amazon US-EAST-1 is down, this means my coffee maker doesn't work

Uh... 1970: Early networks suffered from congestive collapse problems, routing protocols were slow to converge, computed suboptimal routes, and had count-to-infinity problems, only a handful of transit networks existed, domain names were managed by one dude broadcasting a file to everyone, little to no security infrastructure, etc. 2021: We have robust congestion control and queue management, scalable routing protoco…

I see your point, but do all those network level improvements mean much to the end user when so many critical services live in datacenters owned by 1 company? Many of which in a single region on the east coast, that goes dark at least a couple times a year for hours on end?

Re: Avoiding Internet Centralization

#28

Post by mindslight »

AnthonyMouse wrote: post #8
nathias wrote: post #3

> Some protocols require the introduction of centralization risk that is unavoidable by nature. For example, when there is a need a single, globally coordinated 'source of truth', that facility is by nature centralized. No, there is nothing unavoidable in making a centralized DNS system.

Right. Even putting aside blockchain-based systems, you can have systems without a dictator because they're based on voting. Suppose the root is a set of public keys, each with a top level domain. Adding one requires a supermajority of the others to agree. Removing one is impossible; it can sign its own successor and that's it. You now have a federated system with no single chokepoint.

I'd say blockchain naming and the system you describe are still both centralized. The authorities are distributed, but they're still collectively responsible for deciding on a single coherent root.

Compare with systems that don't revolve around making any coherent global view, like Petnames. In the context of Zooko's triangle - do the human readable name lookup once as part of a manual process, and then persist the relationship as decentralized/secure but not human-readable.

Re: Avoiding Internet Centralization

#29

Post by perryizgr8 »

nathias wrote: post #3

> Some protocols require the introduction of centralization risk that is unavoidable by nature. For example, when there is a need a single, globally coordinated 'source of truth', that facility is by nature centralized. No, there is nothing unavoidable in making a centralized DNS system.

In fact, isn't torrent magnet links exactly this kind of a system? You can locate files on thousands of peer systems, without using a centralized tracker.

Re: Avoiding Internet Centralization

#30

Post by Karrot_Kream »

walrus01 wrote: post #10

1970: we're going to build an unbreakable worldwide network to survive a nuclear war 2021: AWS and amazon US-EAST-1 is down, this means my coffee maker doesn't work

Unfortunately I don't think most users care. Give someone the choice between a cheap service with two nines (or even one) of reliability and a more expensive one with four, and the vast majority of people will go with the former. I mean, most ISPs in the US offer business connections with real SLAs but almost nobody is willing to pay that much for guaranteed bandwidth and uptime.
Post reply on HN