Add some ramblings for alamesh and alanet

2022-10-07 08:52:15 +00:00
parent 7162aa1b1d
commit 8bb53f8905
1 changed files with 50 additions and 5 deletions
@@ -1,15 +1,60 @@
-> "They who control the addresses, control the flow of information" - Robby, Neal Stephenson Villain
+> "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.
+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).
+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?)
+* 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 ;)