> "They who control the addresses, control the flow of information"
>   - Robby, Neal Stephenson Villain

ALANET is the private internet in which alamodians host services for eachother. Alamesh is the mesh
on which that internet resides.

This document describes some of the features of the mesh and implementation goals. The goals are
essentially ripped off from [cjdns](https://github.com/cjdelisle/cjdns).

## Goals

* IPv6 between nodes.
* Allocating an IP address is the same as generating a crypto key pair (necessary? do we want to
just make our own verison of ICANN?)
* Peering is as easy establishing a tunnel with someone else.
* ...?
* Our own custom implementation of WireGuard?
  * Using the noise? www.noiseprotocol.org
* Learn BGP

## Discussion

The mesh aspect of it should really only be for peering. The underlying ALANET protocol (if we
stick with a custom proto/ipv6) should not know about peering, the fact that it uses wireguard (?),
etc. It's peerly (heh) a way for alamodians to easily peer with eachother.

So most of the above goals are for ALANET which runs in `fc00/7`. What we need to do is create
wireguard tunnels that forward ALANET traffic. However, since ALANET may be a new transport proto
(not QUIC but with similar ideas?), we may need to have a different tunnel which then fowards to the
actual egress tunnel? That seems kind of stupid, it would be nice if it was all-in-one.

Maybe alamesh and alanet are combined into one userspace (or kernel) tunnel but there are clear
boundaries in the code between the mesh and networking parts of the code. Mesh just handles the
connection and the network part of things handles all of the routing and actual data transfer.

## Hole punching?

Do we want to essentially mimic tailscale (isn't it open source?) and try to connect directly to
machines, or do we want to just tell people to spin up a cheap server somewhere (Don't most people
already have a cheap server somewhere?). Or rather, we let people host their cheap servers or we
let everyone connect to a server themselves. We keep the idea of peering, but it just happens to be
one the same machine? I'm not the biggest fan of that, because it centralizes the mesh topo while
still forcing ALANET to be mesh-like. I think I'm rambling at this point.

## Implementation notes

Peering should be _stupid simple_. Everyone has git, why don't people just open PRs to a git repo
with all of our WG public keys and then add their own key if they want to peer. Bam. Once an hour or
daily we can pull changes to our keys (or listen to a webhook?), refresh the tunnels and we're
done. We could also just manually send our keys to people, but that's no fun. The problem with that
is, WG routing. We can't have multiple kernel WG tunnels that all accept traffic on `fc00/7` since
the kernel would not know what to select. That leads me to think we need a userspace program that
maintains the tunnels and does the routing... So we can't use the kernel's WG tunns, which is fine.
Just means we need to write out own.

The actual routing between peers I guess will be done with the new ALANET protocol. I like the idea
(from cjdns) that a crpyto key is all you need to generate a v6 address. How we share those keys or
how we route (without the tree structure routing becomes... interesting) is up in air, but I like
the idea of people being able to arbitrarily generate keys for services and just start hosting
them. DNS can come later ;)