WEBVTT 00:00:00.000 --> 00:00:03.500 You know that feeling when you're trying to load 00:00:03.500 --> 00:00:05.700 a web page on your phone and you step into an 00:00:05.700 --> 00:00:07.759 elevator or just hit a dead zone? Oh yeah, the 00:00:07.759 --> 00:00:10.080 spinning wheel of doom. Exactly, the spinning 00:00:10.080 --> 00:00:12.800 wheel of doom. You just stare at it completely 00:00:12.800 --> 00:00:16.379 paralyzed until your phone manages to, I don't 00:00:16.379 --> 00:00:18.519 know, scrape together a signal again. We are 00:00:18.519 --> 00:00:20.800 so incredibly used to the internet just being 00:00:20.800 --> 00:00:24.370 this instant, always on utility. Right. But what 00:00:24.370 --> 00:00:26.329 happens when you need to send a really crucial 00:00:26.329 --> 00:00:29.210 piece of data and that dead zone isn't just a 00:00:29.210 --> 00:00:32.770 concrete tunnel on your commute, but like millions 00:00:32.770 --> 00:00:36.729 of miles of freezing deep space or disaster zone 00:00:36.729 --> 00:00:39.289 on Earth. Yeah, where the entire physical infrastructure, 00:00:39.429 --> 00:00:41.850 the cell towers, the fiber optics, it's all been 00:00:41.850 --> 00:00:44.189 completely wiped off the map. Yeah, that's exactly 00:00:44.189 --> 00:00:46.369 our mission for today's deep dive. We are going 00:00:46.369 --> 00:00:48.649 to uncover how communication actually functions 00:00:48.649 --> 00:00:50.710 when the traditional Internet completely breaks 00:00:50.710 --> 00:00:53.159 down. It's a fascinating topic. It really is. 00:00:53.460 --> 00:00:55.240 We're going to explore the mechanics of something 00:00:55.240 --> 00:00:59.100 called delay tolerant networking, or DTN for 00:00:59.100 --> 00:01:02.509 short. Today's source is a really comprehensive 00:01:02.509 --> 00:01:05.189 Wikipedia article on delay -tolerant networking, 00:01:05.829 --> 00:01:08.109 which goes deep into its history, its technical 00:01:08.109 --> 00:01:10.870 architecture, and some genuinely mind -blowing 00:01:10.870 --> 00:01:13.909 real -world implementations. It forces us to 00:01:13.909 --> 00:01:16.349 completely shatter our fundamental assumptions 00:01:16.349 --> 00:01:19.930 about how communication is supposed to work. 00:01:20.069 --> 00:01:23.049 How so? Well, standard internet routing relies 00:01:23.049 --> 00:01:26.040 on a very comforting, very strict illusion. It's 00:01:26.040 --> 00:01:28.680 the expectation of a continuous unbroken path 00:01:28.680 --> 00:01:31.209 from the sender all the way to the receiver. 00:01:31.469 --> 00:01:34.030 Like a physical wire or a clean radio signal. 00:01:34.269 --> 00:01:37.030 Exactly. But in extreme environments, whether 00:01:37.030 --> 00:01:39.409 that's the bottom of the ocean or the surface 00:01:39.409 --> 00:01:42.030 of Mars, that continuous path simply does not 00:01:42.030 --> 00:01:44.870 exist. So why exactly does the normal internet 00:01:44.870 --> 00:01:47.290 fail so spectacularly when things get a little 00:01:47.290 --> 00:01:49.329 rough out there? To understand the failure, we 00:01:49.329 --> 00:01:51.170 really have to look at the mechanical rules that 00:01:51.170 --> 00:01:52.909 govern standard routing. Right, the protocols. 00:01:53.310 --> 00:01:55.750 Yeah, traditional routing protocols. You might 00:01:55.750 --> 00:01:58.049 see them referred to in the source by technical 00:01:58.049 --> 00:02:02.640 names like AODV or DSR. And these protocols are, 00:02:02.659 --> 00:02:05.799 well, they're essentially uncompromising perfectionists. 00:02:06.239 --> 00:02:08.099 Perfectionists. Yeah. Because before they forward 00:02:08.099 --> 00:02:10.960 a single byte of your actual email or web page, 00:02:11.400 --> 00:02:14.219 they demand to establish a complete end -to -end 00:02:14.219 --> 00:02:16.439 route. Oh, I see. So they won't even try unless 00:02:16.439 --> 00:02:18.580 the whole path is clear. Right. They want to 00:02:18.580 --> 00:02:20.520 shake hands with every single router along the 00:02:20.520 --> 00:02:23.139 path. The sender says, are you there? And the 00:02:23.139 --> 00:02:25.139 receiver has to immediately say, yes, I'm here. 00:02:25.770 --> 00:02:28.689 Only after that entire road is mapped out and 00:02:28.689 --> 00:02:31.250 confirmed open does the actual data start flowing. 00:02:31.550 --> 00:02:33.889 Okay, let's unpack this. Traditional internet 00:02:33.889 --> 00:02:36.270 routing is essentially like a highway system. 00:02:36.950 --> 00:02:40.050 If you're driving from New York to LA and there's 00:02:40.050 --> 00:02:43.069 a single bridge out somewhere in Colorado, standard 00:02:43.069 --> 00:02:45.550 routing says traffic stops entirely. Yep, you 00:02:45.550 --> 00:02:47.750 can't even start your road trip. But delay tolerant 00:02:47.750 --> 00:02:50.289 networking, it flips that script completely. 00:02:50.409 --> 00:02:52.789 It seems much more like a relay race where a 00:02:52.789 --> 00:02:55.770 runner might have to camp out for three days 00:02:55.770 --> 00:02:57.849 in a tent waiting for the next runner to finally 00:02:57.849 --> 00:02:59.969 show up. That is a brilliant way to visualize 00:02:59.969 --> 00:03:03.009 it. And the origins of this really racist concept, 00:03:03.270 --> 00:03:05.710 they actually go back significantly further than 00:03:05.710 --> 00:03:09.229 the modern smartphone era. Really? How far back? 00:03:09.289 --> 00:03:12.210 All the way to the 1970s. As computers first 00:03:12.210 --> 00:03:15.189 started shrinking, researchers began tinkering 00:03:15.189 --> 00:03:18.009 with ad hoc routing for mobile computers. So 00:03:18.009 --> 00:03:20.050 even back then, they were thinking about mobility. 00:03:20.629 --> 00:03:23.050 Exactly. They were asking, you know, how do devices 00:03:23.050 --> 00:03:25.270 talk to each other if they're constantly moving 00:03:25.270 --> 00:03:27.849 around? And if you fast forward to the 1990s, 00:03:27.949 --> 00:03:31.150 the explosion of wireless protocols really supercharged 00:03:31.150 --> 00:03:33.250 this research. And that became known as mobile 00:03:33.250 --> 00:03:36.150 ad -hoc networks, right? Or MENETs. Yes, MENETs. 00:03:36.150 --> 00:03:38.550 But those were still largely focused on earthbound 00:03:38.550 --> 00:03:41.110 mobility. Right. Because at the exact same time, 00:03:41.250 --> 00:03:44.250 we had DARPA funding NASA and the MITRE Corporation 00:03:44.250 --> 00:03:47.400 to build something that sounds... Frankly, straight 00:03:47.400 --> 00:03:49.780 out of a sci -fi novel. The Interplanetary Internet. 00:03:49.960 --> 00:03:52.620 The IPN, which is just the coolest name. It is. 00:03:52.819 --> 00:03:55.360 And that project brought in Internet pioneer 00:03:55.360 --> 00:03:58.800 Vint Cerf. Oh, wow. The guy who basically helped 00:03:58.800 --> 00:04:01.639 invent the Internet. Exactly. He famously helped 00:04:01.639 --> 00:04:03.780 design the original fundamental architecture 00:04:03.780 --> 00:04:06.719 of the terrestrial Internet. But when he and 00:04:06.719 --> 00:04:08.780 his team looked at deep space communication, 00:04:09.360 --> 00:04:11.819 they realized their own invention was totally 00:04:11.819 --> 00:04:14.340 useless. Because of the distances involved? Yeah. 00:04:14.419 --> 00:04:17.339 In space, you are dealing with brutal physics 00:04:17.339 --> 00:04:20.189 -dictated realities. I mean, if you want to talk 00:04:20.189 --> 00:04:23.329 to Mars, light speed delay means a simple hello 00:04:23.329 --> 00:04:25.529 can take up to 20 minutes just to get there. 00:04:25.629 --> 00:04:27.490 And another 20 minutes to get the response back. 00:04:27.670 --> 00:04:30.310 Exactly. So a standard Internet handshake would 00:04:30.310 --> 00:04:33.029 just time out and fail instantly. Plus, you have 00:04:33.029 --> 00:04:35.610 immense packet corruption from solar radiation 00:04:35.610 --> 00:04:37.910 out there. So they needed a system that expected 00:04:37.910 --> 00:04:40.350 massive delays and broken links as the default 00:04:40.350 --> 00:04:42.610 state rather than an exception. Right. They built 00:04:42.610 --> 00:04:45.310 it specifically for spacecraft. But how did it 00:04:45.310 --> 00:04:47.029 get back down to Earth? Because obviously we 00:04:47.029 --> 00:04:50.420 use this here now. Up in around 2002, a researcher 00:04:50.420 --> 00:04:53.759 named Kevin Fall realized something crucial about 00:04:53.759 --> 00:04:56.600 what the space teams were building. He took these 00:04:56.600 --> 00:04:59.639 interplanetary ideas and adapted them for terrestrial 00:04:59.639 --> 00:05:01.959 networks. And he's the one who officially coined 00:05:01.959 --> 00:05:04.920 the term delay -tolerant networking, or DTN. 00:05:05.240 --> 00:05:07.620 Yes. He recognized that space isn't the only 00:05:07.620 --> 00:05:09.680 place where the internet breaks. Because if you're 00:05:09.680 --> 00:05:11.800 in a hurricane zone, you essentially have the 00:05:11.800 --> 00:05:14.439 exact same communication problem as a Mars rover. 00:05:14.720 --> 00:05:17.579 If we connect this to the bigger picture... Disruption 00:05:17.579 --> 00:05:20.740 is literally everywhere. It happens because of 00:05:20.740 --> 00:05:23.019 the physical limits of wireless radio range. 00:05:23.259 --> 00:05:26.000 Sure, like being too far from a router? Right. 00:05:26.399 --> 00:05:28.800 Or it happens when you have a sparse network 00:05:28.800 --> 00:05:31.740 of mobile nodes -like rescue workers in a forest 00:05:31.740 --> 00:05:35.000 that rarely cross paths. It happens because of 00:05:35.000 --> 00:05:37.139 strict energy constraints on battery -powered 00:05:37.139 --> 00:05:40.220 sensors or malicious jamming attacks or just 00:05:40.220 --> 00:05:42.600 overwhelming environmental noise. So the bridge 00:05:42.600 --> 00:05:45.480 -out scenario is an incredibly common earth problem 00:05:45.480 --> 00:05:48.819 too. Very common. So we know the why. Traditional 00:05:48.819 --> 00:05:51.680 networks need a perfectly paved highway and in 00:05:51.680 --> 00:05:54.019 extreme environments that highway is constantly 00:05:54.019 --> 00:05:56.660 crumbling. That brings us to the how. The mechanics 00:05:56.660 --> 00:05:59.800 of it. Yeah. How does DTN mechanically solve 00:05:59.800 --> 00:06:02.459 this problem without a continuous path? If the 00:06:02.459 --> 00:06:04.439 bridge is out, how does the data keep moving? 00:06:04.699 --> 00:06:07.199 The secret sauce is an approach called store 00:06:07.199 --> 00:06:10.699 and forward. Store and forward. Yeah. Instead 00:06:10.699 --> 00:06:12.980 of demanding an end -to -end path right this 00:06:12.980 --> 00:06:16.120 second, data is moved incrementally. Okay, give 00:06:16.120 --> 00:06:18.040 me an example. Let's say you have a network of 00:06:18.040 --> 00:06:21.220 drones. Drone A receives a message intended for 00:06:21.220 --> 00:06:24.060 base camp. But Basecamp is currently out of range. 00:06:24.360 --> 00:06:26.300 So a normal network would just drop it. Exactly. 00:06:26.439 --> 00:06:29.339 Abroad it and throw an error. But instead, Drone 00:06:29.339 --> 00:06:33.000 A stores the data securely in its own local hard 00:06:33.000 --> 00:06:35.860 drive. It simply hold onto it, flying around, 00:06:36.300 --> 00:06:38.920 until it eventually encounters Drone B, which 00:06:38.920 --> 00:06:41.420 happens to be moving closer to the final destination. 00:06:41.540 --> 00:06:44.199 Oh, I see. It shifts the entire burden of success 00:06:44.199 --> 00:06:46.939 from the global network path down to the individual 00:06:46.939 --> 00:06:49.740 devices. They basically act as independent couriers. 00:06:49.899 --> 00:06:52.709 Exactly like couriers. But wait, if drone A meets 00:06:52.709 --> 00:06:55.029 drone B, how does it decide whether to actually 00:06:55.029 --> 00:06:56.870 hand over the data? Like, are there different 00:06:56.870 --> 00:06:59.589 strategies for how this relay race is run? There 00:06:59.589 --> 00:07:01.790 absolutely are. And the strategy you choose depends 00:07:01.790 --> 00:07:04.170 heavily on the physical resources of your network. 00:07:04.350 --> 00:07:06.829 What kind of resources? Well, storage space and 00:07:06.829 --> 00:07:09.810 bandwidth. If you are operating in an environment 00:07:09.810 --> 00:07:12.329 where those are practically unlimited, you might 00:07:12.329 --> 00:07:15.170 use a strategy called epidemic routing. Epidemic 00:07:15.170 --> 00:07:18.290 routing? That sounds like a digital virus. How 00:07:18.290 --> 00:07:20.720 does that work in practice? It essentially functions 00:07:20.720 --> 00:07:24.300 exactly like one. In epidemic routing, the network 00:07:24.300 --> 00:07:27.220 deliberately infects itself with the data. Infects 00:07:27.220 --> 00:07:29.740 itself. Yeah. So when drone A meets drone B, 00:07:29.939 --> 00:07:31.959 it doesn't ask if drone B is even going the right 00:07:31.959 --> 00:07:34.540 way. It just blindly copies the message and hands 00:07:34.540 --> 00:07:37.240 it over. And then they both fly off and do the 00:07:37.240 --> 00:07:39.759 same thing to the next drone they meet. Exactly. 00:07:40.379 --> 00:07:43.399 Every single time any node encounters another 00:07:43.399 --> 00:07:46.399 node, it duplicates and passes the message. The 00:07:46.399 --> 00:07:48.560 network creates hundreds or thousands of copies. 00:07:48.779 --> 00:07:52.379 Just relying on the sheer statistical probability 00:07:52.379 --> 00:07:54.699 that at least one of those copies will eventually 00:07:54.699 --> 00:07:57.600 bump into the final destination. That's the idea. 00:07:57.819 --> 00:07:59.600 Hold on. I have to push back on that. That sounds 00:07:59.600 --> 00:08:02.560 incredibly inefficient. If every single device 00:08:02.560 --> 00:08:05.079 is constantly duplicating and transmitting every 00:08:05.079 --> 00:08:07.639 piece of data it encounters, wouldn't they just 00:08:07.639 --> 00:08:09.939 instantly run out of storage? They absolutely 00:08:09.939 --> 00:08:12.160 would. Or worse, wouldn't their batteries die 00:08:12.160 --> 00:08:14.620 in like an hour from constantly blasting radio 00:08:14.620 --> 00:08:17.939 signals? You've hit on the exact flaw of epidemic 00:08:17.939 --> 00:08:21.720 routing. It is a brute force method. It works 00:08:21.720 --> 00:08:24.639 beautifully if you have plugged in high -capacity 00:08:24.639 --> 00:08:28.000 machines. But not for tiny devices. Right. You 00:08:28.000 --> 00:08:29.779 are absolutely right. If you are dealing with 00:08:29.779 --> 00:08:32.759 constrained resources like tiny solar -powered 00:08:32.759 --> 00:08:35.899 environmental sensors in a rainforest epidemic 00:08:35.899 --> 00:08:38.600 routing, we'll kill the network in an afternoon. 00:08:38.799 --> 00:08:41.480 So what do they do instead? In those cases, you 00:08:41.480 --> 00:08:43.940 cannot afford to flood the system. you have to 00:08:43.940 --> 00:08:46.460 use a much more discriminant, intelligent algorithm. 00:08:46.679 --> 00:08:48.899 Making smarter choices about who gets the data. 00:08:49.179 --> 00:08:51.659 Exactly. The nodes evaluate their trajectory, 00:08:51.960 --> 00:08:54.080 their battery life, and their historical encounters 00:08:54.080 --> 00:08:56.659 to choose exactly when and to whom they forward 00:08:56.659 --> 00:08:58.960 the data. They only pass the baton if they are 00:08:58.960 --> 00:09:01.139 mathematically confident the next runner is a 00:09:01.139 --> 00:09:03.259 better candidate. So to coordinate all of these 00:09:03.259 --> 00:09:06.019 complex relay handoffs across totally different 00:09:06.019 --> 00:09:08.779 types of networks, they needed a universal language. 00:09:08.840 --> 00:09:11.620 And that brings us to the bundle protocol. Yes, 00:09:11.639 --> 00:09:14.399 the core of DTN. The foundational rules were 00:09:14.399 --> 00:09:17.899 originally defined in documents called RFC 4838 00:09:17.899 --> 00:09:21.059 and 5050 back in 2007, which created an overlay 00:09:21.059 --> 00:09:24.100 network. But what does a bundle actually look 00:09:24.100 --> 00:09:26.379 like? Because standard Internet data is chopped 00:09:26.379 --> 00:09:29.240 up into thousands of tiny, fragile packets, right? 00:09:29.399 --> 00:09:31.600 And that fragility is exactly what they had to 00:09:31.600 --> 00:09:34.440 fix. On the normal Internet, if one tiny packet 00:09:34.440 --> 00:09:37.419 out of a thousand drops, the receiver just pings 00:09:37.419 --> 00:09:40.320 the sender and says, hey, resend packet 402. 00:09:40.409 --> 00:09:43.110 And that happens in milliseconds. Exactly. But 00:09:43.110 --> 00:09:46.250 in a delay tolerant network, a round trip request 00:09:46.250 --> 00:09:49.070 for a dropped packet could take 12 hours. The 00:09:49.070 --> 00:09:50.769 connection might be totally gone by then. So 00:09:50.769 --> 00:09:52.690 asking for a resend is basically impossible. 00:09:52.830 --> 00:09:55.370 Right. So the bundle protocol groups data into 00:09:55.370 --> 00:09:58.710 a large, contiguous block. This bundle contains 00:09:58.710 --> 00:10:01.720 so much semantic information. the destination, 00:10:02.080 --> 00:10:03.860 the security credentials, the lifespan of the 00:10:03.860 --> 00:10:06.080 data, that the receiving application can process 00:10:06.080 --> 00:10:08.480 it entirely on its own. Wait, so instead of sending 00:10:08.480 --> 00:10:10.700 a letter one paragraph at a time and hoping the 00:10:10.700 --> 00:10:13.220 postman doesn't drop a page, a bundle is like 00:10:13.220 --> 00:10:15.120 sending an entirely self -contained survival 00:10:15.120 --> 00:10:17.840 kit. A perfectly organized independent survival 00:10:17.840 --> 00:10:20.240 kit. It has everything the receiver needs to 00:10:20.240 --> 00:10:22.320 make sense of the data without ever needing to 00:10:22.320 --> 00:10:24.899 ask the sender for clarification. Exactly. And 00:10:24.899 --> 00:10:27.259 because standard IP addresses, like the ones 00:10:27.259 --> 00:10:29.919 your home router uses, rely on a fixed physical 00:10:29.919 --> 00:10:33.220 location, DTN just discards them completely. 00:10:33.600 --> 00:10:35.799 So how do they know where to go? These bundles 00:10:35.799 --> 00:10:39.299 are routed using Endpoint Identifiers, or EIDs. 00:10:39.799 --> 00:10:41.799 It's a naming architecture that identifies the 00:10:41.799 --> 00:10:44.240 application or the service itself, no matter 00:10:44.240 --> 00:10:46.279 where it physically moves. Oh, that's smart! 00:10:46.720 --> 00:10:48.559 And what's brilliantly clever about this survival 00:10:48.559 --> 00:10:51.750 kit is how it prioritizes itself. The applications 00:10:51.750 --> 00:10:54.490 generating the data dictate the urgency using 00:10:54.490 --> 00:10:56.889 specific service classes. Like what? The main 00:10:56.889 --> 00:10:59.909 ones are bulk, normal, or expedited. That makes 00:10:59.909 --> 00:11:02.850 total sense. If I'm a rover on Mars and I'm sending 00:11:02.850 --> 00:11:06.350 my routine daily soil analysis log, I can mark 00:11:06.350 --> 00:11:09.070 that bundle as bulk. The relay satellites can 00:11:09.070 --> 00:11:11.129 let it sit in storage for a week if they need 00:11:11.129 --> 00:11:13.470 to. Yep, no rush. But if I'm sending an alert 00:11:13.470 --> 00:11:15.649 that my primary solar panels are failing and 00:11:15.649 --> 00:11:18.889 I'm losing power, that bundle gets stamped expedited. 00:11:19.049 --> 00:11:21.690 And the network immediately knows to push that 00:11:21.690 --> 00:11:24.110 expedited bundle to the front of the line, ensuring 00:11:24.110 --> 00:11:27.049 critical data survives when resources are incredibly 00:11:27.049 --> 00:11:30.169 sparse. That's a lifesaver. Literally. And I 00:11:30.169 --> 00:11:33.009 should note, this isn't some forgotten 2007 experiment. 00:11:33.529 --> 00:11:35.850 The Internet Engineering Task Force, the group 00:11:35.850 --> 00:11:38.009 that maintains the backbone of the internet, 00:11:38.450 --> 00:11:40.350 is constantly evolving this. Oh, they're still 00:11:40.350 --> 00:11:43.340 updating it. Oh, heavily. They recently transitioned 00:11:43.340 --> 00:11:45.639 the core specifications into Bundle Protocol 00:11:45.639 --> 00:11:48.659 version 7. They published major updates in 2022, 00:11:49.539 --> 00:11:52.500 and incredibly recently, just in January 2025, 00:11:53.059 --> 00:11:56.139 they published a new specification. Wow, 2025! 00:11:56.720 --> 00:12:00.799 Yeah, RFC 9713 to refine how nodes discover each 00:12:00.799 --> 00:12:03.500 other. It is a very active, living architecture. 00:12:03.779 --> 00:12:05.759 Okay, but as I'm picturing these self -contained 00:12:05.759 --> 00:12:07.919 survival kits floating around out there, hopping 00:12:07.919 --> 00:12:10.559 from drone to satellite to rover, I keep hitting 00:12:10.559 --> 00:12:13.320 a massive wall. when it comes to security. Yes. 00:12:13.939 --> 00:12:16.259 Security is tough. If I'm a relay node holding 00:12:16.259 --> 00:12:18.759 on to a bundle for three days, and I have absolutely 00:12:18.759 --> 00:12:20.600 no way to communicate back to the original sender 00:12:20.600 --> 00:12:22.879 to verify passwords or credentials, what stops 00:12:22.879 --> 00:12:24.820 a malicious actor from just infiltrating the 00:12:24.820 --> 00:12:27.039 network and ruining everything? It is arguably 00:12:27.039 --> 00:12:29.399 one of the most difficult, complex challenges 00:12:29.399 --> 00:12:32.679 in all of DTN. If you think about standard internet 00:12:32.679 --> 00:12:36.259 security, it's completely reliant on continuous 00:12:36.259 --> 00:12:38.419 bi -directional communication. Right, like when 00:12:38.419 --> 00:12:40.919 you log into a website. Exactly. When you log 00:12:40.919 --> 00:12:43.259 into your bank, your browser and the bank's server 00:12:43.120 --> 00:12:45.860 talked back and forth multiple times in milliseconds 00:12:45.860 --> 00:12:49.139 to agree on a secret cryptographic code. But 00:12:49.139 --> 00:12:52.299 in a fragmented network, that rapid -fire handshake 00:12:52.299 --> 00:12:54.919 is physically impossible. Right. And without 00:12:54.919 --> 00:12:57.919 that real -time digital ID check, the network 00:12:57.919 --> 00:13:00.500 is incredibly vulnerable to bad actors acting 00:13:00.500 --> 00:13:03.059 as middlemen. If I'm handing my precious data 00:13:03.059 --> 00:13:05.659 to a random node I just met, it opens the door 00:13:05.659 --> 00:13:08.840 for some nasty attacks. Very nasty. I know from 00:13:08.840 --> 00:13:11.279 the source there are two major ones. The flutter. 00:13:11.549 --> 00:13:13.710 and the black hole. A flutter makes sense. It's 00:13:13.710 --> 00:13:16.210 a robe node that just generates thousands of 00:13:16.210 --> 00:13:18.529 fake bundles to choke the network's storage capacity. 00:13:18.669 --> 00:13:21.049 It just overwhelms the system. Right. But the 00:13:21.049 --> 00:13:23.529 black hole attack, that's much more insidious, 00:13:23.610 --> 00:13:26.649 isn't it? It's devastating. In a black hole attack, 00:13:27.009 --> 00:13:29.889 a malicious node joins the network and acts like 00:13:29.889 --> 00:13:32.750 a perfect citizen. It cheerfully accepts bundles 00:13:32.750 --> 00:13:35.350 of life -saving data from other nodes. But it 00:13:35.350 --> 00:13:38.289 doesn't pass them on. Exactly. Instead of storing 00:13:38.289 --> 00:13:40.629 and forwarding them, it quietly deletes them. 00:13:40.809 --> 00:13:43.629 It acts as a data sync. And because the original 00:13:43.629 --> 00:13:45.509 sender doesn't expect a delivery receipt for 00:13:45.509 --> 00:13:48.529 days or weeks, the black hole can silently destroy 00:13:48.529 --> 00:13:51.090 massive amounts of information before anyone 00:13:51.090 --> 00:13:53.710 realizes there's a problem. That is terrifying. 00:13:53.870 --> 00:13:56.049 How do you fight that? I know researchers looked 00:13:56.049 --> 00:13:58.309 into adapting public key infrastructure, which 00:13:58.309 --> 00:14:00.669 is basically that digital ID check we use for 00:14:00.669 --> 00:14:02.909 banking, but making it work without a central 00:14:02.909 --> 00:14:05.649 server is tough. It is incredibly difficult to 00:14:05.649 --> 00:14:08.070 decentralize that trust. I was looking at some 00:14:08.070 --> 00:14:10.539 of the unique solutions the DTN community came 00:14:10.539 --> 00:14:13.259 up with, like identity -based encryption. But 00:14:13.259 --> 00:14:16.000 there's another method that relies on tamper 00:14:16.000 --> 00:14:18.620 -evident tables combined with a gossiping protocol. 00:14:18.799 --> 00:14:21.500 Yes, gossiping. Wait, gossiping? That sounds 00:14:21.500 --> 00:14:23.879 like a middle school rumor mill, not a high -tech 00:14:23.879 --> 00:14:27.240 cryptography solution. How on earth does gossiping 00:14:27.240 --> 00:14:29.879 protect a network from a black hole attack? Well, 00:14:30.000 --> 00:14:32.639 this raises an important question. How do you 00:14:32.639 --> 00:14:35.620 build trust when no one can see the whole picture? 00:14:35.840 --> 00:14:38.460 And there is no central police force to monitor 00:14:38.460 --> 00:14:41.000 behavior. You talk to your neighbors. Exactly. 00:14:42.080 --> 00:14:44.340 In a fragmented network, the nodes have to rely 00:14:44.340 --> 00:14:47.259 on sharing localized, tamper -proof rumors or 00:14:47.259 --> 00:14:50.019 reports about their interactions. When two nodes 00:14:50.019 --> 00:14:52.960 briefly cross paths, they don't just exchange 00:14:52.960 --> 00:14:55.200 bundles of data. What else do they exchange? 00:14:55.259 --> 00:14:57.679 They exchange cryptographic logs of their recent 00:14:57.679 --> 00:15:01.139 activities. That is the gossip. Ah. Let me see 00:15:01.139 --> 00:15:03.240 if I get this. It's literally like a digital 00:15:03.240 --> 00:15:06.129 high school. Node A crosses paths with node B 00:15:06.129 --> 00:15:08.909 and has a node that says, hey, I gave three critical 00:15:08.909 --> 00:15:11.330 bundles to node C yesterday. And according to 00:15:11.330 --> 00:15:13.450 the network gossip I've collected, node C never 00:15:13.450 --> 00:15:15.409 passed them on to anyone. You've got it perfectly. 00:15:15.730 --> 00:15:17.809 And because these gossip logs are cryptographically 00:15:17.809 --> 00:15:20.870 signed, node C can't alter them to cover its 00:15:20.870 --> 00:15:23.870 tracks. They're verifiable rumors. Exactly. As 00:15:23.870 --> 00:15:26.190 nodes move around and encounter each other, these 00:15:26.190 --> 00:15:29.269 rumors spread exponentially. Eventually, the 00:15:29.269 --> 00:15:31.519 collective mathematics of the network across 00:15:31.519 --> 00:15:34.679 the threshold. And everyone realizes node C is 00:15:34.679 --> 00:15:38.019 the bad guy. Right. Enough nodes have swapped 00:15:38.019 --> 00:15:41.200 gossip about node C dropping data that the network 00:15:41.200 --> 00:15:44.259 collectively agrees node C is a black hole. From 00:15:44.259 --> 00:15:47.620 that moment on, every node simply refuses to 00:15:47.620 --> 00:15:50.129 hand data to node C. They just shun it. Yep, 00:15:50.309 --> 00:15:52.450 they route around it entirely. It is a reputation 00:15:52.450 --> 00:15:55.110 system built entirely on decentralized mathematical 00:15:55.110 --> 00:15:58.110 rumors. That is brilliant. It weaponizes the 00:15:58.110 --> 00:16:01.370 very nature of the relay race to spread the security 00:16:01.370 --> 00:16:04.990 updates. Okay, so we've built the network, we've 00:16:04.990 --> 00:16:07.190 bundled the data into survival kits, and we've 00:16:07.190 --> 00:16:09.230 secured it with digital gossip. We have a working 00:16:09.230 --> 00:16:11.330 DCN. Here's where it gets really interesting. 00:16:11.659 --> 00:16:13.980 Let's talk about where this is actually operating 00:16:13.980 --> 00:16:16.620 around us and above us right now, because this 00:16:16.620 --> 00:16:19.100 is not just a theoretical lab experiment anymore. 00:16:19.220 --> 00:16:21.740 Not at all. There are multiple highly robust 00:16:21.740 --> 00:16:24.019 implementations of the bundle protocol operating 00:16:24.019 --> 00:16:26.299 right now. Let's look at space first. OK, let's 00:16:26.299 --> 00:16:28.919 go to space. NASA maintains the Interplanetary 00:16:28.919 --> 00:16:32.750 Overlay Network, or IONN. It is a software implementation 00:16:32.750 --> 00:16:35.549 written in the C programming language, and it 00:16:35.549 --> 00:16:38.710 is specifically engineered to survive the incredibly 00:16:38.710 --> 00:16:41.350 strict safety rules of spaceflight computers. 00:16:41.610 --> 00:16:43.649 Safety rules like what? Well, for example, it 00:16:43.649 --> 00:16:46.720 uses zero dynamic memory allocation. which is 00:16:46.720 --> 00:16:49.440 a programming technique to guarantee the software 00:16:49.440 --> 00:16:52.259 never causes a memory leak that could crash the 00:16:52.259 --> 00:16:54.559 computer. Because you definitely do not want 00:16:54.559 --> 00:16:57.039 your flight computer freezing and asking for 00:16:57.039 --> 00:16:59.200 a reboot when it's halfway to Jupiter. Exactly. 00:16:59.259 --> 00:17:01.039 You can't just send an IT guy up there to turn 00:17:01.039 --> 00:17:03.700 it off and on again. Then you have another implementation 00:17:03.700 --> 00:17:07.220 called DTNME, which is currently operating right 00:17:07.220 --> 00:17:09.299 now on the International Space Station. Oh, they 00:17:09.299 --> 00:17:11.819 use it on the ISS. Yeah, supporting both older 00:17:11.819 --> 00:17:15.039 and newer versions of the bundle protocol. And 00:17:15.039 --> 00:17:17.480 NASA isn't stopping there. They've developed 00:17:17.480 --> 00:17:21.039 a newer library called BPLibC, which is slated 00:17:21.039 --> 00:17:23.839 to fly on the upcoming PACE mission. The PACE 00:17:23.839 --> 00:17:26.140 mission. It's an incredibly advanced satellite 00:17:26.140 --> 00:17:28.799 designed to study Earth's oceans and atmosphere. 00:17:29.079 --> 00:17:31.539 And what's wild is how long they've been successfully 00:17:31.539 --> 00:17:35.339 testing this in orbit. Back in 2008, a project 00:17:35.339 --> 00:17:38.200 called Saratoga successfully tested the bundle 00:17:38.200 --> 00:17:41.259 protocol on a UK Earth observation satellite. 00:17:41.539 --> 00:17:44.390 Yeah, that was a huge milestone. That same year, 00:17:44.589 --> 00:17:47.730 NASA's Jet Propulsion Lab ran the Dynet experiment, 00:17:48.029 --> 00:17:50.569 sending bundles to the Deep Impact spacecraft 00:17:50.569 --> 00:17:53.970 over 20 million miles away. It's just staggering 00:17:53.970 --> 00:17:56.470 distance. But the milestone from the source that 00:17:56.470 --> 00:18:00.210 absolutely blows my mind is from 2015. NASA and 00:18:00.210 --> 00:18:03.210 the European Space Agency used the experimental 00:18:03.210 --> 00:18:06.109 interplanetary Internet to allow an astronaut 00:18:06.109 --> 00:18:09.089 on the ISS to remote control a rover driving 00:18:09.089 --> 00:18:11.190 around down on Earth. That is wild. They were 00:18:11.190 --> 00:18:13.880 literally teleoperating a robot. from space using 00:18:13.880 --> 00:18:16.220 delay tolerant bundles to ensure the commands 00:18:16.220 --> 00:18:18.940 didn't get lost in transit. It's a stunning technical 00:18:18.940 --> 00:18:21.279 achievement. Controlling robots from orbit captures 00:18:21.279 --> 00:18:23.660 the imagination, but we also have to look at 00:18:23.660 --> 00:18:26.160 how this impacts us terrestrially. Right, back 00:18:26.160 --> 00:18:28.359 down on Earth. What stands out to you when we 00:18:28.359 --> 00:18:31.000 compare those multi -million dollar deep space 00:18:31.000 --> 00:18:34.119 missions with the Earth bound applications of 00:18:34.119 --> 00:18:37.059 DTN. Honestly, it's the sheer contrast in scale 00:18:37.059 --> 00:18:39.220 and environment. You go from the sterile high 00:18:39.220 --> 00:18:41.480 tech environment of the International Space Station 00:18:41.480 --> 00:18:45.359 to, well, the Zebronet project. Yes. Zebronet 00:18:45.359 --> 00:18:47.839 is one of the most fascinating examples of terrestrial 00:18:47.839 --> 00:18:51.380 DTN. It uses energy efficient, store and forward 00:18:51.380 --> 00:18:53.799 computing to track the movements and behaviors 00:18:53.799 --> 00:18:56.930 of wildlife. Because wild animals in Africa don't 00:18:56.930 --> 00:18:59.589 exactly stick to areas with reliable 5G coverage. 00:18:59.869 --> 00:19:02.789 Right, exactly. So researchers outfit the animals 00:19:02.789 --> 00:19:05.509 with specialized sensor collars. Let me guess. 00:19:05.869 --> 00:19:08.390 Epidemic routing in the wild. Quite literally. 00:19:09.029 --> 00:19:11.250 Let's track a single zebra out in the Kenyan 00:19:11.250 --> 00:19:14.170 savanna. Zebra 1 has a collar recording its heart 00:19:14.170 --> 00:19:16.589 rate, GPS location, and grazing habits. Okay, 00:19:16.829 --> 00:19:19.609 tracking Zebra 1. Zebra 1 wanders over to a watering 00:19:19.609 --> 00:19:23.089 hole and bumps into Zebra 2. Their collars detect 00:19:23.089 --> 00:19:25.430 each other and instantly they exchange their 00:19:25.430 --> 00:19:28.170 data bundles. So now Zebra 2 has both data sets. 00:19:28.309 --> 00:19:30.829 Now Zebra 2 is carrying both its own data and 00:19:30.829 --> 00:19:33.890 Zebra 1's data. They separate. Days go by. The 00:19:33.890 --> 00:19:36.230 bundles are passed from Zebra to Zebra across 00:19:36.230 --> 00:19:38.730 the entire herd. That is so cool. Eventually 00:19:38.730 --> 00:19:41.009 any single Zebra wanders close enough to a research 00:19:41.009 --> 00:19:43.630 base station or vehicle driving by. The moment 00:19:43.630 --> 00:19:45.990 that connection is made, the collar offloads 00:19:45.990 --> 00:19:48.640 the entire herd's data at once. It's just incredible. 00:19:48.680 --> 00:19:51.099 They turned the herd itself into a localized 00:19:51.099 --> 00:19:53.480 Internet. They really did. And it goes beyond 00:19:53.480 --> 00:19:57.440 wildlife. You have DARPA's W -O -NAN project, 00:19:57.440 --> 00:20:00.059 using it for tactical military communications. 00:20:00.539 --> 00:20:03.200 You have vehicular networks where cars traveling 00:20:03.200 --> 00:20:06.359 in opposite directions on a highway rapidly pass 00:20:06.359 --> 00:20:08.519 data bundles to each other to warn about traffic 00:20:08.519 --> 00:20:10.980 accidents miles ahead. It's highly adaptable. 00:20:11.200 --> 00:20:13.880 And critically, you have university initiatives 00:20:13.880 --> 00:20:16.859 targeting developing remote regions, bringing 00:20:17.039 --> 00:20:19.740 synchronous internet access to isolated villages 00:20:19.740 --> 00:20:22.920 that completely lack traditional telecom infrastructure. 00:20:23.200 --> 00:20:25.619 Oh, the motorcycle couriers. Yes, a motorcycle 00:20:25.619 --> 00:20:28.200 courier drives through a village with a Wi -Fi 00:20:28.200 --> 00:20:31.039 hard drive, automatically absorbs all the outgoing 00:20:31.039 --> 00:20:33.319 emails and data requests from the local clinic, 00:20:33.720 --> 00:20:36.079 and physically drives them to a city with an 00:20:36.079 --> 00:20:38.740 internet uplink. It's such a brilliant practical 00:20:38.740 --> 00:20:41.220 application of the protocol. So what does this 00:20:41.220 --> 00:20:43.890 all mean for us? We started out looking at a 00:20:43.890 --> 00:20:45.809 technology designed to talk to probes at the 00:20:45.809 --> 00:20:47.950 edge of the solar system, and we ended up with 00:20:47.950 --> 00:20:50.750 a tool that can track endangered species and 00:20:50.750 --> 00:20:53.089 provide a lifeline to the most isolated places 00:20:53.089 --> 00:20:55.289 on Earth. It's an incredible journey. It really 00:20:55.289 --> 00:20:58.730 proves that DTN isn't just a niche tool for astronauts. 00:20:59.250 --> 00:21:02.069 It is the ultimate backup plan. It takes the 00:21:02.069 --> 00:21:04.670 greatest liability of a broken network, the sheer 00:21:04.670 --> 00:21:07.349 disconnection, and turns it into a resilient 00:21:07.349 --> 00:21:10.890 web. By relying on patient, self -contained bundles, 00:21:11.190 --> 00:21:14.230 the data actually survives. And as we wrap up 00:21:14.230 --> 00:21:15.890 this deep dive, I want to leave you with a thought 00:21:15.890 --> 00:21:17.890 that builds on everything we've explored today. 00:21:17.990 --> 00:21:20.809 What's that? Well, if humanity eventually fulfills 00:21:20.809 --> 00:21:23.130 the sci -fi dream and becomes a multi -planetary 00:21:23.130 --> 00:21:25.930 species, establishing permanent colonies on Mars 00:21:25.930 --> 00:21:29.200 or mining outposts in the asteroid belt, DTN 00:21:29.200 --> 00:21:31.559 won't just be a backup plan for scientists. Right. 00:21:31.619 --> 00:21:33.779 It'll be everyday life. It'll have to become 00:21:33.779 --> 00:21:37.460 the primary, absolute foundation of a true, inter 00:21:37.460 --> 00:21:39.500 -solar internet. Imagine what human culture, 00:21:40.019 --> 00:21:41.799 streaming media, and global finance will look 00:21:41.799 --> 00:21:43.619 like when every single piece of data has to be 00:21:43.619 --> 00:21:45.740 bundled and tolerate light minutes or even light 00:21:45.740 --> 00:21:48.400 hours of delay. It's hard to even picture. How 00:21:48.400 --> 00:21:50.579 will our very concept of what the internet is 00:21:50.579 --> 00:21:53.440 have to evolve when instantaneous connection 00:21:53.440 --> 00:21:55.599 is literally forbidden by the laws of physics? 00:21:55.960 --> 00:21:58.250 That is a staggering thought. Are we going to 00:21:58.250 --> 00:22:01.269 be waking up to receive massive daily bundles 00:22:01.269 --> 00:22:03.730 of the internet, waiting for the morning data 00:22:03.730 --> 00:22:06.730 to drop from Earth just to see the news or catch 00:22:06.730 --> 00:22:09.329 up on social media? We might have to. It completely 00:22:09.329 --> 00:22:11.470 changes what it means to be connected as a species. 00:22:11.670 --> 00:22:14.329 And it all starts with learning to tolerate the 00:22:14.329 --> 00:22:16.690 delay. Thank you for joining us on this deep 00:22:16.690 --> 00:22:18.470 dive. The next time you're stuck waiting for 00:22:18.470 --> 00:22:20.910 a text to go through in a dead zone, just remember 00:22:20.910 --> 00:22:23.009 the relay runners holding those bundles in the 00:22:23.009 --> 00:22:25.130 dark, waiting patiently to pass them on.