PhaseMage

Hi! I'm Travis Martin, the creator of IsoGrid. Let me know if you have any questions!

Yes, absolutely, nodes set their own rates. I've tried my best to keep economic decisions local. Nodes that steal the credit payment can be detected: And an algorithm can and will be built that detects it, and subsequently sends it's business elsewhere.

Great questions! Happy to answer them :)

Is there an implementation: Not yet. I have a prototype implementation of a link layer and I've prototyped parts of the network layer and transport layer. But only enough to convince me that the general isochronous design is workable.

Yes it uses Source Routing: I've spent the last few months working on the (extremely important) scalability question. Section 13 of the spec deals with this in detail, essentially specifying the 'BGP' of IsoGrid (HashMatchLogMap) so that nodes don't have to specify their own 'hosts' file. I think I've come up with a protocol that scales O(log(N)), where N is the number of nodes on the network. It will definitely have a large constant: The base algorithm starts with just always tracking the 10k or more nodes that are cheapest to access. The algorithm scales because the addresses of nodes contain a Geolocation component, which means it's easy to ask for directions from nodes that you already know about that are both physically and logically (HashMatch) closer to a desired node. My next step is to start implementing this protocol such that I can test it on a simulated large network (I'm thinking I'll build the simulated network dataset from OpenStreetMap).

Not sure what you mean by 'tool', but micropayments are sent along with the data. If a node only has one link to the IsoGrid (Comcast), then they are doing it wrong: The node should use the cheapest routes that meet the desired latency/bandwidth requirements. Competition means that "highway robbery" should cease to become a viable business model. If a node along a route decides to just steal the entire micropayment (rather than just their part) then data stops flowing on that route: The source uses other routes and the robber ended up stealing from it's own neighbors.

Hi there! I'm Travis Martin, the creator of IsoGrid. Let me know if you have any questions!

The TCP/IP Internet is also an engine of centralization. By limiting hop counts, and distributing addresses hierarchically, we end up with just a few giant players in each industry.

For the past 20 months I've been designing a new mesh network protocol in my spare time, and I'm planning to incorporate (obviously as a non-profit) eventually, but haven't pulled the trigger because I haven't needed to solicit donations. I already have a WordPress site up and I know how to maintain it, but my web/graphic design skills are seriously lacking (I'm a systems guy).

The site (and my proposed Protocol Stack Spec) is at isogrid.org. If you find the cause righteous, I'd love the help!

The TCP/IP internet is irreparably broken for real time applications. The barriers to new entrants wanting to do the same thing as Riot Games is too high.

I've proposed a scalable mesh network, see IsoGrid.org

I've been looking for something like this quote from the original World Bank report:

“The economics of the internet favor natural monopolies, the absence of a competitive business environment can result in more concentrated markets, benefiting incumbent firms. Not surprisingly, the better educated, well connected, and more capable have received most of the benefits – circumscribing the gains from the digital revolution.”

My assertion is that this is actually due to the nature of the TCP/IP protocol. IP addresses are assigned hierarchically and packets have a hop limit. Together, this makes a mesh network impossible. The TCP/IP Internet is an engine that centralizes power. I'm working on a side-project to create a (free and open) scalable (wired) mesh network protocol.

I'm really glad I saw this, it'll make a perfect citation for my requirements doc. Anyone disagree with the above? I'm looking to try to strengthen my arguments.

I'd hate for Midori to be lost to the sands of time. Any chance it will be open sourced?

The study relies on isochronously spoken words!

Inside joke: I recently published a network protocol that relies on sending words isochronously between switches.

I'll take this as validation that I'm on to something :-)

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.