[00:01.230 --> 00:03.080]  Hey, is everyone having a good conference?
[00:04.700 --> 00:06.680]  Okay, I didn't hear anyone from the back half.
[00:06.850 --> 00:07.400]  Let's hear that again.
[00:07.520 --> 00:08.620]  You guys having a good conference?
[00:10.880 --> 00:11.240]  Cool.
[00:11.600 --> 00:11.840]  All right.
[00:12.100 --> 00:15.060]  Well, yeah, these guys sound like they're really cool.
[00:15.120 --> 00:24.510]  I just read through the Project Byzantium description in the program, and I've seen a lot of cool people around, so pleased to make the introduction and enjoy.
[00:26.130 --> 00:26.760]  Let's do it.
[00:32.070 --> 00:33.380]  Do these mics work?
[00:34.080 --> 00:35.060]  That's a good question.
[00:35.940 --> 00:36.900]  Good evening, everyone.
[00:37.740 --> 00:38.560]  Welcome to HOPE.
[00:38.760 --> 00:42.540]  Welcome to Project Byzantium, Mesh Networking for the Zombie Apocalypse.
[00:44.540 --> 00:45.360]  Still mic check?
[00:46.280 --> 00:46.800]  All right.
[00:46.880 --> 00:47.880]  Yeah, I don't switch.
[00:48.640 --> 00:49.620]  Is there an on switch?
[00:50.680 --> 00:51.160]  Wow.
[00:51.560 --> 00:52.000]  Plugged in.
[00:56.760 --> 00:57.740]  And before wisecrack.
[00:57.840 --> 00:58.200]  Good on you, sir.
[01:00.120 --> 01:00.900]  We can just come up here.
[01:02.320 --> 01:03.360]  We can just cluster on the podium.
[01:03.500 --> 01:03.940]  It's not a big deal.
[01:04.120 --> 01:04.660]  Turn it on.
[01:07.080 --> 01:07.360]  Okay.
[01:08.700 --> 01:09.740]  Let's just cluster on the podium.
[01:09.900 --> 01:10.360]  It's not a big deal.
[01:10.360 --> 01:10.820]  That's fine.
[01:11.220 --> 01:11.280]  Okay.
[01:11.840 --> 01:14.800]  First, we'd like to give a short disclaimer.
[01:16.020 --> 01:16.520]  Okay.
[01:17.180 --> 01:18.360]  First, we'd like to give a short disclaimer.
[01:19.040 --> 01:19.820]  We do not...
[01:19.820 --> 01:23.360]  None of the Project Byzantium developers speak for our employers past or present.
[01:24.060 --> 01:26.680]  We also are not speaking for Hack DC either.
[01:26.960 --> 01:34.180]  While we're members of Hack DC, well, you know how it goes with organizations and 501c3s and things like that.
[01:35.280 --> 01:40.880]  We'd also like to point to state that Project Byzantium is entirely separate from our day, evening, and other jobs.
[01:41.140 --> 01:42.460]  We're doing this in our spare time.
[01:43.040 --> 01:43.160]  Yeah.
[01:43.260 --> 01:44.340]  Same standard disclaimer.
[01:45.120 --> 01:45.240]  Yeah.
[01:45.460 --> 01:48.480]  So who we are, I'm obviously Ben the Pirate.
[01:48.740 --> 01:49.900]  I also go by Sitwan.
[01:50.100 --> 01:50.700]  That's my handle.
[01:51.520 --> 01:55.460]  Linux sysadmin developer, experience with networks, embedded distributions.
[01:56.400 --> 02:08.900]  And, you know, I'm really concerned about network neutrality, disaster relief, things like Egypt, Haiti, that, you know, what happens when people can't communicate.
[02:11.380 --> 02:12.720]  I'm Hacks with Hacks.
[02:12.930 --> 02:15.180]  I'm Linux sysadmin programmer.
[02:15.560 --> 02:16.480]  Do a lot of stuff.
[02:16.880 --> 02:18.520]  Do outdoorsy stuff.
[02:19.380 --> 02:22.540]  I break things, and that's how I know how to fix them, unfortunately.
[02:24.920 --> 02:26.300]  And I'm called a doctor.
[02:26.660 --> 02:28.200]  On Twitter, I am vertadept.
[02:28.440 --> 02:30.400]  I am a BOFH by trade.
[02:30.600 --> 02:34.780]  I am also a system architect, a security consultant, and a social activist.
[02:35.300 --> 02:38.340]  I have experience with alternative communications technologies.
[02:38.620 --> 02:43.020]  And I am concerned about censorship, emergency communications, and freedom of speech.
[02:44.360 --> 02:44.940]  All right.
[02:45.040 --> 02:48.040]  So the basic assumptions that we're making are that you're...
[02:48.040 --> 02:51.620]  Basically, that you have a net plus or equivalent understanding of networking.
[02:51.620 --> 02:56.660]  If you're familiar with the OSI model, 802.11, you know how routing works.
[02:57.140 --> 03:01.560]  It's pretty standard stuff, I think, for most people at this kind of a conference.
[03:04.040 --> 03:04.520]  Okay.
[03:04.840 --> 03:06.480]  So our fundamental assumption is this.
[03:06.680 --> 03:07.840]  The Internet is broken.
[03:08.580 --> 03:11.780]  It fails on a lot of different levels, but let's start from the bottom five.
[03:13.500 --> 03:14.060]  All right.
[03:14.280 --> 03:19.560]  So the first use case is, you know, the Katrina problem, which is there's a massive failure of infrastructure.
[03:19.560 --> 03:25.620]  Some kind of natural disaster or zombie apocalypse comes in and the phone lines are all down.
[03:25.900 --> 03:27.440]  The ISPs aren't functioning.
[03:27.720 --> 03:30.260]  There might be, you know, no power, limited power.
[03:30.540 --> 03:36.200]  So this is where, like, there's no lines connecting you physically to anybody else.
[03:36.200 --> 03:38.340]  And that can be a problem.
[03:40.660 --> 03:41.140]  Okay.
[03:41.160 --> 03:43.100]  Our second use case we call the Egypt problem.
[03:43.320 --> 03:46.260]  It's when there is a deliberate compromise of the network infrastructure.
[03:46.540 --> 03:48.760]  For example, when ISPs are taken offline.
[03:49.540 --> 03:53.420]  In this situation, you need to communicate with other people in a secure manner.
[03:53.680 --> 03:57.100]  You need to contact the outside world to send and receive information.
[03:57.100 --> 04:00.420]  And often there is an active adversary working against you.
[04:00.560 --> 04:01.800]  In fact, by definition there is.
[04:04.440 --> 04:09.680]  So our approach to solving these problems is the construction of a mobile ad hoc wireless network.
[04:12.280 --> 04:15.040]  But wait, isn't the Internet a centralized network?
[04:15.200 --> 04:18.240]  Doesn't it interpret censorship as damage and route around it?
[04:19.480 --> 04:20.320]  Not so much.
[04:21.540 --> 04:29.260]  So the problem is that the IP addressing, IPv4 and IPv6, are inherently hierarchical.
[04:29.520 --> 04:36.380]  And it determines, your address determines where you exist logically, hierarchically, within that network.
[04:36.580 --> 04:42.040]  So it's a location inside of a network and packets get routed based on this hierarchy.
[04:42.600 --> 04:46.320]  And there's really no, a lot of networks don't have redundant links.
[04:46.320 --> 04:50.140]  There's only, like, one potential route to take to get to a particular destination.
[04:50.320 --> 04:54.760]  If that route happens to go down, then that destination is completely unreachable.
[04:57.280 --> 04:57.760]  Okay.
[04:58.140 --> 05:03.240]  So to solve this problem, what we need is a true mesh network with multiple redundant routes between endpoints.
[05:05.180 --> 05:06.380]  So let's put this all together.
[05:06.860 --> 05:11.120]  Ad hoc wireless plus mesh routing equals mobile ad hoc wireless mesh network.
[05:11.360 --> 05:12.620]  And we can already do this.
[05:12.860 --> 05:14.620]  This software has been around for a long time.
[05:14.860 --> 05:17.800]  Yeah, as a technology, mesh networking has existed for well over 20 years.
[05:17.800 --> 05:20.160]  The thing is, nobody has made it easy to deploy.
[05:20.400 --> 05:23.580]  Nobody has made it easy to verify it's working.
[05:23.700 --> 05:24.720]  Nobody has made it reliable.
[05:25.640 --> 05:27.080]  And we're trying to fix that.
[05:28.280 --> 05:28.740]  All right.
[05:29.180 --> 05:33.860]  So our design goals going into this was that it has to be cheap and use readily available equipment.
[05:34.140 --> 05:37.900]  Because when shit hits the fan, you can't go out to Newegg, you can't go out to, like, Mauser.
[05:38.280 --> 05:40.140]  You're gonna have to make do with what you have.
[05:40.540 --> 05:43.980]  You know, Newegg can't deliver if you can't get online to order it.
[05:45.020 --> 05:49.000]  It's gotta be rapidly deployable because this is an emergency situation.
[05:49.340 --> 05:52.780]  It's gotta be, you know, extensible to solve the problem that you're having.
[05:53.000 --> 05:57.160]  It needs to be reliable because people's lives could depend on it.
[05:57.280 --> 05:59.220]  It needs to be secure for the same reason.
[05:59.520 --> 06:04.240]  And it needs to be low maintenance because the kind of people that have the skills to set this up have other valuable skills.
[06:04.260 --> 06:08.240]  And they're gonna be needed elsewhere to, you know, continue solving problems.
[06:09.240 --> 06:09.720]  Okay.
[06:10.020 --> 06:12.140]  So, let's talk a little bit about our design constraints.
[06:12.620 --> 06:20.340]  We decided to solve for the Katrina problem first and the Egypt problem second because the Egypt problem is actually a specialization of the Katrina problem.
[06:21.360 --> 06:28.920]  To solve this, we need a solution which a small group of minimally skilled individuals can deploy to solve this problem.
[06:29.520 --> 06:34.940]  Ideally, we want to make it as easy to use as, say, setting up a home wireless router right out of the box.
[06:36.340 --> 06:39.580]  The solution also needs to support a larger community of users.
[06:40.380 --> 06:41.720]  It's not just for geeks.
[06:41.840 --> 06:42.640]  It's not just for hackers.
[06:42.800 --> 06:46.900]  It has to be for whoever has a wireless equipped device.
[06:47.040 --> 06:48.440]  Whoever has a need to communicate.
[06:48.700 --> 06:49.720]  Whoever has a need to communicate.
[06:51.260 --> 06:54.600]  Sufficient tools have to be available in the solution to accomplish arbitrary tasks.
[06:54.980 --> 07:00.200]  Because, let's face it, no plan survives first contact with the enemy in whatever shape or form you want to put that in.
[07:01.180 --> 07:03.060]  Also, minimal collusion needs to be required.
[07:03.060 --> 07:13.380]  In an emergency situation where communication is critical, you don't have time to run around finding people, figuring out who knows what they're doing, who doesn't have the skill set.
[07:14.180 --> 07:20.140]  You need to be able to start it up, get it running, and then hit the ground, and then take off to do other things.
[07:20.140 --> 07:22.200]  Yeah, this is a tool to restore communication.
[07:22.220 --> 07:26.300]  So, we're making the assumption that you can't already communicate with the people that you want to.
[07:26.940 --> 07:28.100]  Otherwise, you don't need this.
[07:29.480 --> 07:35.600]  Another design constraint is not all of the devices in the field have to be running the mesh writing software.
[07:37.000 --> 07:41.340]  This presupposes that you're not going to have access to the iTunes store.
[07:41.560 --> 07:43.240]  You're not going to have access to Android Play.
[07:43.800 --> 07:47.220]  You might have a netbook sitting on a shelf.
[07:47.480 --> 07:50.820]  You might have an older PC with a wireless card sitting in your basement.
[07:51.140 --> 07:54.140]  Or you might just have a smart phone or an MP3 player on you.
[07:58.680 --> 08:01.180]  So, we're building this on top of ad hoc networking.
[08:01.880 --> 08:03.680]  So, we're using 802.11 at layer one.
[08:05.040 --> 08:08.880]  And in layer two, we're using ad hoc networking, which is part of the 802.11 spec.
[08:10.300 --> 08:13.800]  Most 802.11 devices, most Wi-Fi enabled devices support it.
[08:14.560 --> 08:17.020]  Not many people know about it or use it for some reason.
[08:17.320 --> 08:18.480]  I'm sure a lot of you did.
[08:19.180 --> 08:20.520]  But average people don't.
[08:20.780 --> 08:24.020]  And there are some devices that have trouble with it.
[08:24.020 --> 08:27.560]  But it requires minimal configuration.
[08:27.880 --> 08:29.160]  There's no central AP needed.
[08:29.400 --> 08:38.740]  What happens if you look at the image on the left, what happens in a standard access point network is that the clients talk to the AP only.
[08:39.020 --> 08:48.360]  Even if they're right next to each other, even if the radios are like literally six inches apart, messages go up to the AP and then back down to the other client.
[08:49.040 --> 08:51.520]  And they can't talk directly to each other.
[08:51.520 --> 08:53.800]  In an ad hoc network, there is no AP.
[08:54.040 --> 08:56.920]  They all just talk and whoever can hear them, hears them.
[08:57.100 --> 08:59.380]  The problem is that it doesn't implement multi-hop.
[08:59.540 --> 09:05.600]  So if the node is a little bit further away, even if there are nodes in the middle, they won't route that traffic automatically at layer two.
[09:06.940 --> 09:09.400]  So that's where mesh routing comes in to solve that.
[09:09.580 --> 09:15.860]  Mesh routing happens at layer three and it solves the multi-hop problem in ad hoc networking.
[09:16.720 --> 09:17.120]  Okay.
[09:17.420 --> 09:17.620]  Okay.
[09:18.040 --> 09:23.080]  As I said earlier, mesh routing has existed as a technology for well over 20 years.
[09:23.740 --> 09:26.220]  And a number of protocols exist to implement mesh routing.
[09:26.440 --> 09:28.700]  And by number, we mean there are over 70 of them.
[09:29.120 --> 09:34.560]  Back in the 1990s, mesh networking was actually something of a hot topic of research where somebody would publish a paper.
[09:35.100 --> 09:38.040]  Maybe they'd write a little bit of sample code and then that was the end of it.
[09:40.000 --> 09:44.180]  There's also the problem that not all mesh routing protocols have the same features.
[09:44.720 --> 09:47.240]  They also don't have all the same problems.
[09:47.240 --> 09:49.200]  So you can't really generalize a solution from them.
[09:49.680 --> 09:55.480]  In fact, some...in fact, not all mesh routing protocols are even equally efficient when compared to one another.
[09:55.760 --> 09:59.360]  And some have some very serious flaws which make them unusable for one reason or another.
[10:00.360 --> 10:00.760]  Right.
[10:00.880 --> 10:02.200]  So we evaluated a number of them.
[10:02.260 --> 10:05.760]  The first one was OpenNATO 2.11s, which it's the standard.
[10:05.760 --> 10:09.720]  So you'd think, well, that's the obvious choice, except it isn't.
[10:11.040 --> 10:17.120]  So the software...yeah, this is a standard that it's only recently become a standard.
[10:18.040 --> 10:23.440]  It's supposed to be implemented into the firmware of 802.11 devices and drivers.
[10:24.100 --> 10:28.580]  It is built...you know, support is built into Linux and BSD, but only where the hardware supports it.
[10:29.720 --> 10:36.160]  It requires, you know, some...I mean, it requires, like, some deep knowledge to use.
[10:36.280 --> 10:37.480]  It's kind of exotic still.
[10:37.840 --> 10:39.020]  Not well implemented.
[10:39.220 --> 10:42.580]  There's, you know, compatibility problems between different versions of it.
[10:42.980 --> 10:45.240]  And, you know, it's really just not widely used.
[10:46.520 --> 10:50.700]  The second protocol we looked at is called OLSR, which stands for Optimized Link State Routing.
[10:50.700 --> 10:54.820]  As the name suggests, it's a link state routing protocol, which is Layer 2 agnostic.
[10:55.120 --> 10:56.720]  It actually predates 802.11.
[10:56.980 --> 11:01.900]  So it can be run on pretty much any network of any kind that you want to throw it at.
[11:02.760 --> 11:05.080]  Unfortunately, OLSR doesn't do link quality awareness.
[11:05.420 --> 11:11.180]  There are a few implementations of the protocol that have it, but at best, it's experimental.
[11:11.180 --> 11:19.220]  So in weird wireless networking environments, transmission transients or RF can lead to links being a little bit dodgy.
[11:19.400 --> 11:21.280]  And OLSR is unable to compensate for that.
[11:22.060 --> 11:25.700]  Also, they've just started implementing proactive loop detection.
[11:25.860 --> 11:27.040]  It's experimental.
[11:27.360 --> 11:32.080]  And how well it works and how many situations it works in remains to be seen.
[11:32.900 --> 11:34.420]  OLSR is also very chatty.
[11:34.740 --> 11:37.380]  It floods the entire network with topology information.
[11:37.380 --> 11:39.520]  So when you have a certain...
[11:39.520 --> 11:47.660]  So at a certain network density and or a certain number of nodes, you may wind up seeing more routing traffic being exchanged than other forms of traffic.
[11:49.520 --> 11:50.080]  All right.
[11:50.140 --> 11:54.380]  The second one we looked at was Batman Advanced, which is being used by the Freyfrunk network.
[11:54.640 --> 11:57.380]  And it's under very active development.
[11:57.520 --> 11:58.660]  There's an active community around it.
[11:59.040 --> 12:01.900]  It stands for better approach to mobile ad hoc networking.
[12:02.540 --> 12:04.340]  It does have link quality awareness.
[12:04.340 --> 12:06.320]  It does have loop avoidance.
[12:06.860 --> 12:10.680]  It's been in the Linux kernel officially since 2.6.38.
[12:11.340 --> 12:12.680]  Before that, it was in testing.
[12:12.820 --> 12:14.440]  So if you have an earlier kernel, you might still have it.
[12:15.140 --> 12:23.320]  The problem is that it requires the batctl utility, which most distributions do not include, do not package.
[12:23.720 --> 12:27.020]  You have to get it from a third party or download the source and compile it.
[12:27.220 --> 12:33.600]  Often, if it is in your distribution's repository, the version of the utility is out of date with the version in your kernel.
[12:35.580 --> 12:38.980]  And it doesn't... in our testing, it didn't lend itself to rapid deployment.
[12:39.160 --> 12:48.640]  It was really difficult to manage and test, partially because it operates at layer three, but provides a virtual layer two interface.
[12:48.860 --> 12:53.720]  So you can't use your regular layer three tools to diagnose the operation and troubleshoot.
[12:53.720 --> 13:00.800]  You have to use special tools written for the Batman software to, you know, poke around and see if it's working, see what's going on.
[13:01.220 --> 13:01.420]  Yeah.
[13:01.520 --> 13:05.680]  Even TCP dump is tripped up by Batman Advanced, which was a bit of a surprise.
[13:06.240 --> 13:13.500]  So after a couple cycles of testing in our development sprint, we settled on a mesh routing protocol called Babel.
[13:14.020 --> 13:20.880]  It is a distance vector routing protocol, which uses, among other things, link quality to help determine the optimal... and optimal route through the mesh.
[13:21.400 --> 13:23.100]  It is traffic density aware.
[13:23.120 --> 13:38.680]  So if a mesh node has several interfaces and one or two of the interfaces are very heavily trafficked, but a third interface is not, then it'll make the decision to route more traffic over the least used interface, which may give it a longer... which may give it a longer path through the network,
[13:39.020 --> 13:41.600]  but will, in the end, wind up being more efficient.
[13:42.720 --> 13:45.020]  Babel also unusually converges rapidly.
[13:45.600 --> 13:48.820]  By rapidly, it'll... a mesh can converge in about four seconds.
[13:49.080 --> 13:49.320]  Yeah.
[13:49.380 --> 13:52.280]  It has proactive loop avoidance that's formally proven.
[13:52.460 --> 13:54.400]  This was... this started as an academic project.
[13:54.720 --> 13:57.440]  So it's the... this is actually mathematically proven.
[13:57.560 --> 13:59.020]  There's a proof on the author's website.
[13:59.220 --> 14:04.380]  You can read about it if you're interested and, you know, in the loop avoidance properties, which are actually kind of cool.
[14:04.960 --> 14:08.340]  If you do a search on mesh networking Babel, you'll find the page.
[14:08.720 --> 14:12.340]  I'm going to butcher the gentleman's name horribly and I apologize in advance.
[14:12.740 --> 14:14.180]  Julius Cabratch, I believe.
[14:14.640 --> 14:15.120]  Yeah.
[14:15.540 --> 14:17.620]  Again, Julius, if you're watching this, I apologize.
[14:19.280 --> 14:21.340]  Babel also runs in user space.
[14:21.640 --> 14:25.160]  So it lends itself to portability and deployability.
[14:25.340 --> 14:26.920]  It doesn't run as a kernel module.
[14:27.040 --> 14:28.040]  It doesn't run as a vice driver.
[14:28.400 --> 14:31.660]  You start it up on the command line and it takes off on its own.
[14:31.660 --> 14:40.060]  It also manages the routing table of the operating system's kernel rather than setting up its own routing table structure or hooking into what exists.
[14:40.680 --> 14:48.500]  Basically, it automates the process of doing route add, route del, yada, yada, yada, in a very streamlined fashion.
[14:48.500 --> 14:57.320]  So it's really easy to check on it by just, you know, using regular tools, regular networking tools to see how it's working and poke around in there if you need to.
[14:58.100 --> 14:59.260]  Super easy to configure.
[14:59.540 --> 15:02.200]  At most, it's like four lines in a configuration file.
[15:02.900 --> 15:04.840]  This was really, really easy.
[15:05.140 --> 15:05.440]  Yeah.
[15:05.680 --> 15:11.240]  And the nice thing is the four line configuration file has been portable across every situation we've thrown it out.
[15:11.240 --> 15:11.340]  Right.
[15:11.700 --> 15:15.800]  It generalizes very easily to lots of different problems.
[15:16.900 --> 15:17.360]  Yeah.
[15:17.620 --> 15:20.520]  So a question we get asked a lot is, what about Tor?
[15:20.800 --> 15:23.560]  What about CJDNS, ITP, all these other solutions?
[15:23.780 --> 15:25.180]  Aren't they mesh networks?
[15:25.500 --> 15:26.620]  Can't we just use that?
[15:26.800 --> 15:28.240]  CJDNS especially keeps coming up.
[15:30.000 --> 15:31.120]  And not quite.
[15:31.260 --> 15:32.280]  They aren't low level enough.
[15:35.040 --> 15:35.960]  I don't know.
[15:35.960 --> 15:36.760]  It's the Cabot.
[15:37.820 --> 15:38.520]  That was him.
[15:39.880 --> 15:43.100]  So they all operate at OSI layer four and above.
[15:43.280 --> 15:48.640]  So if you don't have routing worked out at the network layer, layer three, then you're still dead in the water.
[15:48.960 --> 15:51.420]  CJDNS even is not a replacement for this.
[15:51.600 --> 15:55.540]  Regardless of what it says, you know, about, you know, throwing out the OSI model, it doesn't.
[15:55.640 --> 15:58.560]  It still relies on layer three and below to operate.
[15:58.680 --> 16:03.340]  If you can't send packets, you know, over the IP network, then it's not going to do anything.
[16:03.880 --> 16:04.320]  Yeah.
[16:04.460 --> 16:13.960]  All it takes is one DPI hardware manufacturer to throw a couple of rolls in, which has a turnaround time sometimes of seconds, and your solution is dead in the water.
[16:14.500 --> 16:14.740]  Right.
[16:15.980 --> 16:21.640]  So those solutions can fail if, you know, your ISP is using DPI filtering, filter supports, or stops routing.
[16:21.960 --> 16:22.520]  And so...
[16:22.520 --> 16:24.460]  Or even if they shut off their infrastructure entirely.
[16:24.720 --> 16:27.080]  Which has been happening more and more often in Syria.
[16:27.500 --> 16:27.720]  Right.
[16:27.980 --> 16:32.680]  So ad hoc networks provide you with a solid, you know, layer three that you can use these tools on top of.
[16:32.740 --> 16:33.620]  And we do recommend them.
[16:33.960 --> 16:37.400]  They solve different problems than what mesh routing solves.
[16:37.560 --> 16:38.800]  And they are valuable.
[16:40.180 --> 16:44.740]  And with that, we would like to announce the release of Byzantium Linux version 2.0 alpha.
[16:46.220 --> 16:46.680]  Yeah.
[16:52.740 --> 16:56.560]  You mispronounced it or you misspelled it because you said 2.0.
[16:56.680 --> 16:57.400]  It's .02?
[16:57.880 --> 16:58.320]  No.
[16:58.580 --> 16:59.160]  0.2.
[16:59.340 --> 17:00.300]  This is an alpha release.
[17:01.280 --> 17:01.340]  Okay.
[17:02.260 --> 17:03.220]  Thank you for the question.
[17:03.360 --> 17:03.940]  0.2.
[17:04.120 --> 17:04.460]  Alpha.
[17:05.580 --> 17:06.020]  Sorry.
[17:06.420 --> 17:06.680]  Yeah.
[17:06.880 --> 17:07.660]  We're working on it.
[17:07.880 --> 17:08.160]  Really.
[17:08.840 --> 17:09.280]  Yeah.
[17:09.380 --> 17:11.100]  We're doing our best and we will get there.
[17:11.300 --> 17:11.500]  Yes.
[17:11.580 --> 17:11.960]  It's within sight.
[17:12.660 --> 17:16.000]  This is a live CD, live USB distribution.
[17:16.000 --> 17:17.680]  It's based on Proteus Linux.
[17:18.820 --> 17:23.400]  It has utilities for live replication in the field, which was really why we went with this.
[17:23.540 --> 17:27.280]  It's super easy to make copies, even from just a running copy you have.
[17:27.460 --> 17:30.320]  Plug in a USB, run a script, and you have another one.
[17:31.260 --> 17:34.480]  It has all the mesh routing software already installed on it.
[17:34.480 --> 17:38.560]  It has tools for development and debugging so you can play around with it.
[17:38.740 --> 17:44.100]  We threw a lamp stack on there so you can host applications locally in the case that there is no Internet access.
[17:45.220 --> 17:50.980]  There's a web control panel for administering it similar to administering a wireless router in your home.
[17:52.240 --> 17:58.360]  And we have also included a couple of proof of concept user services, which you can run on a mesh node and will be available to mesh users.
[17:58.360 --> 18:04.740]  Among them, we have included an IRC server with a web client, which we're trying to optimize for mobile devices.
[18:05.240 --> 18:06.800]  And a collaborative text editor.
[18:07.420 --> 18:07.960]  Yay, Etherpad.
[18:10.040 --> 18:13.220]  So we'd like to talk a little bit about some of the problems we ran into and how we solved them.
[18:13.380 --> 18:14.860]  The first was network configuration.
[18:15.340 --> 18:19.660]  In an emergency situation, and in particular with mesh networks, you have something of a chicken and egg problem.
[18:21.200 --> 18:24.500]  You're booting up a node, but you can't be sure you're the only node.
[18:25.040 --> 18:28.220]  You might be, but you have no way of knowing ahead of time if you are.
[18:28.220 --> 18:33.660]  On the other hand, you might be booting up a node and you don't know if there's already a mesh network to connect to.
[18:33.840 --> 18:40.440]  So the question is, how do you configure yourself without stepping on your neighbors, but also how do you make it possible to bootstrap a mesh?
[18:41.340 --> 18:52.260]  And what we came up with is a probe and test algorithm, which unfortunately and accidentally reimplements Avahi's autoconf.
[18:52.260 --> 19:05.220]  What we did was our control panel uses RPing to detect whether or not pseudo-random IP addresses in the RFC 1918 address space of 192.168 stroke 16 exist.
[19:05.860 --> 19:10.340]  And if another server has claimed it, then it'll send back an ARP packet.
[19:10.340 --> 19:11.920]  If it doesn't, it'll claim it for itself.
[19:12.780 --> 19:17.220]  It then assigns that address to its primary wireless interface as a slash 32.
[19:17.520 --> 19:22.580]  So every other node that it connects to is basically a point-to-point route.
[19:23.080 --> 19:28.320]  We do the same thing for clients, only in the 10 stroke 24 address space.
[19:29.160 --> 19:32.960]  We implement DNS and DHCP for the clients with DNS mask.
[19:33.240 --> 19:37.480]  It's dynamically configured by the control panel just after it configures the wireless interface.
[19:38.760 --> 19:42.820]  And we also found a workaround for the problem of only having one wireless interface.
[19:43.940 --> 19:52.540]  What we do is, after the primary wireless interface is configured on a node, it then tries to detect if there is a second wireless interface.
[19:52.760 --> 19:56.680]  If there isn't, it sets up an IP alias on the wireless interface.
[19:56.680 --> 20:00.340]  So if it finds WLAN 0, it creates WLAN 0 colon 1.
[20:00.880 --> 20:06.060]  And WLAN 0 colon 1 is the virtual interface that the clients communicate with.
[20:06.460 --> 20:13.760]  And because they're basically the same physical device, traffic goes in and comes out, and you don't have to do anything crazy.
[20:13.800 --> 20:15.040]  It just does the right thing.
[20:15.500 --> 20:16.680]  How often does that happen these days?
[20:17.000 --> 20:17.520]  Yeah.
[20:17.660 --> 20:23.520]  So when we went to actually implement Avahi, we noticed that that node configuration part actually re-implements 0conf.
[20:23.700 --> 20:25.260]  And that was like, oops.
[20:25.260 --> 20:27.780]  So in the next version, we'll probably just use 0conf for that part.
[20:28.160 --> 20:28.460]  Yeah.
[20:28.920 --> 20:30.320]  So I don't know.
[20:30.820 --> 20:31.180]  Right.
[20:31.380 --> 20:37.480]  So like he said about the clients, in a mesh network, you have nodes.
[20:37.480 --> 20:41.020]  But we're also anticipating that there's going to be clients that aren't running the mesh software.
[20:41.320 --> 20:43.040]  So how do we deal with those?
[20:43.040 --> 20:47.220]  The pomegranate there is our logo for Byzantium.
[20:47.320 --> 20:49.400]  So that represents, you know, a Byzantium node.
[20:50.060 --> 20:53.920]  And it has the WLAN 0 and the WLAN 0 colon 1 interface.
[20:54.220 --> 20:57.940]  The WLAN 0 interface has that slash 32 address.
[20:57.940 --> 21:01.260]  And it's talking to the other nodes in the mesh network.
[21:01.500 --> 21:05.340]  And the colon 1 has that 10 dot slash 24 address.
[21:05.340 --> 21:07.460]  And it's talking to non-mesh devices.
[21:07.640 --> 21:13.080]  So when a non-mesh device comes on the ad hoc network, it's going to use DHCP to ask for an IP address.
[21:13.240 --> 21:15.840]  You know, just like you go to Starbucks and connect to their Internet.
[21:16.200 --> 21:22.460]  And what's going to happen is the closest node to you is, you know, usually is going to reply first with an IP address.
[21:22.620 --> 21:25.620]  And then it's going to become your gateway to the rest of the mesh network.
[21:25.620 --> 21:31.640]  So, to a regular user, they're connecting to a hotspot, just like in Starbucks.
[21:31.920 --> 21:36.780]  And just like in Starbucks, you're going to get a captive portal page, you know, telling you, hey, you're on a mesh network.
[21:37.020 --> 21:38.860]  These are the kinds of services that are available.
[21:39.360 --> 21:39.980]  Watch out.
[21:40.080 --> 21:41.180]  It might not be secure.
[21:42.580 --> 21:53.780]  And so we can allow devices like phones, you know, laptops that aren't running the software, computers, anything else that's out there that's Wi-Fi enabled to still access the network, the Internet, everything.
[21:56.460 --> 21:56.940]  Okay.
[21:57.100 --> 22:01.780]  Another problem we ran into is inherent in 802.11, and that's the range of an augmented Wi-Fi.
[22:03.540 --> 22:13.500]  The reason you would want to do this is you might get, under best circumstances, a range of maybe a city block with a wireless interface, which is fine for that city block.
[22:13.660 --> 22:17.980]  But when there are people city block and change away, how do you get them on the mesh?
[22:19.400 --> 22:30.560]  Another problem, another problem, which is actually a super problem of this, is how do you hook together multiple meshes in a city which are separated by distances farther than the maximum range of Wi-Fi?
[22:30.560 --> 22:36.300]  And it boils down to you can't assume that there will be consistent coverage of a mesh in a city.
[22:36.700 --> 22:37.520]  It's sad but true.
[22:38.220 --> 22:44.340]  And we did a development sprint where we really packed on this problem and tried to find some creative solutions.
[22:44.800 --> 22:52.100]  We worked on some improvised solutions as well to see what a motivated group could do in an emergency with the junk they have in their basement.
[22:52.100 --> 22:55.140]  Which for us was the junk that we had around Hack DC.
[22:55.880 --> 22:56.140]  Yeah.
[22:56.640 --> 23:09.100]  So we tried things like we tried building a sound to laser transducer and we tried a couple different optical to electrical trans... or optical to electrical receivers.
[23:09.620 --> 23:12.720]  We tried sound modem over FRS, GMRS radios.
[23:13.240 --> 23:14.760]  Which is illegal by the way.
[23:14.940 --> 23:16.260]  Don't do it in the United States.
[23:16.960 --> 23:22.060]  We took precautions to make sure that we were causing the minimum interference possible.
[23:22.920 --> 23:25.040]  And long story short, don't bother.
[23:26.100 --> 23:30.480]  Even doing two radios at a time for bi-directional communication, it's pants.
[23:30.900 --> 23:31.180]  Right.
[23:31.380 --> 23:31.980]  Don't worry about it.
[23:32.100 --> 23:36.120]  We had a packet loss of about 50% and a latency of over a second.
[23:36.860 --> 23:39.580]  Please keep in mind that the two radios were a meter apart.
[23:43.180 --> 23:43.700]  Okay.
[23:44.200 --> 23:45.240]  So hang on.
[23:45.520 --> 23:45.600]  Yeah.
[23:45.600 --> 23:51.500]  So some of the solutions that we came up with, we actually found doing research on how other people have solved it.
[23:51.800 --> 23:58.820]  And for example, improvised parabolic antennas or waveguide antennas on wireless interfaces work really well.
[23:59.060 --> 24:19.100]  In fact, there is a project out there called WalkFi where you take a walk strainer and you poke a little hole in the bottom and you put a USB wireless interface through the hole and you connect it with an extension cable and the walk makes an excellent parabolic reflector.
[24:19.520 --> 24:21.800]  And without a linear amplifier, you can hit 10 kilometers.
[24:22.140 --> 24:22.580]  Right.
[24:22.840 --> 24:27.140]  In fact, this is done routinely in New Zealand and Afghanistan for Wi-Fi.
[24:27.400 --> 24:27.860]  Yeah.
[24:28.000 --> 24:34.800]  It's really, really hard to beat Wi-Fi equipment for availability, for cost, and for performance.
[24:34.800 --> 24:38.260]  It's, you know, improvised solutions aren't going to come close.
[24:39.000 --> 24:39.580]  So...
[24:39.580 --> 24:39.700]  Yeah.
[24:40.200 --> 24:47.000]  We also are doing some research in situations where the network infrastructure is compromised, but still functional.
[24:47.180 --> 24:53.900]  For example, if, as is being done in Syria, deep packet inspection hardware is popping up like mushrooms after a rainstorm.
[24:53.900 --> 25:02.960]  So, it is theoretically possible to connect a mesh network to the Internet to another mesh over a different connection medium.
[25:02.960 --> 25:09.740]  For example, by tunneling through another network, by using dial-up, which worked really well during the Arab Spring.
[25:10.820 --> 25:11.380]  Clotheslines.
[25:11.580 --> 25:11.840]  Pardon?
[25:11.980 --> 25:12.840]  Cat5 clotheslines.
[25:12.960 --> 25:13.880]  Cat5 clotheslines.
[25:14.040 --> 25:14.660]  Those work really well.
[25:15.420 --> 25:15.560]  Yeah.
[25:15.560 --> 25:17.000]  You could do it over VPN.
[25:17.700 --> 25:22.900]  You could theoretically do it over packet radio, but your bandwidth is going to be horrible because it tends to top out at 9600.
[25:24.040 --> 25:24.440]  Yeah.
[25:24.560 --> 25:28.400]  We have an amateur radio club at Hack DC, and yeah, they thought this was pretty interesting.
[25:28.500 --> 25:30.480]  We're going to try this at some point soon.
[25:30.940 --> 25:31.120]  Yes.
[25:31.920 --> 25:36.900]  There's also the possibility of sneaker net or IP over avian carrier, both of which work really well.
[25:37.000 --> 25:39.360]  I mean, think about how big micro SD cards are getting.
[25:39.540 --> 25:40.960]  That's a lot of bandwidth.
[25:41.860 --> 25:42.220]  Yeah.
[25:42.540 --> 25:44.940]  32 gigs on a card the size of your pinky nail.
[25:45.960 --> 25:46.640]  Latency sucks.
[25:47.020 --> 25:48.740]  Latency sucks, but you can't get the bandwidth.
[25:49.100 --> 25:49.140]  It does, but yeah.
[25:49.300 --> 25:50.500]  In an emergency, you're going to be picky.
[25:51.350 --> 25:51.740]  Yeah.
[25:52.020 --> 26:02.040]  I mean, at one point during the Arab Spring, it's been said that people were bundling messages onto USB keys and shooting them over the border with slingshots.
[26:03.100 --> 26:03.480]  Yeah.
[26:03.780 --> 26:04.340]  It worked.
[26:06.360 --> 26:09.600]  Or even some combination of any or all of the above.
[26:09.760 --> 26:12.620]  And one of the things that we're shooting for with Project Byzantium is improvisability.
[26:12.820 --> 26:15.800]  If this is what you got, what else do you have that you can apply to solve the problem?
[26:15.860 --> 26:15.980]  Yeah.
[26:16.140 --> 26:20.820]  Every emergency situation is different, and you're going to have to tailor your solution to what's going on.
[26:22.100 --> 26:25.740]  So there were a number of incidental use cases that have come up in the development of this.
[26:25.960 --> 26:29.020]  Various, you know, talks that we've given or, you know, sprints that we've had.
[26:29.100 --> 26:32.140]  People have come and said, well, you can use this for, you know, all these different things.
[26:32.920 --> 26:37.600]  Classrooms, conventions, extending the range of a home network, community municipal Wi-Fi.
[26:37.600 --> 26:43.420]  And these are great things that, you know, I encourage people to experiment with mesh networks for these purposes.
[26:43.720 --> 26:45.400]  But that's not our focus.
[26:45.580 --> 26:57.300]  Our focus is really on solving the emergency mesh network problem, where you're creating temporary infrastructure for emergency communication, not, you know, a permanent mesh network.
[26:57.300 --> 27:02.720]  There are lots of other groups that are working on that problem, and we support them.
[27:02.880 --> 27:03.840]  We are working with them.
[27:04.320 --> 27:18.400]  And, you know, the Freyfrunk network in Germany, the Athens Wireless Metropolitan Network, Commotion Wireless, which is a community mesh network firmware, Freedom Box, Rezulab, and Montreal, which is based on Freyfrunk.
[27:18.400 --> 27:30.940]  And the last three, in particular, we are in communication with their developers and working on interoperability, so that you can transition seamlessly from a Byzantium mesh network to one of their networks.
[27:33.900 --> 27:36.920]  And we've also have been doing some threat modeling.
[27:37.100 --> 27:46.580]  We've been doing some experiments, and we've been working closely with the dissidents in Egypt, Tunisia, and Syria on some of the electronic threats that they're seeing over there.
[27:46.580 --> 27:49.400]  And we've come up with a list of potential threats.
[27:50.280 --> 27:57.700]  The nice thing about NetHawk Wireless Mesh is that there's no central authority that says that you can't set up a mesh node or dictates how you configure your mesh node.
[27:58.400 --> 27:59.540]  That's also the downside.
[28:00.020 --> 28:02.460]  An attacker can set up a Byzantium mesh node as well.
[28:05.620 --> 28:12.040]  And this is unfortunately no different from an attacker walking to an ISP and saying, you're going to install this box into your rack.
[28:12.220 --> 28:13.720]  No, we're not telling you where the traffic goes.
[28:14.440 --> 28:15.120]  Gee, has that ever happened?
[28:17.020 --> 28:18.260]  Weird sense of deja vu.
[28:18.580 --> 28:19.280]  I've been awake for a few days.
[28:20.860 --> 28:24.960]  Also, a lot of distributed services don't encrypt federated traffic.
[28:25.260 --> 28:33.740]  And by that, we mean, let's say you have a massively distributed Twitter work-alike, and those find each other, and they synchronize one another.
[28:34.760 --> 28:40.920]  You can't count on that server using SSL or TLS to encrypt that traffic before it goes on on the mesh.
[28:40.920 --> 28:45.220]  Now, we think that we can mitigate that to a great extent by using Opportunistic IPsec.
[28:45.620 --> 28:46.640]  We're not there yet.
[28:46.780 --> 28:48.940]  It's on our roadmap for the next release.
[28:49.820 --> 28:50.060]  Yeah.
[28:50.420 --> 28:59.580]  I mean, that said, even if it is using TLS, you don't necessarily know who the other person is that's, you know, setting up that server it's federating with, so you don't necessarily know if it's trustworthy.
[29:00.540 --> 29:01.020]  So...
[29:01.020 --> 29:07.900]  And that's one of the reasons why in the captive portal page that a user sees when they first associate with the mesh, they're warned about this.
[29:08.100 --> 29:09.060]  Hi, you're on a mesh.
[29:09.180 --> 29:10.220]  We can't trust...
[29:10.220 --> 29:10.840]  You can't...
[29:10.840 --> 29:12.940]  You cannot necessarily trust who's running the nodes.
[29:13.180 --> 29:13.740]  You can't...
[29:13.740 --> 29:15.100]  You don't know who's watching.
[29:15.260 --> 29:16.160]  You may be under surveillance.
[29:16.940 --> 29:18.460]  Don't give away sensitive information.
[29:18.660 --> 29:19.620]  Don't do anything dumb.
[29:19.880 --> 29:20.420]  Click here to continue.
[29:23.340 --> 29:26.080]  Unfortunately, user education is the best we have for this.
[29:26.080 --> 29:26.500]  Right.
[29:27.480 --> 29:30.480]  Also, mesh routing protocols tend to suffer from route injection attacks.
[29:31.740 --> 29:37.000]  Because mesh nodes don't make any assumptions about who the nodes are around them.
[29:37.160 --> 29:41.480]  They just know that they'll periodically receive topology updates saying, hi, I'm here.
[29:41.480 --> 29:42.160]  I have a route.
[29:42.320 --> 29:44.080]  Or, hi, this route is still good.
[29:44.220 --> 29:46.080]  Or, uh-oh, this route is going away.
[29:47.060 --> 29:50.860]  That can be the mesh node two buildings down that your best friend set up.
[29:50.980 --> 29:52.940]  Or it could be somebody injecting routes.
[29:52.940 --> 30:00.840]  Now, the Babel protocol is implementing cryptographic authentication of routes to prevent someone from injecting routes manually.
[30:01.080 --> 30:01.420]  Yeah.
[30:01.620 --> 30:03.260]  This was started by the Quagga developers.
[30:03.440 --> 30:06.520]  And Babel is actually the first protocol to start supporting this.
[30:06.880 --> 30:07.240]  Okay.
[30:07.240 --> 30:15.520]  And there's also the fact that signal strength and signal quality and traffic levels are also factored into account when determining what route to relay traffic through.
[30:15.860 --> 30:19.720]  So non-adventageous routes may not be used if someone tries to inject them.
[30:20.640 --> 30:23.120]  The last problem that we've been working on is wireless jamming.
[30:23.560 --> 30:26.460]  Unfortunately, every wireless implementation is vulnerable to jamming.
[30:27.220 --> 30:28.180]  Byzantine is no different.
[30:29.940 --> 30:32.500]  The best you can really do is have the nodes jump channel.
[30:32.860 --> 30:39.540]  Or try to fly under the radar of whoever happens to be war driving looking for your mesh network.
[30:39.880 --> 30:43.600]  They may be looking for access points in managed mode, but not ad hoc mode.
[30:44.260 --> 30:44.660]  Yeah.
[30:44.820 --> 30:45.320]  And here's the thing.
[30:45.500 --> 30:52.600]  If you ever see an ad hoc network called free public Wi-Fi, you know, no one's going to suspect that of anything.
[30:53.180 --> 30:53.300]  Yeah.
[30:53.680 --> 30:56.340]  Everyone knows that actually, that doesn't actually go to the Internet, right?
[30:56.420 --> 30:57.100]  We've all tried that.
[30:59.140 --> 31:09.140]  And if your neighbor decides to act like a jerk and jam your mesh network, or carry out some other kind of DDoS attack, then you have the option of a BBRS, baseball bat restoration of service.
[31:15.440 --> 31:20.660]  We've also been analyzing and coming up with countermeasures for the threats being seen right now in the Middle East.
[31:22.380 --> 31:27.420]  As happened in Egypt last year, no routing tables means no traffic is going anywhere.
[31:27.760 --> 31:32.840]  On the other hand, if you're not using your ISPs infrastructure, you don't really have a problem.
[31:34.120 --> 31:39.460]  In Syria, they've been routinely cutting power to ISPs to knock out connectivity before sending tanks in the cities.
[31:40.920 --> 31:43.300]  A Byzantium mesh uses independent equipment.
[31:43.500 --> 31:47.260]  If a local ISP goes down, they're not killing the power on your laptop.
[31:47.580 --> 31:49.620]  They're not killing the power on your desktop PC.
[31:50.080 --> 31:52.320]  They're not unplugging your machinery from a UPS.
[31:53.400 --> 31:58.900]  Independent equipment means you have a greater degree of safety from an attack like that.
[31:59.060 --> 31:59.280]  Great.
[31:59.460 --> 32:04.320]  It's structurally harder because there's not one single entity you can go to to shut down the entire network.
[32:04.320 --> 32:07.980]  You have to go find every single person running a node and shut it down.
[32:08.520 --> 32:09.720]  And they can shut it down.
[32:10.080 --> 32:12.720]  And five minutes later, after the Jeep pulls away, they can boot it back up.
[32:13.260 --> 32:14.420]  Maybe it's on a different channel.
[32:15.780 --> 32:17.320]  Maybe they don't bother getting back to you.
[32:18.780 --> 32:24.120]  Also in Syria, we have gotten word that the military was war driving for open access points for a while.
[32:24.360 --> 32:25.680]  In particular, in the city of Homs.
[32:26.580 --> 32:31.900]  Ad hoc nodes from some of the information we got from dissidents over there seem to be slipping under the radar.
[32:32.240 --> 32:43.940]  They're looking for APs in managed mode and they're either ignoring ad hoc nodes entirely because their software can't cope with it or they're dismissing it as free public Wi-Fi.
[32:46.940 --> 32:49.220]  They might catch on to this in the future.
[32:49.540 --> 32:50.240]  We don't know if.
[32:50.360 --> 32:51.020]  We don't know when.
[32:51.600 --> 32:54.940]  All we can do is keep our eyes open, keep our ears open, and hope for the best.
[32:54.940 --> 33:00.380]  Now, one thing to keep in mind is that ad hoc networks are dependent on the BSSID and not the ESSID.
[33:01.380 --> 33:11.880]  So, in theory, Byzantium nodes all over a city can all be announcing different network names, but as long as they're using the same BSSID, they'll still interoperate with one another as expected.
[33:12.260 --> 33:12.340]  Right.
[33:12.500 --> 33:16.940]  And that makes it so that you don't have Byzantium all over the place because that would be conspicuous.
[33:18.100 --> 33:19.540]  Yeah, but Linksys is okay.
[33:21.100 --> 33:22.220]  And free public Wi-Fi.
[33:24.780 --> 33:28.340]  There are also social engineering attacks that can be carried out to gather intelligence.
[33:29.540 --> 33:37.160]  As we said earlier, we warn people not to give away sensitive information, especially to people that are calling themselves zero coal on the IRC channel.
[33:38.680 --> 33:40.360]  You really have to use discretion.
[33:40.740 --> 33:44.720]  And if it seems shady, you can always do a slash quit and come back five minutes later with a different Nick.
[33:46.380 --> 33:52.660]  Yeah, we all know here that the user education part is the hardest part of this to fix.
[33:53.080 --> 33:54.540]  That's always going to be a problem.
[33:54.800 --> 33:56.580]  That's the vulnerability that can't be solved.
[33:57.520 --> 34:00.780]  Yeah, all you can do is keep warning people and hope they listen.
[34:02.040 --> 34:11.120]  Also, we have some experience with operational security training online for communicating with dissidents, for communicating with journalists and things like that.
[34:12.360 --> 34:14.460]  The same training applies on a Byzantium mesh.
[34:15.040 --> 34:22.920]  And also, there is the issue of open-source intelligence surveillance of public sites like Facebook, Twitter, other social networks.
[34:23.140 --> 34:26.140]  We know this is happening in Syria quite heavily these days.
[34:26.500 --> 34:28.160]  It's happening in other countries as well.
[34:29.060 --> 34:32.600]  Byzantium resources don't touch the public net, especially if you don't...
[34:32.600 --> 34:34.600]  Byzantium resources don't touch the public net.
[34:34.600 --> 34:41.280]  So, a distributed Twitter work-alike or the IRC network will not federate with servers on the public Internet.
[34:41.680 --> 34:50.780]  So, if you're not actually touching the public Internet, then it is slightly safer than going on dial net or anything like that.
[34:50.960 --> 34:53.120]  Yeah, it might fly under the radar a little bit longer.
[34:53.400 --> 34:54.880]  It's also inherently localized.
[34:54.880 --> 34:59.460]  So, if someone is looking for something in this country, they're not going...
[34:59.460 --> 35:01.740]  They're probably not going to pick up on stuff you're talking about in this country.
[35:03.420 --> 35:05.420]  There are also some potential threats in other countries.
[35:06.060 --> 35:09.020]  Social engineering attacks and infiltrators work all around the world.
[35:10.160 --> 35:12.640]  Again, operational security warnings and training.
[35:12.800 --> 35:14.740]  That's the best solution we have.
[35:15.540 --> 35:20.720]  Passive surveillance is a problem that's somewhat mitigated by encryption of traffic between nodes.
[35:20.920 --> 35:24.900]  It's also mitigated by encryption of traffic from the client to the server and back again.
[35:25.100 --> 35:29.200]  So, if someone is just running TCP dump, they're just going to see SSL and TLS traffic.
[35:30.600 --> 35:33.460]  Active surveillance attacks are mitigated with OPSEC.
[35:33.580 --> 35:36.940]  Once again, let's keep banging on that nail until it's flush.
[35:37.720 --> 35:42.620]  Also, the fluidity of the network architecture helps to deter active surveillance somewhat.
[35:43.360 --> 35:49.140]  There's nothing that says that a Byzantium node can't be running in your backpack or can't be under your shirt.
[35:49.260 --> 35:50.060]  Or on the stage.
[35:50.060 --> 35:51.420]  Or on the stage.
[35:53.600 --> 35:54.740]  Good job, man.
[35:54.800 --> 35:55.160]  You're a ninja.
[36:00.580 --> 36:02.960]  It also avoids d-packet inspection equipment.
[36:03.480 --> 36:07.820]  So, again, not using an ISP's infrastructure.
[36:08.280 --> 36:11.400]  Any attacks that are built into the ISP's infrastructure won't touch you.
[36:12.620 --> 36:14.760]  Seizure of nodes is something of a problem.
[36:16.120 --> 36:18.760]  Byzantium Linux, by default, does not use persistent storage.
[36:19.080 --> 36:20.140]  Everything is running in RAM.
[36:20.320 --> 36:21.100]  It's a live distro.
[36:21.480 --> 36:25.440]  And when you kill the power in about 30 seconds, the contents of RAM are gone.
[36:27.100 --> 36:30.500]  There is support out of the box, however, for encrypted persistent storage.
[36:30.500 --> 36:42.040]  So, if you want to install Byzantium Linux on an external one terabyte hard drive, you can set up a data store, which is encrypted with looks, which is automatically mounted at boot.
[36:42.180 --> 36:43.480]  It'll prompt you for a passphrase.
[36:43.600 --> 36:44.520]  You enter your passphrase.
[36:44.640 --> 36:47.040]  You do enter strong passphrases, right?
[36:48.560 --> 36:49.040]  Yes.
[36:49.100 --> 36:49.580]  Yes.
[36:52.140 --> 36:53.460]  Yeah, they'll never guess the six.
[36:55.460 --> 36:57.440]  Also, nodes tend to be fairly innocuous.
[36:57.440 --> 37:01.640]  Case in point, the netbook, which has been sitting there at that...
[37:01.640 --> 37:02.020]  The whole time.
[37:02.260 --> 37:02.800]  I put it up there.
[37:02.800 --> 37:03.240]  Sorry.
[37:06.080 --> 37:07.940]  If we didn't notice, maybe they won't.
[37:11.480 --> 37:19.440]  And somebody sitting on a subway typing on their netbook looks pretty similar to somebody else sitting on the subway typing on a netbook.
[37:19.620 --> 37:24.720]  The only difference is one person has Microsoft Office open and the other person has a web browser open.
[37:24.720 --> 37:30.880]  That web browser is connected to the IRC server that they are running on their Byzantium node in their lap.
[37:32.060 --> 37:36.760]  Unless you grab someone, throw them on the ground, and go through their laptop, you're not really going to know what's going on.
[37:37.920 --> 37:45.140]  And, of course, there's the ever-present danger of your service provider being sent subpoenas and or gag orders.
[37:46.000 --> 37:48.940]  If you don't use the ISP's infrastructure, you are immune to that.
[37:48.940 --> 37:49.280]  Right.
[37:49.880 --> 37:53.740]  And, you know, in the case of a mesh network, there is no one ISP to contact.
[37:54.580 --> 37:55.000]  So...
[37:55.720 --> 37:56.140]  Okay.
[37:56.820 --> 37:59.320]  So what we need... we need more developers.
[37:59.480 --> 38:01.400]  Right now, it's basically just the three of us.
[38:01.820 --> 38:05.940]  We have a couple weekend warriors who come in for development sprints, but...
[38:06.580 --> 38:07.140]  But, yeah.
[38:07.300 --> 38:08.280]  We need developers.
[38:08.620 --> 38:20.660]  The control panel is written in Python, so if you know some Python, we can use your help, especially knowledge of I-18N and DBUS, so that we can make this internationalized, because not everyone speaks English, surprisingly enough.
[38:22.320 --> 38:29.340]  We need people with experience in Linux administration and shell scripting, because that's, you know, the rest of the software that we've written has been in Bash.
[38:31.060 --> 38:32.180]  User interface design.
[38:32.520 --> 38:35.820]  If, you know, when you guys, you know, get a copy, you'll see our skills with CSS.
[38:36.760 --> 38:37.120]  Yeah.
[38:39.560 --> 38:42.120]  We need people testing and filing bug reports.
[38:42.400 --> 38:43.860]  Please file bug reports.
[38:44.000 --> 38:45.780]  If you can fix it, send us a patch.
[38:45.900 --> 38:46.300]  It's on GitHub.
[38:47.300 --> 38:53.920]  But, you know, even just saying that, hey, there's a problem here, or with this hardware configuration, or I tried this and it didn't work, or I want this feature.
[38:54.580 --> 38:55.640]  That helps, too.
[38:56.620 --> 39:00.240]  Bug reports let us know that, you know, that there are things to fix.
[39:00.380 --> 39:02.200]  Otherwise, it's not going to get done.
[39:03.560 --> 39:05.900]  And we need people that don't have tech skills.
[39:05.920 --> 39:12.600]  If you're just, if you can translate, if you can write documentation, if you can, you know, promote us people who can, you know.
[39:13.340 --> 39:14.960]  That would be very, very helpful.
[39:15.100 --> 39:18.420]  Our end user documentation right now is not pretty.
[39:19.340 --> 39:19.860]  We have some.
[39:20.540 --> 39:27.640]  And also, we need people running Byzantium Linux on as many different laptops and computers as possible, because we're trying to build a hardware compatibility list.
[39:29.320 --> 39:35.340]  And we ran some gotchas when we were pressing the run of CDs that we'd like to hand out afterward.
[39:36.280 --> 39:39.060]  And we just need, we need more people running it.
[39:39.140 --> 39:40.000]  We need to know what works.
[39:40.140 --> 39:41.120]  We need to know what doesn't work.
[39:41.320 --> 39:42.640]  What firmware do we have to include?
[39:42.820 --> 39:44.440]  Do we have to install a kernel patch?
[39:44.560 --> 39:46.300]  Do we have to enable a driver when we compile?
[39:46.660 --> 39:47.860]  We need to know these things.
[39:47.860 --> 39:50.700]  And we have only a limited amount of hardware to do it on.
[39:51.020 --> 39:51.400]  Great.
[39:51.700 --> 39:53.720]  So we're crowdsourcing that testing to you guys.
[39:54.900 --> 39:56.620]  Who likes that word crowdsourcing, right?
[39:58.760 --> 40:03.020]  So yeah, any suggestions or problems you have, let us know, please.
[40:03.580 --> 40:05.420]  And this is where you can let us know.
[40:06.420 --> 40:08.140]  This is how you contact us.
[40:09.200 --> 40:11.160]  We have a channel on Freenode.
[40:11.160 --> 40:12.520]  We have, you know, a Twitter hashtag.
[40:12.920 --> 40:14.480]  The project's hosted on GitHub.
[40:15.200 --> 40:17.600]  And of course you can subscribe to our mailing list.
[40:17.880 --> 40:20.640]  And there's often a lot of interesting discussion on our mailing list.
[40:20.720 --> 40:21.620]  So I highly recommend it.
[40:22.940 --> 40:24.980]  And a lot of it tangentially related.
[40:25.220 --> 40:26.260]  So it's not just.
[40:26.460 --> 40:26.840]  Right.
[40:27.060 --> 40:33.520]  A lot of it is more the sort of general area of Zandium.
[40:33.520 --> 40:34.680]  We can't hear you.
[40:34.740 --> 40:34.960]  Yeah.
[40:35.060 --> 40:35.820]  Do you want to say that again?
[40:35.980 --> 40:36.380]  No microphone?
[40:37.560 --> 40:37.960]  Oh!
[40:38.380 --> 40:38.820]  Watch out.
[40:39.220 --> 40:40.300]  These silly microphones.
[40:41.300 --> 40:46.540]  So on the mailing list, it's not just the Byzantium specific stuff.
[40:46.740 --> 40:48.300]  We have a lot of tangential stuff.
[40:48.480 --> 40:53.480]  Like we're looking for services that we can use to put on here to make this useful.
[40:53.600 --> 40:54.700]  If there's no Internet connection.
[40:55.280 --> 40:55.900]  Stuff like that.
[40:56.120 --> 40:57.880]  There's a lot of that kind of stuff that comes across.
[40:57.880 --> 41:06.260]  There's lots of interesting sort of articles and whatnot that come across that are not directly related to Byzantium, but are related to that whole idea space.
[41:06.260 --> 41:06.540]  Yeah.
[41:06.800 --> 41:08.700]  Discussions of mesh networking in general even.
[41:09.060 --> 41:11.320]  So if you're interested in mesh networking, it's a good place to.
[41:11.420 --> 41:13.180]  And it's not a super amount of traffic.
[41:13.320 --> 41:15.520]  So it's not going to flood your inbox or anything.
[41:15.980 --> 41:20.580]  We put the developer stuff in a digest on the list.
[41:20.800 --> 41:21.320]  So it's not.
[41:21.500 --> 41:21.800]  Yeah.
[41:21.800 --> 41:26.500]  So immediately after this talk, we will be downstairs in the hackerspace area.
[41:26.500 --> 41:30.260]  We have 500 copies on CD to give away.
[41:30.620 --> 41:35.860]  And we're going to try and build the biggest Byzantium mesh network to date here at HOPE.
[41:36.100 --> 41:38.660]  It took us 26 hours to burn them.
[41:39.060 --> 41:40.140]  Please come get them.
[41:42.800 --> 41:43.440]  Yes.
[41:44.460 --> 41:48.560]  That does include time for, you know, making it work.
[41:48.960 --> 41:51.420]  And, you know, making the machine work.
[41:51.840 --> 41:52.200]  Yeah.
[41:52.320 --> 41:53.780]  Our CD duplicator is a bit dodgy.
[41:54.300 --> 41:54.820]  Right.
[41:54.820 --> 41:57.680]  So comments, questions, suggestions, anybody?
[41:57.920 --> 41:59.460]  We have about 10 minutes for questions.
[41:59.640 --> 42:02.120]  So if people have them, please line up behind me and I'll get out of the way.
[42:02.440 --> 42:02.800]  Excellent.
[42:03.560 --> 42:04.040]  Where are you?
[42:04.120 --> 42:04.360]  Thank you.
[42:04.480 --> 42:05.100]  Oh, there you are.
[42:06.900 --> 42:07.900]  Just a quick question.
[42:08.040 --> 42:08.640]  There's a room here?
[42:09.040 --> 42:11.260]  I was under the impression it was just this one row.
[42:13.560 --> 42:17.460]  Do you have any plans to integrate it into router firmware?
[42:17.460 --> 42:19.160]  It already is.
[42:19.640 --> 42:20.440]  Well, okay.
[42:20.600 --> 42:28.920]  So the mesh routing software itself is already compiled for various, you know, router from us, particularly open work.
[42:29.100 --> 42:32.640]  But like we said, that's permanent infrastructure and that's not something that we're focusing on.
[42:32.760 --> 42:35.820]  We're focusing on, you know, commodity hardware that people already have.
[42:35.960 --> 42:42.000]  In an emergency, reflashing your router is a lot harder than sticking in a CD and rebooting your machine.
[42:42.220 --> 42:48.860]  But the other network, the other mesh routing project we mentioned, a lot of them focus on just, you know, on just that.
[42:49.180 --> 42:51.280]  More permanent infrastructure mesh networks.
[42:51.620 --> 42:59.200]  The real value added that we bring is that we have the stack of services on top of that software.
[42:59.400 --> 43:03.640]  Because if it's just that software, all you have to do is distribute configuration files.
[43:04.640 --> 43:05.140]  Okay.
[43:05.560 --> 43:10.080]  Otherwise, you kind of have a network that doesn't have anything going on on it.
[43:10.080 --> 43:17.400]  So, we added in those services so that it was easy to kind of motivate people to actually use it.
[43:17.740 --> 43:24.220]  Instead of, you know, having to try and get out to the Internet to do things, you can do things locally without a whole lot of setup.
[43:26.380 --> 43:27.620]  Two pretty short questions.
[43:27.860 --> 43:37.820]  One is, I know Commotion has done some work on trying to deal with temporary connections to the real Internet or to the rest of the Internet.
[43:37.820 --> 43:41.980]  Is there any support within Byzantium for multiple bad connections to the net?
[43:42.200 --> 43:46.840]  The other question I have is, how solid is the 512 megabytes of RAM requirement you have on GitHub?
[43:47.440 --> 43:51.400]  Which, since I love Raspberry Pis, seems like a hell of a lot to me, really.
[43:51.960 --> 43:52.480]  Okay.
[43:52.820 --> 44:03.040]  So, if you're running it on x86, it actually, the 512 is based on running the KDE or LXDE, you know, desktop environments.
[44:03.320 --> 44:06.240]  If you're not running those desktop environments, obviously, you need a lot less RAM.
[44:07.140 --> 44:11.100]  But, you know, that's how we've been testing it, is by booting up a full, you know.
[44:11.280 --> 44:14.340]  We have both desktop environments in the ISO.
[44:14.500 --> 44:16.560]  And the ISO is still only about 400 megabytes.
[44:16.680 --> 44:17.740]  It's actually less than 400 megabytes.
[44:17.740 --> 44:18.560]  There's also OpenBox.
[44:19.340 --> 44:19.700]  Yeah.
[44:19.940 --> 44:25.180]  So, but your first question was about, we support having multiple gateways.
[44:25.180 --> 44:30.200]  And actually, we seamlessly, or we in the next release, we will seamlessly interoperate with commotion networks.
[44:30.420 --> 44:36.360]  We use the same BSSID as they do, so that you're already on the same, you know, ad hoc network.
[44:36.560 --> 44:40.000]  It's just a matter of getting the routing software to talk to each other.
[44:40.220 --> 44:42.740]  And that's, like, that close to being done.
[44:45.140 --> 44:45.540]  Hi.
[44:46.660 --> 44:50.180]  I was wondering if you, I had two questions, but you added a third.
[44:50.380 --> 44:51.660]  And so, I'm just gonna go ahead.
[44:51.660 --> 44:52.220]  Yeah.
[44:52.220 --> 44:57.820]  I was wondering if you considered IPv6 instead of the zero-conf IP things.
[44:57.980 --> 44:58.320]  We already are.
[44:58.320 --> 44:58.800]  Yeah.
[44:58.920 --> 45:01.640]  It actually already uses both IPv4 and IPv6.
[45:01.760 --> 45:02.020]  Okay.
[45:02.120 --> 45:03.960]  So, you get auto-configuration going on.
[45:03.960 --> 45:04.160]  Yeah.
[45:04.340 --> 45:06.520]  It requires IPv6, so it's already there.
[45:06.780 --> 45:07.160]  All right.
[45:08.140 --> 45:11.660]  The second question was about route.
[45:12.460 --> 45:15.560]  You said that you were authenticating routes.
[45:15.780 --> 45:20.760]  And I was wondering if you could expand on, or, man, how you would do that and how it works.
[45:21.660 --> 45:23.000]  We weren't running that build of Babel yet.
[45:23.160 --> 45:32.120]  When we went into code freeze, 4.2 alpha, I think it was nine hours later, the next release of the Babel demon came out, which had preliminary support for it.
[45:32.500 --> 45:34.120]  But how does it work, though?
[45:34.260 --> 45:34.960]  Like, where is...
[45:34.960 --> 45:35.540]  Like, how does...
[45:35.540 --> 45:38.320]  Like, is there a central authority, or how do you resolve that problem?
[45:38.480 --> 45:42.360]  I haven't read the code yet, because we were too busy trying to get this release ready.
[45:42.360 --> 45:43.960]  Yeah, we've been kind of distracted.
[45:44.140 --> 46:00.960]  But if you read the spec for Babel, there are actually two different places within the packets that it uses that allow for you to store that kind of cryptographic information, so that the packet can be checked against, you know, a signature that it hasn't been,
[46:01.000 --> 46:04.980]  you know, arbitrarily modified by, you know, in the middle.
[46:05.140 --> 46:09.880]  And, again, it's called Byzantium because we're trying to build a Byzantine fault-tolerant system.
[46:09.880 --> 46:11.500]  So, that's...
[46:11.500 --> 46:14.080]  There will be more details on that shortly.
[46:14.420 --> 46:17.220]  You know, it's still in development, active development.
[46:17.400 --> 46:19.160]  So, it's not quite finalized yet.
[46:19.340 --> 46:22.820]  And we haven't done any internal to the mesh.
[46:22.940 --> 46:27.760]  We haven't implemented any DNS, because we don't want a central authority doing anything.
[46:28.180 --> 46:28.560]  Yeah.
[46:28.740 --> 46:32.780]  That's actually one of the really hard problems, is decentralizing name services.
[46:33.120 --> 46:38.860]  Because, you know, handling name arbitration without a central authority is a challenge.
[46:39.600 --> 46:40.160]  All right.
[46:40.240 --> 46:40.480]  Thank you.
[46:45.080 --> 46:51.220]  You mentioned, you addressed this earlier in talking about sparsity of nodes in an emergency environment.
[46:51.400 --> 46:55.820]  Obviously, most people in a city are not going to be running Byzantium.
[46:56.160 --> 47:00.360]  So, there's going to be mesh networks that are disconnected.
[47:01.140 --> 47:03.480]  What have you done to address this?
[47:03.660 --> 47:15.800]  Because the Internet is still point to point, and you're not using a document-based routing, are you focusing on older, for example, older protocols like UUCP to transfer messages, or are you addressing that at all?
[47:16.060 --> 47:17.540]  Well, it's interesting that you mention that.
[47:18.560 --> 47:28.480]  We built Byzantium Linux on top of a distribution called Porteus Linux, which has another fork called FIDOSlax, which is a full implementation of the FidoNet protocol.
[47:29.400 --> 47:31.100]  And we have their package set.
[47:31.320 --> 47:33.200]  We're looking at it to see how it works.
[47:33.480 --> 47:43.260]  And as we add services to the mesh, we're also looking at doing high latency or bundle-based synchronization between meshes.
[47:43.860 --> 47:46.760]  So, hopefully, at some point, you'll be able to plug a USB key in.
[47:46.960 --> 47:49.240]  It'll tell you to remove it.
[47:49.320 --> 47:57.620]  You remove it, get on your bike, go two or three blocks away to the next node, plug it in, it'll synchronize, and basically, you're playing round-robin.
[47:58.040 --> 48:12.480]  We also talked a little bit about that in the Zen of intermesh links thing, where what we'd ideally like to see is one or two nodes, one of which has a mesh interface with a client interface, and the other is a parabolic dish, which goes across town to the next mesh.
[48:13.000 --> 48:13.280]  Great.
[48:14.400 --> 48:16.420]  The theory of sound, we know it works.
[48:16.600 --> 48:17.460]  It's being done.
[48:17.720 --> 48:18.480]  It's being done.
[48:18.580 --> 48:19.160]  It's walk-by.
[48:20.020 --> 48:23.260]  We have yet to build that functionality into our control panel.
[48:23.720 --> 48:26.460]  That is on the roadmap for the next release.
[48:26.920 --> 48:28.540]  Yeah, we all have full-time jobs.
[48:28.820 --> 48:31.400]  So, we're doing this in the evenings, on the weekends.
[48:31.660 --> 48:36.780]  We're giving as much time as we can, but there's a lot to do, and there's just the three of us.
[48:39.220 --> 48:44.380]  Have you experimented with any voice over IP protocols over Babel meshes?
[48:45.080 --> 48:49.600]  We have, in one of the early releases, we actually had Mumble set up.
[48:50.340 --> 48:52.800]  We had a Mumble server, which was automatically configured.
[48:52.960 --> 48:54.200]  We also had a couple of Mumble clients.
[48:54.500 --> 48:58.300]  And the problem was actually, the Mumble package keeps breaking fonts in X.
[48:58.700 --> 48:58.960]  Yeah.
[48:59.500 --> 49:11.740]  And we fought with it for a while, and realized that it was more important to get the control panel stabilized, and get another release out, so we can get user feedback, than it was to fight with Mumble, and figure out how to unbreak the fonts.
[49:11.740 --> 49:19.620]  But not dissimilar from voice over IP, one of the first things we usually do, when we get a network up and running, is streaming audio and YouTube videos.
[49:21.660 --> 49:24.380]  You mentioned there's a web server included.
[49:24.700 --> 49:25.120]  Yes.
[49:25.500 --> 49:27.380]  But there's no central DNS, right?
[49:27.580 --> 49:29.880]  How does one connect to that web server?
[49:30.100 --> 49:30.900]  We cheated.
[49:33.240 --> 49:39.020]  When you get past the first capital portal page, there's a page with a bunch of links of services.
[49:39.020 --> 49:39.360]  Okay.
[49:39.560 --> 49:42.380]  So those are going directly to the IP instead of...
[49:42.380 --> 49:42.640]  Does that get updated?
[49:42.920 --> 49:44.540]  Yeah, it gets updated through Avahi.
[49:44.920 --> 49:45.060]  Right.
[49:45.140 --> 49:49.520]  So it listens for Avahi messages with certain attributes.
[49:49.740 --> 49:50.320]  Service announcements.
[49:50.440 --> 49:50.960]  Yeah, service announcements.
[49:50.960 --> 49:54.440]  Also the IRC server, and whatever else you want to have, database server.
[49:54.740 --> 49:55.360]  Right, right.
[49:55.500 --> 50:05.800]  So instead of having a domain name service, we're gonna have nodes announce what services they have, so that it can be, you know, you can look it up on a website and see which services are real on the mesh.
[50:06.400 --> 50:06.800]  Yeah.
[50:07.020 --> 50:10.540]  And you would access them by clicking on a link which references IP addresses and not host names.
[50:13.580 --> 50:24.100]  So in your hardware testing, or in the case of someone having one laptop, desktop, whatever, have you done any VM testing to see if the pass-through networking's a problem?
[50:24.100 --> 50:26.900]  That is our primary development configuration.
[50:28.260 --> 50:28.540]  So...
[50:28.540 --> 50:29.560]  Yeah, we've...
[50:29.560 --> 50:30.040]  I didn't need to get paid.
[50:30.060 --> 50:30.980]  Oh no, the pass-through.
[50:31.140 --> 50:32.160]  Specifically USB pass-through?
[50:32.420 --> 50:32.580]  Have you...
[50:32.580 --> 50:33.060]  Yeah, that's what I do.
[50:33.220 --> 50:33.560]  Okay.
[50:33.900 --> 50:33.980]  Okay.
[50:34.100 --> 50:34.460]  Yeah.
[50:37.040 --> 50:38.300]  Works in VirtualBox.
[50:38.520 --> 50:38.740]  Okay.
[50:39.240 --> 50:40.000]  And second question.
[50:40.160 --> 50:44.260]  Have you considered a DARPA fast-track grant to assist you with the development?
[50:45.560 --> 50:46.240]  The thing is...
[50:46.240 --> 50:48.520]  The military may have an interest in helping...
[50:48.520 --> 50:48.560]  Yes.
[50:48.840 --> 50:50.860]  ...people, but may have an interest in keeping other people off the Internet.
[50:50.960 --> 50:50.980]  Yeah.
[50:50.980 --> 50:53.880]  So grants are still something that we've been discussing internally.
[50:54.100 --> 50:57.620]  Not just whether or not we should, but, you know, what we would do with that money.
[50:57.700 --> 50:58.660]  This is not something...
[50:58.660 --> 50:59.620]  You know, we're not doing robotics.
[50:59.740 --> 51:01.160]  There's not a lot of expensive equipment involved.
[51:01.460 --> 51:07.900]  And it's not really an option for any one of us right now to take time off from work and do this full-time.
[51:08.280 --> 51:13.300]  So, you know, what would we do with that money other than, you know, just promoting and stuff and...
[51:13.300 --> 51:17.140]  Pay yourselves, because they actually put in the CFT.
[51:17.340 --> 51:17.520]  Right.
[51:17.620 --> 51:22.880]  I mean, we'd rather put that money towards like, you know, we would try to find something, you know, that would get that...
[51:22.880 --> 51:23.900]  One more question.
[51:24.040 --> 51:24.180]  Yeah.
[51:25.060 --> 51:26.340]  I think mine was extra.
[51:26.660 --> 51:26.880]  Okay.
[51:27.260 --> 51:27.340]  Okay.
[51:27.440 --> 51:34.380]  I'm wondering if OpenGarden is a potential group that you would collaborate with on interoperability.
[51:35.400 --> 51:36.260]  We would love to.
[51:36.460 --> 51:40.080]  There are dozens of different mesh networking groups out there.
[51:40.600 --> 51:42.220]  We'd love to collaborate with all of them.
[51:42.360 --> 51:44.680]  We just haven't met anyone to talk to yet.
[51:44.680 --> 51:47.660]  I think that's a smartphone-based mesh networking system.
[51:48.160 --> 51:48.720]  Yeah.
[51:49.120 --> 51:52.520]  There's a group that's doing, like, Android...
[51:52.520 --> 51:53.340]  What is it?
[51:53.560 --> 51:55.620]  The Servo Project from Guardian Project.
[51:56.080 --> 51:56.320]  Yeah.
[51:56.480 --> 51:59.100]  So, there are other groups out there that we would love to collaborate with.
[51:59.180 --> 51:59.960]  We just need to meet someone.
[52:01.200 --> 52:01.560]  Cool.
[52:01.940 --> 52:03.880]  Let's hear it for Project Ben's presentation.
[52:04.200 --> 52:04.680]  Thank you, guys.
[52:08.870 --> 52:15.250]  And, once again, we'll be giving a mesh networking workshop on the mezzanine in the Hackerspace Village.
[52:15.490 --> 52:17.210]  We'll be down there in about 10 minutes.
[52:17.470 --> 52:20.850]  We have 500 copies of Byzantium Linux, 0.2 raw for the handout.
[52:21.290 --> 52:22.330]  Let's stress test it.
[52:22.330 --> 52:22.430]  The thing next is a quarteringsy clock.
[52:22.430 --> 52:22.470]  At the same time point we could chat here.
[52:22.490 --> 52:22.570]  A longix data score.
[52:23.010 --> 52:23.230]  It's a quartering app!