New user router, Eth, IP address provision

Althea L1 Development
1

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:

  1. Nate’s router needs an Ethereum address.
  2. Nate’s router’s Eth address needs to have enough funds to cover the IP leasing/renewal fee.
  3. Nate’s router needs to be given an IP address that is in the subnet’s range, and is not already taken.
  4. Nate’s IP address and Eth address need to be added to the subnet DAO’s node list.
  5. 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.

Implementation

1

Let’s assume for now that routers either come from the factory with a unique Eth address, or generate one on startup.

2

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 ip_addr->eth_addr
  • 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_addr by 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).

5

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.

2

I suggest we have a simple constant of pause period. The longest an address can be on the pause list before being returned to the available list.

3

Update to DHCP: We will simply have the frontend get a hashmap of all IPs, then randomly generate an IP and check it against the hashmap, retrying if it is taken.

4

Let’s actually skip the frontend getting the hashmap, since collisions are very unlikely.

5

Just had some more thoughts on this. From the althea_rs perspective this time. @michal @drozdziak1

  • The new user needs to startup and connect to a peer, as a non-paying not verified peer they get some minimum amount of free bandwidth and traffic watcher doesn’t attempt to bill them (it may at some point have abuse prevention stuff to look for but right now it just shouldn’t watch.

  • The user must sign up for an exit and the exit does something similar, it registers a new user and gives them the minimum free bandwidth.

  • It is now possible to access the list of configured web3 nodes, allowing for queries to the blockchain including signing up for the subnet dao and buying some eth to pay for bandwidth.

  • The bootstrapping router can now present proof that it is on the subnet dao to it’s neighbor as well as open a channel, this prompts the neighbour to change the tunnel state from ‘unpaid and unauthorized’ to ‘paid and authorized’ at which point normal operation may proceed. The bandwidth restriction is lifted and the client inserts it’s own forwarding rules to allow user traffic to traverse the router.

On the dashboard side @Adam_Soltys

  • The user needs to get redirected to the dashboard until signup is complete, exactly how to do this will require some router shenanigans (probably with a dhcp redirect which althea_rs will have to manage) and then the frontend can query the config and see if everything was setup correctly. Moving to the right step.

  • this wizard like interface will shepard the user through the first setup and allow bootstrapping to complete, parts of it will also show back up when for example the user is no longer on a subnet dao for some reason or they are out of money required to open a new channel.

Now in the immediate timeframe I would like to start by adding ‘authorized’ states to the tunnels in next weeks sprint. This will require

A) Querying web3 nodes against @Sebohe’s subnet dao alpha to check membership/authorizaton
B) by default restricting bandwidth and this unrestricting it (probably we should make a dummy rule for now, so we can test without breaking people’s access)
C) unrestricting once a node is on the subnet dao.
D) some component for joining on the web-interface (how viable is this @Jehan @Adam_Soltys?)