-====================================================================================-
| David Irvine - SAFE Network, Technical Overview of Routing (Clean) - Transcription |
-====================================================================================-

Excellent. Alright, guys... Routing! So, now that we've got Sentinel, actually Routing becomes... much, much simpler.

One of the hard things about Routing, I think, is that XOR, this XOR thing. The XOR distance, and whatnot, is very, very difficult to get your head around, and to try and reason with. Especially, it seems the more mathematical we are, the more difficult that is. Uh, so I find it easier! But, um...

One good thing about Routing is, all that XOR information is in the Routing table. So, when we want to do something, in Routing, like work out, "What is the distance between A and B?" Or, "Is A closer, than C?" The Routing table does that. Now, you can't have, "Is A closer than C," because you've got to do "with respect to," whatever, some target. So, one of the main things to know about Routing is, this Routing table handles the XOR relationship. Same thing to do with distance, or measurements, or any of that sort of stuff: that information is in the Routing table.

And, initially the Routing table, when the Routing table was written in this sort of previous version of Routing, there was actually an [??] in it. That said: "Don't ever change this." "Don't ever touch this." Because, the Routing table's got stuff in it, that you look and think, "That's not correct!" Like, "You should be able to sort something, without having a 'with respect to.'" And, any time you do---any time you touch this Routing table, you should be sweating blood. Because, you should be in a position where maths doesn't make sense anymore. And your head's got to be in a place that can cope with XOR stuff.

So, just, the Routing table on its own, we could probably spend... days and days, going over, in how that works. But, Erik has done some pretty good presentations, and videos about the Routing table, and the whole XOR Networking thing---and things like: distance, and closeness. All these relationships are not obvious. But Erik's covered all of that. So, I figured today, just to say that: anything to do with distance, closeness, or whatever, is in this XOR space, and the Routing table handles that for us.

And, the main... the Routing table is critical, in Routing. And... in a previous version of Routing, we totally screwed up. The version of Routing that we had in C++ has got, enormously screwed up logic. It's completely insecure, because of enormously screwed up logic.

And, here's the fundamental thing, about Kademlia-based networks. If you take the Routing table, it splits in two. So that's, eh, bucket... I think we've called this bucket 0. Then it splits in two again. So, bucket 1. And it splits in two again, bucket 2. Splits in two, bucket 3. All the way to 511. Now, if you imagine that the whole XOR address range, from "you" to "!you" the complete opposite of you---so, you may think 0-FFFF. But you can't think 0-FFFF. You've got to think from "you" to the complete opposite.

The way that the system works is, and it's got to work like this, you know some information about this part of the network. So bucket 0, you know some information. So let's call that information, that you know... 1,000. So you know 1,000 of this piece of information. Your knowledge, if we could measure knowledge, ranks 1,000... there. This bucket here, the knowledge that you would have over this bucket, would be 2,000. You would have double the amount of knowledge you do of this bucket than you do of this bucket. This bucket here, 4,000. 8,000. So, as you send a message, across an XOR network, every bucket that you send the message to---so, every bucket you send a message to, if it's just one [??], we'll have 2x the info.

And, I think the easiest way to explain it in layman's terms is, if I was sending postcard to somewhere in, I don't know, Mexico, Cancun, I would have very little information that it makes. Well I might know what continent it's in. And it will go to that continent. So it will get to South America. South America, they would know where Mexico is, so it goes to Mexico. Mexico, they would know where Cancun is. In Cancun, they would know where the local post office is. The local postman would know where the street is. And when it goes through the door, the family would know who's supposed to get that letter.

So, when you're going in an XOR network, it's a lot like getting a letter delivered. The next step knows more than you do about the target destination. And the closer you get to the target, the information has been building, and building and building and building and building, until it's at maximum. And it's at maximum, the closest you get to the destination. So, in an XOR network, you always have your message going to where there's more information known about it.

