PhaseMage

I think we need a mesh topology at the network layer in order to really have reliable networks in an emergency. TCP/IP, in my opinion, is an engine that centralizes power: Which leads to choke points and single points of failure for critical systems. This is especially true for most end nodes: I'm out of luck if Comcast goes down.

I want a mesh network that does to the TCP/IP Internet what the road network has done to the train network. The road networks reduced the barriers to entry in so many industries.

I only have Comcast as an option for broadband Internet. This is the direct result of the protocol's topology. This is power and control that no amount of protocols written on top of TCP/IP can break. We can keep wanting to have decentralized or non-centralized services, but I don't see it actually happening on the TCP/IP Internet: The economies of scale are too powerful too compete against.

If we tried to layer a road network exclusively on top of a rail network, we'd just have a less efficient rail network.

Thanks for the pointers, I'll look them up!

> The question is what benefits does the meshnet provide over the mixnet style schemes?

My Isochronous grid/mesh protocol is designed to operate at the network layer. The TCP/IP Internet has: * High and Unbounded Latency * Wasteful, Underused Links * Low Redundancy * A Tendency to Centralize Power * Choke-point Surveillance and Censorship * Disaster Vulnerabilities * Tragedy of the Commons

I think a mesh network with non-centralized per-byte pricing can make a big dent in all of these.

A meshnet built on top of a starnet is like trying to build a road network on top of a train network: It's not economically feasible and ultimately pointless.

If you arbitrarily define any large wire on a pole as being "centralized", then sure, but I wouldn't agree with that definition. For example, I can lease long distance point to point dark fiber for my personal use, and run whatever combination of wavelengths and protocols that I want on it.

In the case where there is only one link between two towns, then the owner(s) of the switches at either end of that link will be able to charge a monopoly price for the bits that get sent across it. Market forces will soon encourage others to create additional links between the two towns.

In the bootstrapping phase of my plan, the case of a single link between two cities would be impossible: Network participants would create tunnels through the IP Internet (with the obvious downside of higher latency and cost).

Back to my original question: Should I be spending my time on this? You claimed that crypto was a better route because mesh doesn't scale. I'm not a crypto genius, but I do consider myself a reasonably proficient systems software engineer. I feel that if I could design a scaleable mesh network protocol stack, many of the problems we're discussing become tractable. What do you think?

> A centralized network needs to be trusted for transporting data over vast expanses...

Thanks for the reply!

You state this as a fact, but I've spent many hundreds of hours trying to prove to myself that it's not a fact. I think with packet switched networks, you are probably correct. Instead, I've been designing an Isochronous network protocol. If you could help me out with more concrete details on why all non-centralized networks are incapable of running at scale, it could save me a lot of time! :-)

> private unless an eavesdropper was physically nearby.

I completely agree with your post. I have an idea for how to resolve this via networking topology. Right now, TCP/IP seems to me to be an engine for centralizing power: Limited hop count and hierarchical address assignment leads to star topologies, leading to economies of scale that again support centralization.

I propose a network protocol stack that encourages a mesh topology, where it actually makes economic sense to physically link my home to 2 or more of my immediate neighbors. I surmise that all my neighbors (or all the neighbors of the person I'm communicating with) would have to be my adversary in order to spy on my communications (See secret splitting on Wikipedia). I feel that mass surveillance doesn't scale with this topology.

I've been working for some time on designing such a networking protocol stack... What do folks here think? Is this worth my time?

I completely agree that Cryptography researchers should evaluate their work against their moral values. I feel the same thing about pretty much all engineering... I've been focusing on trying to design moral networking protocols.

If you can settle for the Sun, and be patient... Just wait ~8 billion years for the sun to turn into a red giant (engulfing the earth, along with your remains). You may even get lucky and some of your remains may be swept away in the solar wind.

I absolutely love the concept and the underlying moral reasoning for why we need IPFS!

One of the first questions that came to me: Is there any way to add a forward error correcting code, like an erasure code to IPFS? I didn't find any discussion of this in the IPFS paper.

This seems somewhat critical to be able to compete with modern centralized storage systems which are likely to use FEC extensively to provide the level of redundancy that customers expect. Modern FEC codes can provide phenomenal levels of redundancy with less than 50% overhead. IPFS seems to rely on many fully-redundant copies?

Pretty slick tool, hope it works well! How do they avoid the Tragedy of the Commons?

You're right, but it's even worse than that. The speed of light in optical fiber is closer to 200,000 km/s.