IPvPub: Decentralized Internet by@BenjiStokman
471 reads

IPvPub: Decentralized Internet

Read on Terminal Reader

Too Long; Didn't Read

People Mentioned

Mention Thumbnail

Company Mentioned

Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - IPvPub: Decentralized Internet
Ben Stokman HackerNoon profile picture


Ben Stokman

Videogame lover and privacy advocate

Learn More
react to story with heart

IPvPub part 2

Best Internet layout for blockchain scalability

The Internet is not decentralized.

Nor can it really not, but I’ll talk about that later.

The internet is currently run by big ISPs that can dictate what speeds you get. Net Neutrality currently (in most places) protects consumers, but there is no way to ensure that those protections will stay in place.

Which means that these for profit conglomerates may have control over what you get and don’t get.

And even then, the free market might not be able to protect you — about a third of Americans have only one ISP, which is often their TV provider.

The way to fix this is to get rid of ISPs altogether.

andrena.tech, in his article about a decentralized internet in a community, suggested that people would buy internet access directly from their neighbors via wireless connections.

There’s one problem with this: it is so slow. Good luck playing any video games, because it will take a while to just get across town — let alone the country.

There would also be many places that have congestion issues due to some popular server there.

I pointed the first problem out to him in an email:

I read your article and I have a few things to say/ask.

What happens when someone is way out in the country? Would you use wires to your neighbors home?

Eventually, that connection has to go long distance, which means that there are a few people that are connected to that wire. How do you expect to connect larger distances?

I think your idea is impractical. The amount of nodes that your traffic would go through will slow down your internet way too much. I like the idea of a decentralized internet is good, but the way you are doing it is inefficient. I suggest a community or [large] neighborhood (like a township or close group of neighborhoods) having its on connection to a main hub, which is connected to other neighborhoods. which is connected to other cities and places. Each house would have their own cable.

Ben Stokman

PGP public key

He then replied with:

Hi Ben,

Thanks for the feedback. You are correct in that with current technology we cannot replace the entire infrastructure especially over very large distances. This is meant to be a technology for “The Last Mile” and density matters in the areas chosen. Working with dense communities and hubs is exactly the right call. There’s no silver bullet for the entire last mile, but currently the wireless technology is capable of working in towns and cities hubbed together, like you said. The only issue is with each house having their own cable (maybe I’m interpreting this incorrectly), as that’s exactly what ISPs do today. It’s a business model that doesn’t lend itself to decentralization, which is why we chose wireless. So if we start from a position where we want to use as much wireless as possible, while leveraging wholesalers wired fiber for providing high quality internet, we find that we can actually replace a lot of what ISPs do at the community and town wide level. One of the biggest companies that does this from a monolithic perspective is Rise Broadband, and they’re in the category of fixed broadband. They use wireless technology much like an ISP manages utility poles to reach people’s homes. What OISP proposes is to take the best from fixed broadband and scale it horizontally in a decentralized fashion with blockchain.

Thanks for reaching out Ben, always glad to chat!

Neil C

Now that you feel guilty for skipping half of that, I would like to inform you that you can skip half of that if you want to.

Basically: I said that his idea was slow, and then he clarified to me that the wireless connections would be connected short distances into fast, longer distance cables.

That is better, way better, and almost better than what I am proposing, if you don’t actually care about a decentralized internet.

What I am proposing is that a large group of neighborhoods — maybe 5000 houses — would have their own local server that is paid for collectively by them, and may be subsidized by the government. This will allow each “large group of neighborhoods” to run their own node on the blockchain.

The IPv6 geolocator will be the same format, what the bits mean will be changed.

Take that example IP addresses I used before

Example IP address:2002:4559:1fe2:a71b:774252d1a160076a563ce3d312dce1c46beddd1f5855d9126e8c0b9c26e47ede

2002: Region — this is a group of areas, which usually spans a planet. This is currently part of IPv6, and is the same.

4559: Area: The area will be a city or metro area or group of counties

1fe2: Neighborhood: the neighborhood will be a group of 5000 or so households. This is the point at which the mesh network turns into spokes.

a71b: Customer: the customer is the point at which the WAN turns into the LAN.

There will be no subnets. Subnets are not needed, and can be managed by the customer if needed.

The neighborhoods will be each connected to about 15 or so other neighborhoods around them, so that traffic does not have to stop at many nodes if it is going long distance. A neighborhood does not absolutely have to be a group if 5000 houses or so. Large servers or an office complex can have their own neighborhood.

The cables that connect neighborhoods will also have to be really fast — like, 100 terrabytes fast — a chain is only as strong as its weakest link.

There will still be the cables that connect long distances. These cables will most likely be government subsidized, unless the residents of a neighborhood are willing to spend money on a long distance cable for themselves. These cables will not go to neighborhoods right next to where it started, but maybe neighborhoods that are 5 maybe 10 neighborhoods away. Many cables should be built spanning accost an area, and a few very thick cables going to other areas and long distances.


Half of the reason for doing is speed — mainly latency. There would have to be a way for the neighborhoods to know the fastest way to get packets to their destination. A government could manually map everything, but that map may become outdated quickly.

There has to be an automatic way, a way for the servers running the neighborhood nodes to figure out the fastest path.

There is a very simple way. Every neighborhood server knows the ID of the other neighborhoods that it is connected to. The server will then ping the servers that they are connected to, and record that data.

The difference will be within milliseconds, maybe microseconds. The neighborhoods will then release their data to the nodes surrounding them, and they do the same. This will be referred to as a latency map.

Note that this is done on the intra-area level, but this can be applied to the inter-area level.

The neighborhoods will then use the data to find the fastest path.


Often times, traffic is going to other cities or specific places. This will cause a few nodes to become overwhelmed and backed up because they are the “fastest” route.

When a node is overly congested, some traffic should be routed around them.

A node can send the other nodes around them with a number from 0 to 255 of the amount of congestion they are experiencing.

The nodes around them will then send traffic other ways, so that the extra time that it takes to send traffic the other direction is even with the amount of time saved by not sending the traffic to the congested node.

But since only the nodes that are directly around the congested node consider this, traffic may be sent to the node around the congested node just to be sent another direction that may have been faster if sent there in the first place.

To fix this, the latency map will have to be updated live. The nodes will then recalculate the fastest route for each packet.

However, recalculating the route for each packet is inefficient. The fastest route will be stored until new data comes in. Every time a packet comes in that pertains to that new data, the route is recalculated.


Blockchains have the problem with scalability — and if a blockchain that everyone uses would be sustainable. If everyone on the planet (7.5 billion people) sent two 250 byte transactions a day, that would amount to 3.75 terrabytes a day. To put that in perspective, the current size of the Bitcoin blockchain is around about 140 gigabytes; and 3.75 terrabyte estimate is very low. If a blockchain like Cicada was running everything, the data consumption would be a lot higher.

Now imagine trying to run that yourself, on your own personal income. You might run into a few issues.

But 5000 having people funding the node will make things way easier.

You may not need to store the blockchain to mine, but that data has to be stored somewhere; and it shouldn’t be trusted to banks, beaurocracies, governents, conglomerates, the rich, the military, the people against decentralization.

Blockchains are important because they finally let us have control, let is not be tricked to believe that ideal should not be protected.


. . . comments & more!
Hackernoon hq - po box 2206, edwards, colorado 81632, usa