In our previous network, we did something weird, to where we would get to here and then send a message to [??] [??] network, and then send it back, and all the rest. So we had a massive logic error. That massive logic error leads to hundreds of extra [clog??]---all of which is invalid, all of which has bugs in it, and you're never ever going to get a network that works. Apart from being insecure, we weren't checking signatures and stuff. That was a disaster.

So the key element in Routing, really, is this Routing table, which handles this relationship on the network: of closeness, distance, and knowledge.

Now, in a peer-to-peer network, in a Kademlia-type thing, it's a single view of knowledge. You always get more knowledge going closer to the target. You never ever ever get more knowledge going anywhere else. You've got to go closer to the target. So, if you've got a node 001101, and you're trying to send it to some target 1... blah blah blah blah blah. And the next Node here, has got a 1 there, so it's getting closer to the target, just by one bit. Just one bit closer, is 2x the info. 1 bit farther away is half the info. It never ever changes. So in a peer-to-peer network, where all peers are equal, the distance, er, the direction of travel of messages is critical. If you break that rule, or break the Routing table, nothing else matters, nothing's going to save the network; it's completely bust. So, in Routing, we should see the Routing table as close to god as we can possibly get.

And knowing that the XOR stuff, working with XOR is the best non-linear, non-Euclidean way of thinking. And one thing that over the years of working with that stuff, I think what we've realized in-house is: regardless of what expert we're speaking to, professor, whoever, from whatever University---when people make an assumption that's based on linear thinking, it's almost, almost 100% wrong, entirely. So, when we are looking at stuff in XOR space, or relationships between nodes, the amount of non-linear thinking is huge. The only way to make changes to that Routing table, is to get into that whole mindset, and do some measurements, actually measure your assumptions. (So, for security and whatnot in the Routing network, we're all a tool, that actually... creates a distributed network in XOR space, and then measures things about that network.) I've yet to meet somebody that can put the XOR thing in their head, and actually keep it there, and keep thinking that way. I've not come across anybody that can. But nearly every expert I've came across trips themselves up, continually, in this space.

So what I'm trying to get at, and I hope I'm making a point is, the Routing table is the absolute key to Routing. Changing that Routing table should make us completely petrified, because you could make a change that looks correct, it looks like the tests are still working... and the whole network will actually collapse. It will break. There will be security things. Stuff will happen, that's incredibly bad. So, the XOR thing, nothing wrong with working on it, but if you're working on the XOR part on the Routing table, do not be considering anything else like sleeping, eating, and all the rest of it. Really get your head in there, and stay in there until it's finished, and come out again. It's a hard, hard, hard, hard thing to do.

So, in saying that, the good thing is, the Routing table is written. It seems to work. There's a fairly substantial test, which works. It's pretty complex. I'm on the fence whether it's too complex to be the only test we could have. I think that something like Routing is a prime candidate for a library dedicated to testing it, not test inside Routing itself. I'm not saying we shouldn't have tests in Routing. I think we should have that tested as much as anything else. But it's probably a candidate for another library that completely simulates massive networks, and tests some of the logic itself. And just keep that in mind.

So, in saying that, Routing: so what is the purpose in Routing? So, in our case, the purpose of Routing for us is, along with a transport layer, like Crust. Crust is a transport layer; Routing is a Routing layer. And between the two of them, they give us the ability to implement a DHT. There's lots of DHTS: there's Kademlia, there's Chord, Tapestry, Pastry, there's umpteen DHTs kickin' about. Kademlia is probably the most commonly used one. And our Routing table is based on Kademlia-like Routing table, but it's not; what we have is not Kademlia, and it's quite different.

So, in a Kademlia network, let's just look at a KAD network. What you generally have is K, a value of K, which is replication. So, that's K. That's a number of copies you're going to make of something. And you'll have Nodes. Let's say K = 4. We're going to have 4 copies of stuff. And these Nodes are in the vicinity of ABC. You're storing ABC; you store it to these Nodes. And they keep ABC as a key; and whatever value. That's primarily what a Kademlia network does. Couple of things: they, here, would have a time-to-live (TTL). That defaults generally to 24 hours. So when you see things like Bittorrent or mainline DHT, all these things, they're based on a Kademlia network, which works on this way here. So, the TTL, 24 hours, and that's generally a republish time. And basically what the network says is, I'll store this for 24 hours. And then I'm not going to store it; I'm just going to drop it." So these guys will have a 24-hour timestamp. And they'll timestamp that, and keep that thing for 24 hours.

So, it's a peer-to-peer network, which kind of means, nodes are going to drop. These guys are whoever's computers. We are not in charge of them. So they're going to drop. So this guy here disappears, and there are some other guys in the vicinity. And Kademlia... does nothing. So that node drops. There's only three copies now. Nothing happens. (Normally, your key is 8, or 20. In most distributions of Kademlia, the K is 8 or 20.) So, nothing happens here. And another time goes past, and that guys goes, and then we will get two copies. Nothing happened; nothing's going on. Then, the nodes get to a republish time.

So, republish is what nodes do. And they'll do it every 1 hour, as the default time to republish data, on such a network. And what will happen is, these two guys that are left, will store ABC again. And the ABC will stay here, and will stay here; and it will maybe go in this guy, and maybe another guy's appeared here. So, we've got 4 copies again. Then the next time 1 goes down, a half an hour goes past and then republish happens, up until the 24 hour period; then the whole data drops. And the client here, has to republish, before the 24-hours is up. And then he can overwrite ABC, because there's no way that he can tell it not to overwrite it, because there's no ownership... information on a DHT. So you can overwrite on a DHT if you want, anything, because there is no ownership. It's why you won't ever see delete, on a DHT either. So this guy is going to have to republish ABC. Of course somebody else can publish ABC and overwrite this guy's data---which you can do in Bittorrent networks, not a problem. So there's this lack of ownership, and there's a time-to-live, and a republish.

So that's one thing that's different. That's a normal Kademlia network. The other thing about a Kademlia network that's interesting is: they're iterative. Kademlia networks are iterative. So you have a guy here, A, and he's trying to get to ABC group. So obviously it doesn't know the ABC group, and he's going to have to find him. So he'll ask K... so if we say K is 4 (as we said, normally it's 8 or 20), he'll send K messages to the closest Nodes that he knows of, to ABC. And they will reply to him, with the K closest that they know of. And he will accept a minimum number of these replies. So, say he will accept 3. And once he's got 3 of those replies, he's sourced his new Routing table again with this additional information, and sends another K messages out. Then they come back. And this one could have come back, the 4th one of the thing could have come back in the meantime. These guys come back; he sources Routing table again. And then maybe he's got to here, after a certain amount of iterations. And if you look even in 2 iterations with a K of 4, you've got 1, 2, 3, 4, 5 6 7 8. 8 holes you would have to put; 8 things you would have to punch in through your router.

