3.4 KiB
"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.
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 ;)