wiki/projects/alamesh/2022-10-15_notes.md

# `2022-10-15` SaT Meeting Notes

Last SaT Robby and I talked about the mesh network/internet ideas that we've been thinking of.

We want alamodians to have their own mesh network and internet that they can take part in, host things on,
allocate addresses in, DDoS each other with and much more. This is a good opportunity to dig a little deeper
into how the internet "really works" and have a little fun.

And there's some legitimate use-cases for the network as well:
* Robby wants to host services without putting them on the public internet. He used to just rely on auth, but ended up 
switching back over to WireGuard (WG) anyways. He wants so share other services too that aren't behind auth and this 
is the "best" way to do so.
* I (fisher) also want to start to host more and more services as well. I'd like to put some internal services of my 
own up, host a CI builder, etc. I want to experiment with:
  * writing and using my own DNS server.
  * hosting my serverless functions.
  * writing my own email server (right, lol).
  * and other internety things.  
  Having our own internet makes all of the above safer and I don't need to care about hackers and portscanners messing
  with me. 

## The Old and the New

There are two overall ideas and we'll be doing both:

1. Recreate our own version of the internet. Have things like address allocation, [ASNs](https://en.wikipedia.org/wiki/Autonomous_system_(Internet)),
root DNS servers, IANA, bureaucracy, etc. 
2. Create a _new_ version of the internet, using a home-grown p2p mesh. Would likely be built on top of [pinecone](https://matrix.org/blog/2021/05/06/introducing-the-pinecone-overlay-network)
and be essentially a rewrite of the OSI stack.

Both sound pretty cool; we can kinda learn what it really means to run our own ASN with prefixes, allocate addresses 
and route things around. After a time, we'll learn why p2p networks are hard as balls and maybe we'll have two 
computers talking with each other.

# What's next?

## Determining a prefix

We need to determine a prefix for the network. [IPv6 address space](https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml).
There's some good options here. cjdns uses `fc00::/7`. Yggdrasil uses `0200::/7`. It really doesn't matter what we do,
but we should decide one something. We might also be able to use `fec0::/10`. Whatever we use, we should use the next
avaiable bit to denote a old-internet vs mesh network address.

## Peering

We're going to need to peer (connect) with each other. Basically what a fiber cable does today. We'll most likely be 
using the built in WG tunnel in the kernel to peer. We might need a custom userspace program for the mesh network, but 
overall it will be guard.

I think we should take inspiration from dn42's peering/ASN process and pretty much hard-copy them. We should just peer
with everyone for now, we'll test routing recovery and announcements with BGP

## Figuring out how the fuck BGP works

Now that we're connected with eachother, we gotta start the "real" work. I'm pretty sure this is "just" running a daemon
on a box (bird), running some config and calling it good. Automating that will be extremely useful and a good learning 
experience in linux networking.

Once we got BGP running, we'll need to setup some failure tests to check route stabilization and if BGP is actually 
working. 

## Before we start the mesh in earnst

It should be _as easy as possible_ to configure your mesh, peer and add routes. It would be nice if pretty much every 
device on one's network was peered / running the BGP daemon (iBGP for internal BGP). Idk how realistic that is, but UX 
is the key.


# Conclusion

We need to:
1. Determine a prefix. One of `fc00::/7`, `0200::/7`, `fec0::/10` etc.
2. Copy dn42 for peering, ASNs, basically everything.
3. Actually peer with eachother and test network resiliency.
4. Start hosting things!  
  * Make it easy to spinup services on internal networks.
5. Design doc for p2p network.