Now if that was 20, and you're looking at 10 iterations, that's 200 per request, holes getting-- and if that was on a LAN, this router's getting pummeled, where holes are getting-- all the UDP ports opening. And our UDP port holdings are all still for 20-30 seconds. So if you've got a bunch of these guys in the network, with this iterative approach, you're going to get slammered.

Now, that's not all. So an iterative approach, and you see, I said earlier that guy goes off, nobody even notices. Nobody knows he's been off. So let's say this guy was called X. These fella's here, after several iterations, know X is quite close, and they'll send back X. "You should be speaking to X." This guy here will send out to X, who's not there anymore. These guys haven't been told that X isn't there, so they're keeping him in the Routing table, as a dead node. So these messages that are going to go to X are going to time out eventually. And nothing happens. These guys still think X is there. This is a normal DHT. Now, there's a thing called, down-list notification. And when this happens, this guy here should go back to this guy, and say, "X doesn't exist anymore." And then this guy should actually try and ping X to see, "Is this guy telling me the truth?"

And you get into this-- you get into this way, that... this network gets pretty confused. There's a lot of traffic that happens. During the refresh time, these guys will all try and refresh at a 30-minute thing. So you get a flood happening. And then there's an improvement called Beta refresh, to try and make these guys refresh at different times, based on some factors, to try and improve that refresh. But for a period of normally an hour, you don't know how many of these nodes have been off. You've got copies disappeared, you don't know about these guys. And you hope that K is big enough that the whole group doesn't collapse, and doesn't disappear, and take your data with it.

