Mesh Network

This is meant to sit above the TCP layer, but with the modification that routers and computers should connect directly.

Requests fall into two categories, static broadcasts and dynamic response. A static broadcast of a resource means that any node can fulfill the request. A broadcast has two parts, the message and the signature. The message is the data and is unencrypted. The signature is a hash of the message signed with the originators key. A dynamic response follows the same format, but is encrypted for the originator of the request.

Static Broadcast Request

Request

• Topology of requester
• Public key of content-owner
• Resource Id (up to 1kB)
• Optional: topology of resource

Routing

The message is routed until someone has the resource at which point a response is sent. The responder does not have to be the content-owner, they can simply have the resource cached. If the topology of the resource is included, it will be followed. This can be modified by any node along the way. This may happen if a better topology is found. Nodes also have the option of attaching a processing time before re-broadcasting to help establish local topology.

Response

• Topology of requester
• Message
• Signature (signed with public key)
  • Hash of message

Dynamic Response

Request

• Topology of requester
• Public key of content-owner
• Encrypted (with recipient public key) message
  • Request-data
  • Signature (of requester)
    • Hash of request-data
• Optional: topology of recipient

Routing

The message is routed to a server that can answer on behalf of the requested public key. Again, the topology can be modified along the way if a better topology is found. Nodes also have the option of attaching a processing time before re-broadcasting to help establish local topology.

Topology

This will be very complex (and I need to research it more) but every node knows their immediate surroundings with reasonable accuracy. When a node enters the network it identifies itself (sends a list of public keys) to all its neighbors. The neighbors respond with a list of public keys and the latency to get to them (any public keys they hold will be marked 0).

To maintain network topology, nodes will occasionally ping each other. To keep chatter down, this should be done minimally.

Broadcast Identity

• List of public keys (that this server holds the private key to)
• Protocol

Identity Response

• Dictionary of public keys and latency
• Optional: protocol (if requesting different)

Ping

• One byte
• Optional: perceived latency

Ping Response

• Return sent
• Optional: Delay request
• Optional: Do not send latency
• Optional (Only ONE of the following):
  • Return ping (also one byte)
  • Retry request (if server was busy and ping time may not be accurate)

Econ

This gets really complex. I'm not sure how to actually achieve it.

While maintaining the self-organizing nature of the network, nodes also need to be in competition. Devices automatically choose a route based on speed, cost and reliability. Every node utilized along the way gets a cut.

This of course brings in all sorts of complications. There needs to be a pseudonym and reputation system. There needs to be a way for user to build and collect tabs. Or, alternatively, there needs to be an entirely new way to think about both networks and wealth.

Phases

1: Nodes

Get a design out for a simple bridge node. This lets devices on the local network connect to the mesh and use the internet as a bridge. These nodes can also be used as servers. Hopefully, we can create a design using cheap hardware like the RasPi.

2: Point-to-Point

Again, the hope is to use cheap hardware. But this time, it's for longer distance, narrow beam communications. Something like off the shelf laser diodes pointed at each other over a few miles (I have no idea what realistic distances would actually be). At this stage, the network could start to be useful, at least in more populated areas. Just a few people connecting with point-to-point and running servers would give people access to resources without utilizing traditional network hierarchies.

3: Growth

As individuals on the periphery find the network useful, adoption should spread. I hope that the draw of earning money from running nodes as well as having access on an a-la-carte basis should bring people in. In this phase there should start to be connections between nearby cities and efficient bridges (people or organizations with access to high bandwidth internet).

4: Replacement

At a certain point, individuals should start to feel comfortable without a traditional wire. Reverse bridges (connecting to the traditional network through the mesh) should start to arise. Somewhere around this time we should see a tipping point.