I think the typical approach to the bottleneck issue with regard to traffic analysis attacks is that the machines on the edges can act as mixes. They can essentially launder traffic from within their respective meshes so that any intermediary between them can't do attribution. Of course, you have to trust the mix! So what then? Then communication to them has to be encrypted and onion routed, and moreover, continuously sent (even if what is encrypted is the message, "No data here dummy, this is just chaff") and then that has to be sent along, all so the mix doesn't know that you're actually communicating anything.

It's a whole category of research really. Papers like Herd at Sigcomm and Vuvuzela at SOSP are the two latest I've seen and following references there should be helpful. I think if you look at Herd there are a few tricks in there to lower the cost of all of the chaff with the superpeers (or whatever they call them, I read it a while ago). A hybrid system that mixes meshnet schemes for local peer to peer traffic with secret sharing schemes and mixnets for more disparate networks seems workable to me. The question is what benefits does the meshnet provide over the mixnet style schemes?

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.

I see. I'm not sure if all of these things are fundamental to TCP itself, but instead are economic and regulatory results. Something to think about. It's not my area so I don't have specific cites, but data centers are effectively meshes. I know there has been work on different ways to transit data within them other than stock TCP/IP. Network coding, for instance, is a pretty cool way to splat data among a whole bunch of interconnected people and UDP to all your peers is a good medium to do it over. There's also work on multipath TCP (MCTCP, others) to help utilize other idle links.

I'd check the literature on that, typically under the data center track at networking conferences.

Unfortunately, the other thing that doesn't scale with this topology is the network itself. A centralized network needs to be trusted for transporting data over vast expanses of underpopulated areas, or even urban bottlenecks (e.g., LA communicating with SF)).

Ignoring this fact makes most "mesh" seem like the answer, but the real answer, especially pertaining emergence, is continual improvements in encryption, etc., not a replacement of the entire construct of the Internet, which itself is emergent.

> 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! :-)

Just a quick thought experiment (because my networking expertise is limited):

Take a single computer at the edge of town A. It's the only machine in town A that can connect to the next town B, because of the distance between town A and town B. All traffic in town A now has to route through this machine to reach town B. How will a single machine achieve this?

Even worse, what if the two towns are too far for any connection other than a centralized style connection (large wires on a pole).

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?

I think mesh doesn't scale is a pretty valid network assumption, in the general case.

So. Maybe an interesting question is: What sorts of applications and protocols will work in a mesh topology? That set might be interesting. For example, you could imagine big chunks of Nextdoor working well in a mesh topology, since it's already a geo-limited social graph by design.

I think the answer to your question is here today, if not that popular yet. Lambda.

After that, the next step might something as open and decentralized as Ethereum.

You mentioned a tunnel. That's exactly what I mean. If the Internet itself wants to constrain and control us, we can just create a new Internet inside of it, at their (e.g., ISPs, backbones) expense. The result is a system of protocols in communication standards that can be distributed across on trusted hardware, which lens itself well to a future, more open and distributed Internet, at a point when these types of things become illegal on the existing Internet. In other words, work with what we have for now, building up the necessary tools and infrastructure from the inside.

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.