The Data itself is not keyed. It's just basically a key and a value. There's no type of data; there's just one type of data. And it's whatever type that's got that key and that value. So you don't get immutable data, mutable data, structured data; you don't get that. You just get data. It's a key and a value. It may or may not be there. It's very inefficient. There's network flooding that happens. You don't know when nodes disappear. The refresh rate will determine how fresh your table is. The longer you're on without a down-list, the longer the Routing table gets poisoned that you're in, and you give off bad information to people.

That's a normal Kademlia network. And it's enormously successful. Hugely successful. You don't often hear that Bittorrent's not working, or, you know, some of these DHT's just, are broken. And the iterative thing knocks lumps over routers. These guys don't know if a group's really there, or if they are the closest group. We don't know how much of our Routing table is poisoned and not poisoned. And we really don't know if the data is there. And even if it is there, we hope that the guy who put it there is going to publishing it again somewhere.

So, with all of those errors, all of that extra traffic, all of that bad information in the Routing tables, this works. And it works probably better than a server-based system. Bittorrent certainly seems to be able to download information much quicker than extremely expensive servers. And it's based on people having a computer on, running a program for just a little while, not for a great big huge amount of time, not incentivized whatsoever to do so, and running a piece of software which does this, which has got all these errors.

So, one of the first places to attack for us, really, with the Routing thing, is this refresh thing. So we look at the refresh, and we say, this is the group for ABC. Now, if we increase the refresh... er, decrease the refresh timer, so increase the number of refreshes, this group will be more accurate. So, if you have a refresh time of 0, or as close to 0 seconds as you can get, you're going to get the most accurate DHT that you can imagine. That's one thing that's interesting.

Another thing is, DHT is quite an academic thing. So you've got your client, and you've got your router. And as I said, when he's doing iterative look-ups, he's going to knock lumps out of all the opening UDP ports in this router. And if there's a couple of them, they're really going to knock out lumps out of these routers. So the UDP port usage is going to be ridiculous. So, this is where introducing... take away the iterative approach, and make it recursive. So you've got your router, and you're going to have a fixed number of ports used. So in our case, 64. We're going to use 64. Regardless of the number of iterations that we use here, the number of searches per second or whatever, these are the 64 ports that are open. We're not knocking the lumps out of that router. So immediately we've got something... quite good happening.

Now, the recursive thing for us means, use Crust. So we take all the UDP type, connection-less connections, and make them connection oriented. Which means-- and your group here, these guys, are all connected to each other. And as soon as one goes off, and if it goes off gracefully, we will get a message coming back. We know immediately that that guy's going off. And immediately these guys can go into a republish mode... immediately. They can refresh as close to 0 as is possible, using network technology available to us today. So if we've got a graceful log out, we'll know within milliseconds. If we've got an ungraceful logout, a collapse, a network going off, a DHCP change of address or something, we'll find out, in... seconds. It won't be minutes or anything like that.

So if you take this 60 minute thing, of a normal DHT, to get its Routing table rate, in terms of refresh---you'll never be right, in terms of dead nodes, because you're screwed there. If you take that 60 minutes, and go down to milliseconds, to seconds, that's how much more accurate your DHT is going to be for a start. So that was a good thing to notice. That was a good thing for us to find out, that we can bring this refresh thing down.

Another thing is, you're connected here, and we're doing this iterative thing. So if we were able to actually---and again, this is the non-academic side of Routing; this is a real-world thing---this guy has to have a listen port that's available to the world. Here, we can punch a hole through that router, and get a listening port, whether you use hole-punching, or if it's TCP, uPNP, not PNP or whatever. And once we've done the work of getting that information, the network can be told about it. The network could be told, "This guy has got these listening ports available." Also, the Routing table, for every node in the network, wins the same reward as the refresh thing. Other Routing tables are as fresh as possible, using today's network technology.

