In the latest Dev-update there are some nice links found to flowcharts about bootstrapping and node discovery. Quite a great starting point for understanding the more in depth functions of SAFE. This topic is meant to understand how the bootstrapping of a node works. I hope others will join this road to discovery. We should only poke the Dev’s when we really get stuck in the system. Until that moment I think we can do an amazing job discovering the inner workings of Routing and Bootstrapping.
Here’s the top part of the bootstrapping flowchart.
So what do we actually see? There are 4 addresses named:
- Address A
- Address B
- Address X (NAE Manager of A)
- Address Y (Relocated close group of A)
Address A and B appear to be on the normal IP-level. Address X and Y appear to be in XOR-space.
When the Client connects to SAFE it starts at IP-level. In this case we see that Client (A) connects to an IP-address (B) and provides it’s public key. If Client (A) is new to B than B will add Client A to it’s Client map. It will also provide it’s own public key to A. That way fully encrypted communication is guaranteed from the start. B will also provide the current quorum-size and that’s very interesting. Quorum-size is on XOR-level isn’t it? It seems that node A is the Client and node B is the Relaynode for A. And what did we learn about the Relaynode??
So B seems to be both in IP-level and XOR-level and I guess that’s why quorum size already comes in so early. We now have communication between the Client(A) and it’s Relaynode(B). The next step for the Client is to get a Networkname from the NAE-managers:
To: NAE Manager(A)
This is the part where the Client(A) tries to join SAFE on XOR-level. It can’t create it’s own XOR-address (NetworkName) so it needs other nodes on XOR-level to provide one. It doesn’t connect directly to the NAE-Manager but uses it’s Relaynode (B) as a “proxy”.
Okay, just a start. Feel free to add, correct, extend or whatever. We’ll take it step by step to get errors out and get full understanding ;-).