Quite a read, but very clear and thorough. Seems things have evolved in a few areas so it is very useful to have this all laid out in one place.
Not an easy thing to write I suspect, but a great job IMO.
Thanks 
Yes Paige did a grand job here. Should save a load of questions (I hope). As we move through the tests there will be more I am sure.
This was a long time coming. Glad it’s finally released.
Huge thanks to @AndreasF and @wumpus for helping me refine and clarify technical points. @nicklambert is always a helpful grammar editor even though we do disagree on comma usage a lot of time. 
I’d really like to do a write-up of data on the network next… think that’s another big part of the network that could use an overview. The mechanics of safecoin and PoR is also of interest but I’d rather wait until the team is actively working on it or after the first implementation.
Yes, this was a bugbear for outsiders I think. Very nice to have it all laid out in one place clearly and up-to-date. Shame I’m not clever/technical enough to understand much of it 
Well done though… quick translation into Chinese maybe? 
I’d be interested in understanding where things fall apart for you. Was hoping to not make it too technical but I guess that’s difficult if the goal is to technically explain the consensus.
Oh absolutely, I don’t think it’s prolix or unclear in any way, you’ve done a great job. I just think most of this stuff is a bit esoteric by nature and I’m a total tech-tard doofus, so it’s like your grandad not getting it… I’m sure that to anyone with even a basic grasp of the technical side this is a simple and clear walk through.
Great job with it!
Terrific big picture work on this one especially with the diagrams…cant get enough of em.
Yes, let’s see more pictures, to help us autistics.
For each client connection into the network, there is an anonymising proxy node which relays all data to and from destinations within the network, but the proxy does not have the ability to read any of it (for those familiar with Tor, this function is akin to a “guard node”).
So the client connects to the network using a relay_node. But the vaults connect without a relay_node. And the vaults are the client_managers. In other words, the close nodes are close vaults when you connect on XOR-Level.
The illustration below shows relationships of a Client (n) and the closest online Vaults which make up their ClientManager (n+2, n+5, n+7, n-8)
So, when we look at IP-level it looks something like this:
- I’m at home with IP 11.22.33.44 and connect to a bootstrap server from Maidsafe.
- I get a relay_node from that bootstrap server. Let’s say with IP 77.88.99.66
- A get_networkname request is done, so the relay_node is on XOR and sending out the request.
- A group picks me up, I get public keys etc. I join that group of client_managers which are vaults on the network.
Now the next part is where I have some questions…
- I’m connected to only 1 IP which is the relay_node?
- The relay_node has 32 IP-connections directly to my vaults (client_managers) and 1 to me?
- Is it just 1 relay_node to join a group of say 32 vaults (client_managers)? Or are several relay_nodes involved here? How is decided which relay_node serves which part of the group?
In tests only, you will have parallel connections at launch though. We do’t trust individual nodes so you will confirm via several (prb 3) routes. So it will mean more traffic, but probably necessary. Also 3 means we can cycle as these churn and clients should not be affected. Unless you connect through your own local vault So room for a vault to be integrated into launcher for ease and safety.
it has connections to it’s group (plus normal kad routing table entries). Your message are routed to wherever you want (your ClientManagers for Pu and DM for Get/Post/Delete).
This is probably answered in the first question (I think), shout if not.
I can’t decide if I like this more formal post, or your original late night mental struggling stream of consciousness blog post (likely at 4am).