Now, having good Routing tables means immediately we are saving on bandwidth, because we're not sending bad packets, corrupt packets, or having to re-send stuff. Note we have the connection orientation here, so we are not saying we are more bandwidth efficient, because we may actually be using more bandwidth between these two guys than we normally would, because we are sending keep-alives, or, TCP's... doing that anyway---you just don't see it. A [??] degrees of separation: we think because in TCP you don't see it that it's not there, but it is there.

So, it's established that, the [??] line between two guys is something that networks live with, and they live with really well. We [don't fly an array??] across the network. So for us, this recursive thing, saves us on ports. But to become recursive, we actually adjust the Routing table, so that these are constantly connected guys. So we'll get fresh Routing tables. So we get fresh Routing tables, and we've got a refresh rate, which a normal Kademlia couldn't even dream of getting close to, without flooding the whole Internet. And this is where Routing deviates from Kademlia networks, significantly. There's a lot more small bits to it. But this is just like in the background, or, is to-- folk keep saying we're just a DHT over Kademlia or something like that. We're kinda, but we're not really.

Now, the downside of that is, if you look at your Kademlia Routing table, and I was saying before you've got this thing. So we get 511 buckets; 511 slots. If it was a true Kademlia Routing table, then we might have number of nodes per bucket. And a lot of Kademlia implementations, that's also K, which would be 8 or 20. So, for us, we would be looking at say, a K of 4. So you're looking at over 2,000 nodes. If we maintained a proper Kademlia Routing table, we would need over 2,000 nodes. So that'll be 2,000 connections---which is, too much, for us. So what we've done for the Routing table, is we have said 64 buckets is what we're dealing with. Or more accurately, 64 connections.

And immediately folks say, "Oh my god; that's not right! It's not blah blah blah." And you've got all the bullshit[?] stuff. But we'd had some, it was one of the lassies that worked with us actually; she was into maths and things.

And just as a side thing, just so that you know, for a network population of 7 billion---and you've got a hash table, 0-F, of 2 to the 512 address ranges. Every second node obviously goes into this bucket. So if you would start with a 1 [??], and it starts with 0, then it goes in there. Then every 4th nodes get in there, and every 8th nodes get into there. That transpires to, if you have a filled Kademlia Routing table, and a Network population of 7 billion, you'll only have nodes in 33 buckets, a potential of 64. So we are seeing a [??] of 64... nodes, that 33 of them are treated special. These are special nodes.

And, we do not care how many of these 32 nodes that are our closest nodes. Even if they are all in one bucket, we don't care. It's okay. So, for our close group, we are saying the bucket notation doesn't matter. However many buckets those 32 nodes span, that are closest to us, we don't care; we really don't care. The remaining 32 nodes, we do have the Kademlia Routing table pattern. So the remaining 32 nodes are actually put into a Kademlia Routing table, in a Kademlia fashion. So we do differentiate there. And again, that's just background information. That's in the Routing table. As I said, don't change stuff in that Routing table, really, haha, that's important.

So what do we have, in Routing? So we've got Crust here. And what Crust will do for us is it will connect to the network. Somewhere, it will connect to the Network somewhere, one that we were previously connected to. And it will make connections. So if Crust has got UTP and TCP, that will make at least those couple of connections. Um, it should make a connection per protocol. That will keep a bootstrap list... of nodes, that it knows that it could get to. These are the nodes that could get through the router, and have a listening port that we can access from anywhere else. So it'll keep that bootstrap list. So Crust will basically connect to the Network, and it will kind of say to us, "OK, I'm on the Network. I'm probably connected to people that you don't want to be connected to. But that doesn't matter! I'm connected to people on your Network... so I can route information, for you. So I can route information as far as you can tell me who to connect to." So, you think, well, that's kind of rubbish, because Crust is connected to 2 or 3 guys who, are probably not connected to anybody else; they might be, we don't know. How does that know how to do Routing?

