This is how people get a new router, an IP address for it, and get onto their local Althea network.
Nate goes on a website showing the Althea global TCR, and finds a subnet DAO serving his area. He goes to a meeting or whatever, and talks to Judy, who is one of the organizers. He decides to get on the subnet and get a router from her.
Now there are several requirements:
- Nate’s router needs an Ethereum address.
- Nate’s router’s Eth address needs to have enough funds to cover the IP leasing/renewal fee.
- Nate’s router needs to be given an IP address that is in the subnet’s range, and is not already taken.
- Nate’s IP address and Eth address need to be added to the subnet DAO’s node list.
- Code needs to be set up that will “pause” or remove Nate’s IP address and Eth address from the node list if his renewal fee escrow contract runs out of money. We need to decide when this code will be run.
Let’s assume for now that routers either come from the factory with a unique Eth address, or generate one on startup.
Nate will need to load up the address with funds bought from an exchange. Judy can show him how, or even sell him some crypto for cash. This is actually better than Nate needing to buy the funds while setting up the router at home by himself since Judy can walk him through it.
3 and 4
This is where the DAO specification starts. We are using Aragon, which provides a set of contracts and a frontend for this kind of stuff. We will make an app for this framework called Node List. The Node List app will have a smart contract which contains:
- A mapping of
- A constant containing the ip range allocated to the subnet DAO
- Facilities to hook into Aragon’s permissioning/voting framework to allow Eth addresses to be added and removed based on votes of certain percentages of subnet organizers.
- Functions to add or remove from the
ip_addr->eth_addrby Aragon’s voting etc facilities. The node addition function will have to run a dhcp algorithm to assign an ip address for a submitted eth address. This could also be done on the frontend, which would do dhcp itself based on its view of the existing node list and simply submit an ip and eth address pair to the blockchain. However, this might be prone to collisions from people assigning IP addresses at the same time, so we will do dhcp on the blockchain.
We also have to consider how the process looks to the humans. Let’s say that Judy gives Nate a router fresh from the box. Then Nate plugs it in, connects to its wifi hotspot, and checks the eth address. Judy opens her Aragon interface, types in Nate’s Eth address (might be better yet to have a way to scan in a qr, maybe if Judy runs Aragon on her phone). Now Judy hits the “add node” button and the frontend submits Nate’s eth address to the blockchain where it is given an ip address. After the transaction confirms, the frontend shows Nate’s IP address and Nate can type it into his router (again might be good to have a qr reader).
If Nate stops paying his IP leasing fees, he should not be able to use the IP any more. The simplest way to accomplish this would be to simply have the renewal fee escrow contract remove his address from the list and make it available for re-use. However, this would require him to contact a subnet organizer to get it reinstated. Another way would be to pause use of the IP address. Other nodes would not be able to connect to Nate, but his IP address would not be given out to someone else. Once Nate refilled his renewal fee escrow contract, his IP address would become active again.