And this is the key Crust has completely done. It knows [??] [??] Routing. It knows how to connect to networks, and it knows how to reconnect to networks; it will know how to do that in a multi-protocol way, and it will know how to do that in a way that it can check the NAT-traversal parameters and all the rest of it. And it will connect back. So how do we work in Routing then? Well that's pretty [??] [??], because we can't connect to this, and see, "Could you now connect to whatever, using a Kademlia address?" It wouldn't work, because it doesn't learn about these things.

So what Routing does, it starts a node. The very first node in the Routing network starts, and it will listen through Crust; it will listen. So node 1. So Node 2 starts, and connects to Node 1. And they pass some information saying, "Who are you?" And then he goes who who who? So, they discover... this guy discovers that he's Node 1, and this guy discovers he's Node 2. And then, they want to make a connection proper... connection, with each other. The way that Routing nodes would work: so this guy here says, "I really want to connect with someone who is called Node X." So this guy is a Routing node; he's got his own Routing table. And this guy here says, "Right, I've connected to you Node 1. But I don't really care about you; I want to connect to Node X." And... this guy here, doesn't know about Node X. He's like, "Huh, what? What are you talking about? Node X?"

So, what we do, is we need to do something to get from the IP Network to the... what is called the Routing network. IP is using IP Addressing, REP, and all the rest of that stuff. Routing is using a sort of Kademlia-like thing. So we need to get up to the Kademlia thing, to find information about who we want to connect to. So... initially when we start, we're quite dumb. We say, "Well, we're Node 2. We should be connected to some people, but I wonder who, we should be connected to?" So we're not on the Network; we're still at the IP network here. We're just an IP network. We're not on the Kademlia network; that's all on the Routing network. So what we need to do is, this guy is on the Routing Network: Node 1. The whole world and Routing knows about him. [???]. If it's not, he's just on his own, and that's perfectly OK.

So we need to send a thing that says, "Get me some information." Get some info. And what we do is we send a Group, for Node 2. So we're saying to this guy here, we're trying to say to the Network, "Get Group for Node 2." But, over here, you've got the DHT. And it can't speak back to us; it can't get back to us... because we are not on the DHT. Remember, we are still in the IP Network. You know, the Routing network is up here; we're not on it, we've not joined it. We're trying to join it, we're not there yet. So what we need to send is, "Get Group, for Node 2," so that we can get some contact information back, that we're going to try and connect to. And, how we do that, is we relay... via, Node 1.

And that's pretty straightforward. So the network, the DHT, sees, "Ah! Message from Node 1! [??] Get Group 2." And that gets the information and sends it back to Node 1. And Node 1 then gives it back to us. And now it's just going through a relay address. So when you send, this guy here sends the message, with this guy as the source (him as the relay)---when it comes back from being answered, that relay address is taken at the source, and put into a destination again. 'Comes back here, he sees the messages for him, but notices, "Ah, there's a relay address, for Node 2! So I'll give it to Node 2, because I'm connected to him. He's down here in this IP world; he's not in the Routing world. So I'll give this message to him."

This guy here then knows the IDs: the Routing IDs! The IDs from the Routing world. It knows then, that it should be connected to him. So it says, "Alright, I know who I should be connected to, but I've got now idea how to talk to them, because I'm down here, in the pits of IP, and I need to get up to the Routing layer." So he sends another message, for each of the IDs. So ID 1... he will send a connect... message, saying, "Please connect to me!" And that again will go through here as a relay message to the DHT network. And, ID 1 over here... will see, "Oh! That's a connect request from somebody that I should be connected to, because he's got an ID." (Sentinel does the checking of keys now, so we'll that for Sentinel.)

So this guy says, "I want to connect to ID 1." And this guy might make millions of connect requests, to get 3 or 4 connections. Later on, you'll see how that happens. But keep that in mind that, getting in close group connections is probably a 1:1 "you'll ask for a connection and get it." Get any other connections in your Routing table, you could be looking at a millions of attempts. So this guy doesn't hold the state of those connect requests. Importantly it doesn't hold the state. And that's vital... because that state could be millions, and you could do nothing but the [??], but if somebody doesn't connect to you, what do you do? Beg them? You know, there's no point in holding that state.

So we saved all the state away here. We say, "I'm ID 1. Here's the connection parameters that I've got. (I might have several connection types. I'm trying to connect to you in TCP.C, or UTP.)" This goes here, and the ID 1 node says, "OK I've got that." It's saying, "I'm going to send back my connection stuff, here, to this guy." And this guy says, "Oh! ID 1 wants to connect to me. The connect responds, which means, I must have asked him to connect!" But how do we know that's not a hacker? Somebody could be just be sending a connect request and doing something bizarre; we don't know. So when the connect request comes back, and says, "Connect response," the original connect request, signed by you, by this Node here, Node 2, he'll have a... So, he gets his own parameters back, plus his own signature back, saying, "This is what you asked me!" (And here, you've signed it yourself, so you can easily check it.) "And here's how you can connect to me." So it's saying, "Here's my connection parameters. Here's your connection parameters. Let's connect!" When that connection then gets established, this guy here moves up into the Routing. So he becomes on the Routing network Node, and he can speak for himself.

So initially, when you're not on the Routing network, you have to relay through another Node who is on the Routing network. And then, once you've got your connection established, you appear on the Routing network again, so you can speak to the Routing Network.

So, on Routing, that's how we do a connect, and that's how we get on to the Routing network, from the excellent work that Crust does to get us onto the IP. He needs to get us onto the IP Network, so he needs to connect us to an IP Address, that's already on the Routing network, behind the IP Layer. So Crust does that part for us, and then we just use him to go onto the [other?] network.

So, we already know we've got a recursive network here. But there's a thing that we do, called the Swarm. And I think I'll just fly over this, because I think everybody already knows it. These four guys, I'll just draw them like this, are supposed to be connected to each other. However, let's say this guy here is behind a symmetric router. And so is this guy. So they can't actually establish that connection. It doesn't work for them---for whatever reason. Probably about 30% of connections will be like this. And they can't establish it. But that's the group, the group for ABC.

So these guys need to be able to speak, because they have to make an agreement on actions and all the rest of it, on the network. So how we get around that is: whenever a message on the network, comes into this group---and it's destined for anywhere within that group, whether it's for that individual node, or for just a group in general---any node picking that message up, in here, sends it to every node he can speak to. And he sent it once. So this guy here got the message. And he will send it once, to everybody. So you get this Swarm thing.

And what that means is, no matter where the message comes in, everybody's going to get it. So he's going to give it to him, and him, and him. So, even though these guys couldn't speak, they got the same message. Same with, if he logs out with a node down, [??] going down---he will get it; he will get it. And he will transmit it, as well. So he will get told. If this guy here notices he's got a node down, he does the swarm thing. And this guy, finds out, anyway.

So, the swarm approach allows us to make nodes---that aren't actually connected---look like they are, at the cost of some extra traffic. And that extra traffic there is more than worth it. Because, trying to answer that question, by saying, "Let's make him send it; and we'll sign this; and, blah blah blah blah blah," You start ending up having to trust less than a group. ...And that doesn't work. All you end up with is piles and piles and piles of complicated code. Or just ignore the problem---which, heh, we've done, which wasn't a good thing.

The other main part of Routing, as you'll know, is we've got Group, and Quorum. And, so that's obviously from 0 to X. And then, there's a Quorum size... in there. And this distance here---this number of nodes here, represents to us, our error acceptance.

So, what we are saying with the Quorum size is: we are prepared to live with and accept a certain level of error, in the system. But the error can't be too dramatic, or it's going to-- there's going to be a Quorum down here, with one node telling the truth. The Quorum size has to be fairly high.

And we've measured this from a security perspective. And with that Quorum size of 19 or more, we've got something like 60... I don't know, 60-something% attack vector. And that means: when you've got the network kickin' about the place---and you've got a Quorum of 19---that when you take (imagine there's 19 things in there)... when you take the network population, if you try and create 19 nodes all close together, you're going to have to have some, I think it was something like 63% of all the nodes, in the network. So if the network is still at 100 nodes, you're going to have to add something like, I don't know---140.

Now, when you are adding that 140, nobody else is able to add nodes---only you---to get these figures. So it's very hard. The, point here is, the quorum size of 19, group size of 32---it seems to, give us... we did a group size down near at, 23 I think, and we noticed that there wasn't enough error margin. Some things in the Sentinel weren't working right. And what we did was we increased the group size to 32 to give us more of an error margin. But we maintained the security size, here. And that security size is important.

If you were able to add 140 nodes to a 100 node network, and prevent anybody else adding a node, the chances are that you would be able to get a group here. So, that becomes quite a powerful thing, because that 60-odd% attack is, ultra, ultra conservative. I think everything would have to be going in your favor, to be able to attack it in that way. So, the Routing network is very focussed on this Group and Quorum size. And there's a thing called Address Space, too, in the C++ library---which if you run it, you can play about these figures, and you can see the attack sizes. And you can see how that's coded.

So Routing specifically is: what adds the routability, if you like, or the Routing capability to an IP Network. So you've got IP, and you've got Routing. And Routing, basically, is saying a few things. It's saying... that we'll be able to find stuff, on the network. And, when you add Sentinel, it gives you a whole bunch of security things.

But also, Routing is kind of saying, "Well, we're going to provide security---via these quorum sizes, via, say a quorum." So particularly, a group size of a quorum we can imagine just being a group size, if you ignore the error part of it. So we're going to provide security via a quorum. And at the moment, it doesn't... heh. So at the moment, it doesn't provide any security, even with Sentinel.

So if we, again, have this group---we say the network's there. And we are saying it's sixty, say 63% attack. So you start adding nodes. And then eventually they will go in here. However, at the moment, you just create a key pair. And store it. And then join the network. So you can get into that group by just, offline, creating key pairs... like mad. And to add, heh, add salt to the injury, we have just moved to libsodium---which will allow you to create a hundred and something thousand key pairs per second. So, you could say, "Well, I need an address of 'close to ABC.'" And just keep creating key pairs, until you get that address. So you break all the quorum stuff.

So, one of the important things about Routing, that it has to do is what we will call Address Relocation. And Address Relocation takes away this offline attack---just removes it. And what that means is---and it's part of the [??] [??] now---you're trying to store a key, ABC. So, that will get close to the group, ABC. So this guy here, ABA, ABB, blah blah blah. And one of this group will say, "Oh, I've seen a store ABC." "So we'll take that message, ABC, and we'll add in the two closest IDs, to ABC." (So these ones.) "So we'll add that. And then hash it again." And then, give it back to this guy, and say, "This is your ID, to join the network with." So, here... now that could be improved, because these guys here could go and store it, and, various stuff.

So the key point here is this Address Relocation needs to be carefully considered---that you're not allowed to store ABC. You're not allowed to just create any key pair that you want. And then sorta, when that key pair-- Routing uses Session Keys. So when that key pair goes to, whatever that, PQR... if that became PQR. So it goes to PQR, in a 10-minute cache. So that guy has got 10 minutes to then go and connect, to there. Or else they'll drop his key. And he'll have to start again. That's how Address Relocation can be shown, in its most simplified manner.

So Routing, really, at the moment, hasn't-- if you take the Address Relocations that you've done, if you take Routing, you've got the Routing table. You've got your connect message; connect response; get group; and then you're going to have a couple of get keys (what you're going to pass to the Sentinel). And then you've got the trait requirements. And you've got this Authority.

I've not really been over Authority yet. It's pretty simple. From the message traits, we can say, "What's the name of this piece of data---on the network address, or the element manager, or on the node manager or client manager?" The Authority is, that's explained plenty of times on our blog post. And then, the Authority code itself is very simple. So you can see it. But Routing, is really... (Someone on the call: "David, that's 1 hour.") Routing is really just those components... and, nothing else.

So, there you go! That's your... very quick, brief, Routing overview!
I'm going to mute myself now.