1 00:00:00,000 --> 00:00:04,600 Imagine your company's email server just goes down right now, 2 00:00:04,600 --> 00:00:06,800 not just for a minute, but permanently. 3 00:00:06,800 --> 00:00:08,400 Oh, that's a nightmare scenario. 4 00:00:08,400 --> 00:00:08,920 Right. 5 00:00:08,920 --> 00:00:13,120 Every single client contract, every internal HR dispute, 6 00:00:13,120 --> 00:00:15,760 compliance records, financial audit trails, 7 00:00:15,760 --> 00:00:18,440 just gone in a matter of seconds. 8 00:00:18,440 --> 00:00:21,920 For most companies relying on legacy infrastructure, 9 00:00:21,920 --> 00:00:24,400 that is the ultimate single point of failure. 10 00:00:24,400 --> 00:00:27,320 It's exactly what keeps IT directors awake at night. 11 00:00:27,320 --> 00:00:28,040 It really is. 12 00:00:28,040 --> 00:00:29,720 I mean, email is foundational, right? 13 00:00:29,720 --> 00:00:33,080 But historically, the infrastructure behind it is, 14 00:00:33,080 --> 00:00:34,840 well, it's incredibly fragile. 15 00:00:34,840 --> 00:00:36,880 You set it up, you cross your fingers, 16 00:00:36,880 --> 00:00:38,760 and you basically try not to touch anything 17 00:00:38,760 --> 00:00:40,600 so the whole delicate system doesn't just 18 00:00:40,600 --> 00:00:41,920 collapse under its own weight. 19 00:00:41,920 --> 00:00:42,440 Exactly. 20 00:00:42,440 --> 00:00:44,880 And because it's so terrifying to manage, 21 00:00:44,880 --> 00:00:46,560 organizations usually feel trapped. 22 00:00:46,560 --> 00:00:48,400 They look at their infrastructure and think, 23 00:00:48,400 --> 00:00:50,880 their only safe option is to pay an absolute fortune 24 00:00:50,880 --> 00:00:52,840 for expensive proprietary tools. 25 00:00:52,840 --> 00:00:55,800 Oh, yeah, the massive vendor ecosystems. 26 00:00:55,800 --> 00:00:58,720 Like Microsoft Exchange or Google Workspace. 27 00:00:58,720 --> 00:00:59,680 But here's the thing. 28 00:00:59,680 --> 00:01:01,760 Those ecosystems can actually be replaced 29 00:01:01,760 --> 00:01:05,000 by incredibly powerful open source solutions. 30 00:01:05,000 --> 00:01:07,520 And we're talking about a truly staggering difference 31 00:01:07,520 --> 00:01:10,160 in cost, which perfectly highlights 32 00:01:10,160 --> 00:01:13,040 the focus of today's deep dive, supported by Safe Server. 33 00:01:13,040 --> 00:01:14,480 And that cost difference is huge. 34 00:01:14,480 --> 00:01:16,800 But I mean, it goes way beyond just the IT budget. 35 00:01:16,800 --> 00:01:18,880 When you're dealing with corporate or institutional 36 00:01:18,880 --> 00:01:21,960 email, you're navigating a total minefield 37 00:01:21,960 --> 00:01:25,560 of legal, regulatory, and compliance requirements. 38 00:01:25,560 --> 00:01:26,480 Oh, absolutely. 39 00:01:26,480 --> 00:01:29,240 Strict email retention laws, GDPR, 40 00:01:29,240 --> 00:01:32,440 securing financial records, and maintaining 41 00:01:32,440 --> 00:01:33,640 those critical audit trails. 42 00:01:33,640 --> 00:01:36,360 Right, which means data sovereignty is paramount. 43 00:01:36,360 --> 00:01:37,840 You can't just throw your company's 44 00:01:37,840 --> 00:01:40,320 most sensitive communications into some massive tech 45 00:01:40,320 --> 00:01:43,200 giant's mystery cloud and just hope for the best. 46 00:01:43,200 --> 00:01:45,360 You need to know exactly where your data lives, 47 00:01:45,360 --> 00:01:48,280 who holds the keys, and who actually has access to it. 48 00:01:48,280 --> 00:01:50,720 Which is exactly where Safe Server comes in. 49 00:01:50,720 --> 00:01:53,120 They help organizations find and implement 50 00:01:53,120 --> 00:01:57,760 the right open-source solution for their specific needs. 51 00:01:57,760 --> 00:02:01,480 And they do it all from the initial consulting phase, 52 00:02:01,480 --> 00:02:03,240 to figure out what you actually need, 53 00:02:03,240 --> 00:02:05,200 all the way through to operating the software 54 00:02:05,200 --> 00:02:06,920 on highly secure German servers. 55 00:02:06,920 --> 00:02:09,760 Yeah, it's a complete pipeline for taking back control. 56 00:02:09,760 --> 00:02:10,500 Exactly. 57 00:02:10,500 --> 00:02:12,000 So if you're an organization looking 58 00:02:12,000 --> 00:02:14,080 to take back control of your infrastructure, 59 00:02:14,080 --> 00:02:16,840 you can find more information at safeserver.de. 60 00:02:16,840 --> 00:02:19,160 It's the perfect context for what we're exploring today, 61 00:02:19,160 --> 00:02:22,200 too, because we are looking at a system that completely 62 00:02:22,200 --> 00:02:25,080 shatters the traditional way we think about hosting email. 63 00:02:25,080 --> 00:02:26,520 We really are. 64 00:02:26,520 --> 00:02:29,440 So welcome, everyone, to today's Deep Dive. 65 00:02:29,440 --> 00:02:32,000 We have a genuinely fascinating stack of sources 66 00:02:32,000 --> 00:02:35,200 in front of us today, the official GitHub repository, 67 00:02:35,200 --> 00:02:38,800 which is currently boasting over 2.1 thousand stars, 68 00:02:38,800 --> 00:02:40,720 alongside the official documentation 69 00:02:40,720 --> 00:02:42,920 for an open source project called Wild Duck. 70 00:02:42,920 --> 00:02:45,240 It's a fantastic project to dig into. 71 00:02:45,240 --> 00:02:47,800 Yeah, and our mission today is to give you, 72 00:02:47,800 --> 00:02:50,760 even if you're a total beginner to server architecture, 73 00:02:50,760 --> 00:02:53,360 a clear, easy entry point into what 74 00:02:53,360 --> 00:02:56,000 an opinionated email server is, 75 00:02:56,000 --> 00:02:58,840 and how Wild Duck fundamentally reimagines 76 00:02:58,840 --> 00:03:00,680 the back end of your inbox. 77 00:03:00,680 --> 00:03:02,400 So, okay, let's unpack this, 78 00:03:02,400 --> 00:03:05,840 starting with that specific word, opinionated. 79 00:03:05,840 --> 00:03:07,960 That's a great place to start because it dictates, 80 00:03:07,960 --> 00:03:10,160 well, everything about how this software works. 81 00:03:10,160 --> 00:03:11,760 In software development, you know, 82 00:03:11,760 --> 00:03:14,440 when a tool is described as opinionated, 83 00:03:14,440 --> 00:03:16,840 it means the creators have made very specific, 84 00:03:16,840 --> 00:03:19,040 rigid design choices for you. 85 00:03:19,040 --> 00:03:20,680 Like, they're not giving you a blank canvas. 86 00:03:20,680 --> 00:03:22,000 Right, exactly. 87 00:03:22,000 --> 00:03:23,940 Instead of giving a system administrator 88 00:03:23,940 --> 00:03:26,200 a million different ways to configure something, 89 00:03:26,200 --> 00:03:27,280 the developers are basically saying, 90 00:03:27,280 --> 00:03:29,440 look, this is the best way to do it. 91 00:03:29,440 --> 00:03:31,280 We built it to work exactly this way. 92 00:03:31,280 --> 00:03:34,400 And if you want to use our tool, you play by our rules. 93 00:03:34,400 --> 00:03:35,960 And Wild Duck's specific rule book 94 00:03:35,960 --> 00:03:38,040 is incredibly straightforward. 95 00:03:38,040 --> 00:03:39,520 According to the documentation, 96 00:03:39,520 --> 00:03:42,600 it explicitly tries to follow Gmail's product design. 97 00:03:42,600 --> 00:03:44,840 It says right there in the repository. 98 00:03:44,840 --> 00:03:46,000 If there's a decision to be made 99 00:03:46,000 --> 00:03:47,800 about how a feature should work, 100 00:03:47,800 --> 00:03:50,480 the answer is usually to just do whatever Gmail has done. 101 00:03:50,480 --> 00:03:52,240 Which is, I mean, it's a bold strategy, 102 00:03:52,240 --> 00:03:54,760 but mathematically, it's a brilliant one. 103 00:03:54,760 --> 00:03:56,700 Gmail completely revolutionized 104 00:03:56,700 --> 00:03:58,920 how we handle massive scale in email. 105 00:03:58,920 --> 00:04:00,480 And Wild Duck, which, by the way, 106 00:04:00,480 --> 00:04:02,360 was created by Zone Media OU 107 00:04:02,360 --> 00:04:04,000 as part of the Zone Mail Suite, 108 00:04:04,000 --> 00:04:06,040 is built with that exact same philosophy. 109 00:04:06,040 --> 00:04:08,160 It's designed to be a highly scalable, 110 00:04:08,160 --> 00:04:11,760 no-SPOF mail server for IMAP and POP3. 111 00:04:11,760 --> 00:04:13,280 Okay, I'm gonna pause you right there 112 00:04:13,280 --> 00:04:14,920 for the beginners listening. 113 00:04:14,920 --> 00:04:17,600 What exactly is a no-SPOF architecture? 114 00:04:17,600 --> 00:04:19,280 Ah, right, good catch. 115 00:04:19,280 --> 00:04:22,120 So it stands for no single point of failure. 116 00:04:22,120 --> 00:04:25,400 In traditional IT, if your one primary mail server 117 00:04:25,400 --> 00:04:27,560 goes down like maybe the hard drive fries 118 00:04:27,560 --> 00:04:29,020 or the motherboard fails, 119 00:04:29,020 --> 00:04:31,440 your whole company's email just stops working. 120 00:04:31,440 --> 00:04:32,280 Total blackout. 121 00:04:32,280 --> 00:04:35,280 Exactly, and no-SPOF architecture means redundancy 122 00:04:35,280 --> 00:04:38,040 is built into the very core of the design. 123 00:04:38,040 --> 00:04:39,480 There is no single machine 124 00:04:39,480 --> 00:04:41,080 that can bring the whole thing down. 125 00:04:41,080 --> 00:04:42,600 If a piece of the system crashes, 126 00:04:42,600 --> 00:04:44,840 another identical piece instantly takes over 127 00:04:44,840 --> 00:04:46,920 and the end user who's just typing out an email 128 00:04:46,920 --> 00:04:48,540 never even notices the hiccup. 129 00:04:48,540 --> 00:04:52,020 Wow, okay, so who is this actually for? 130 00:04:52,020 --> 00:04:53,960 Because looking through the documentation, 131 00:04:53,960 --> 00:04:55,480 they have a pretty blunt disclaimer. 132 00:04:55,480 --> 00:04:57,720 It says if you're running a small setup 133 00:04:57,720 --> 00:05:00,240 where everything fits onto a single server, 134 00:05:00,240 --> 00:05:01,800 you really shouldn't use Wild Duck. 135 00:05:01,800 --> 00:05:03,420 Yeah, they don't sugarcoat it. 136 00:05:03,420 --> 00:05:04,260 They don't. 137 00:05:04,260 --> 00:05:07,320 They actually recommend you stick to the industry standard 138 00:05:07,320 --> 00:05:09,960 for small setups, which is a combination of software 139 00:05:09,960 --> 00:05:12,640 called Postfix and DoveCot. 140 00:05:12,640 --> 00:05:16,080 That's right, because Wild Duck is explicitly designed 141 00:05:16,080 --> 00:05:19,200 for massive large scale setups. 142 00:05:19,200 --> 00:05:22,000 We're talking about organizations with a thousand 143 00:05:22,000 --> 00:05:24,320 or more email accounts dealing with just 144 00:05:24,320 --> 00:05:26,600 gargantuan storage quotas. 145 00:05:26,600 --> 00:05:28,680 It's designed to scale horizontally. 146 00:05:28,680 --> 00:05:30,620 Meaning instead of buying one giant server, 147 00:05:30,620 --> 00:05:32,120 you just link up a bunch of small ones. 148 00:05:32,120 --> 00:05:34,080 Exactly, instead of buying one bigger, 149 00:05:34,080 --> 00:05:36,160 more expensive server, you just keep plugging in 150 00:05:36,160 --> 00:05:38,400 lots of cheaper, smaller servers side by side 151 00:05:38,400 --> 00:05:40,020 to handle the increased load. 152 00:05:40,020 --> 00:05:41,760 Okay, so the way I'm picturing this, 153 00:05:41,760 --> 00:05:43,580 and tell me if this analogy tracks, 154 00:05:43,580 --> 00:05:46,200 is that a traditional small email server setup 155 00:05:46,200 --> 00:05:48,160 like Postfix and DoveCut is like 156 00:05:48,160 --> 00:05:50,440 a local mom-and-pop post office. 157 00:05:50,440 --> 00:05:51,340 Okay, I like that. 158 00:05:51,340 --> 00:05:53,680 Right, it's incredibly reliable. 159 00:05:53,680 --> 00:05:55,880 The postmaster knows where every single letter is, 160 00:05:55,880 --> 00:05:57,760 and it's perfect for a small town. 161 00:05:57,760 --> 00:05:59,720 But Wild Duck is like a massive, 162 00:05:59,720 --> 00:06:02,440 fully automated international shipping hub. 163 00:06:02,440 --> 00:06:04,640 It is total overkill if you just want to send 164 00:06:04,640 --> 00:06:05,800 a postcard to your neighbor. 165 00:06:05,800 --> 00:06:06,640 Oh, absolutely. 166 00:06:06,640 --> 00:06:09,420 But if you're processing millions of packages a day, 167 00:06:09,420 --> 00:06:13,920 you absolutely need that relentless robotic automation. 168 00:06:13,920 --> 00:06:16,600 That is a highly accurate way to visualize it. 169 00:06:16,600 --> 00:06:18,680 I mean, the local post office works beautifully 170 00:06:18,680 --> 00:06:21,120 right up until you suddenly have 10,000 people 171 00:06:21,120 --> 00:06:24,120 trying to drop off packages at the exact same millisecond. 172 00:06:24,120 --> 00:06:26,360 When that happens, the walls of the post office 173 00:06:26,360 --> 00:06:27,840 quite literally burst. 174 00:06:27,840 --> 00:06:30,060 Right, and that leads me to my biggest question. 175 00:06:30,060 --> 00:06:32,020 I really want to push back on this a bit. 176 00:06:32,020 --> 00:06:33,620 We've sunk decades perfecting 177 00:06:33,620 --> 00:06:36,560 traditional file-based email servers. 178 00:06:36,560 --> 00:06:39,760 If it's meant to handle Gmail levels of scale, 179 00:06:39,760 --> 00:06:42,380 how does it physically store all those messages 180 00:06:42,380 --> 00:06:43,220 without crashing? 181 00:06:43,220 --> 00:06:45,160 It's the multi-million dollar question. 182 00:06:45,160 --> 00:06:47,800 Because moving an entire enterprise's email 183 00:06:47,800 --> 00:06:51,840 away from traditional storage seems incredibly risky. 184 00:06:51,840 --> 00:06:53,600 Why reinvent the wheel here? 185 00:06:53,600 --> 00:06:56,040 Because at a certain scale, the wheel breaks. 186 00:06:56,040 --> 00:06:57,560 What's fascinating here is that 187 00:06:57,560 --> 00:07:00,840 while that completely throws away the traditional rule book 188 00:07:00,840 --> 00:07:03,480 for how an email server stores data, 189 00:07:03,480 --> 00:07:05,600 it totally abandons the file system. 190 00:07:05,600 --> 00:07:07,040 Wait, no file system at all? 191 00:07:07,040 --> 00:07:07,880 None. 192 00:07:07,880 --> 00:07:08,880 So where are the emails actually going? 193 00:07:08,880 --> 00:07:10,960 They go directly into a database. 194 00:07:10,960 --> 00:07:12,140 Let's look at the mechanism 195 00:07:12,140 --> 00:07:15,820 of why traditional servers fail at scale, right? 196 00:07:15,820 --> 00:07:19,240 In a standard setup, every single email you receive 197 00:07:19,240 --> 00:07:23,400 is saved as a tiny individual file on a server's hard drive. 198 00:07:23,400 --> 00:07:25,280 If you have a company with a million emails, 199 00:07:25,280 --> 00:07:27,120 you have a million tiny files. 200 00:07:27,120 --> 00:07:28,680 Hard drives are not designed 201 00:07:28,680 --> 00:07:31,300 to read a million tiny files simultaneously. 202 00:07:31,300 --> 00:07:33,720 It takes a massive toll on the system's index 203 00:07:33,720 --> 00:07:36,160 to search through them, read them, manage them. 204 00:07:36,160 --> 00:07:38,600 The hard drive literally spends all its time 205 00:07:38,600 --> 00:07:41,300 spinning around looking for tiny fragments of data. 206 00:07:41,300 --> 00:07:42,960 Which I think is called disk threshing, right? 207 00:07:42,960 --> 00:07:45,480 Exactly, disk threshing. It kills performance. 208 00:07:45,480 --> 00:07:48,000 Instead, Wild Duck stores absolutely everything 209 00:07:48,000 --> 00:07:49,880 in a distributed database, 210 00:07:49,880 --> 00:07:53,680 specifically a sharded and replicated MongoDB cluster. 211 00:07:53,680 --> 00:07:57,120 Hold on, isn't migrating an entire enterprise's email 212 00:07:57,120 --> 00:08:01,160 over to a MongoDB database a massive paradigm shift? 213 00:08:01,160 --> 00:08:03,360 I mean, people usually use NoSQL databases 214 00:08:03,360 --> 00:08:04,920 for like fast web apps, 215 00:08:04,920 --> 00:08:07,600 not for critical corporate communications. 216 00:08:07,600 --> 00:08:09,520 It is a massive shift, yeah. 217 00:08:09,520 --> 00:08:12,440 But it solves the disk threshing problem perfectly. 218 00:08:12,440 --> 00:08:14,240 When we say the database is sharded, 219 00:08:14,240 --> 00:08:17,600 imagine you have a massive heavy encyclopedia. 220 00:08:17,600 --> 00:08:20,100 Instead of making one person carry the whole thing, 221 00:08:20,100 --> 00:08:22,120 sharding slices that encyclopedia 222 00:08:22,120 --> 00:08:23,760 into a hundred smaller chapters 223 00:08:23,760 --> 00:08:26,400 and hands them out to a hundred different people. 224 00:08:26,400 --> 00:08:29,200 Slicing the database into smaller manageable chunks 225 00:08:29,200 --> 00:08:31,720 across different servers means no single machine 226 00:08:31,720 --> 00:08:33,120 ever gets overwhelmed. 227 00:08:33,120 --> 00:08:33,960 Oh, I see. 228 00:08:33,960 --> 00:08:35,720 Okay, so instead of a million separate files 229 00:08:35,720 --> 00:08:37,680 sitting in messy folders on a hard drive, 230 00:08:37,680 --> 00:08:40,560 your inbox is actually just a highly organized series 231 00:08:40,560 --> 00:08:43,400 of entries in a massive high-speed database. 232 00:08:43,400 --> 00:08:45,560 Exactly, and the magic really happens 233 00:08:45,560 --> 00:08:48,080 in how the server talks to that database. 234 00:08:48,080 --> 00:08:49,440 All the application servers, 235 00:08:49,440 --> 00:08:51,320 the machines that actually answer your phone 236 00:08:51,320 --> 00:08:54,160 when it checks for new mail, are what we call stateless. 237 00:08:54,160 --> 00:08:55,320 Wait, stateless? 238 00:08:55,320 --> 00:08:57,660 Does that mean the server literally forgets who I am 239 00:08:57,660 --> 00:09:00,040 the second after it hands me my email? 240 00:09:00,040 --> 00:09:01,200 Like, so that doesn't get bogged down 241 00:09:01,200 --> 00:09:02,500 holding onto my connection. 242 00:09:02,500 --> 00:09:03,920 That is exactly what it means. 243 00:09:03,920 --> 00:09:05,720 It holds no personal data. 244 00:09:05,720 --> 00:09:08,120 It doesn't remember what you did five seconds ago. 245 00:09:08,120 --> 00:09:11,920 These stateless servers just sit behind a TCP load balancer. 246 00:09:11,920 --> 00:09:13,720 So the load balancer is like the traffic cop. 247 00:09:13,720 --> 00:09:17,120 Yes, think of it as a hyper-efficient traffic cop 248 00:09:17,120 --> 00:09:19,460 at a very busy intersection. 249 00:09:19,460 --> 00:09:21,100 When you open your email app, 250 00:09:21,100 --> 00:09:24,560 the traffic cop looks at 50 different Wild Duck servers, 251 00:09:24,560 --> 00:09:27,200 finds the one that's currently the least busy, 252 00:09:27,200 --> 00:09:28,680 and directs your request there. 253 00:09:28,680 --> 00:09:29,800 And then what happens? 254 00:09:29,800 --> 00:09:32,520 That server instantly grabs your specific data 255 00:09:32,520 --> 00:09:35,880 from the sharded MongoDB database, hands it to you, 256 00:09:35,880 --> 00:09:37,360 and immediately forgets about you 257 00:09:37,360 --> 00:09:39,380 so it can serve the next person. 258 00:09:39,380 --> 00:09:42,320 That mechanism is how you get horizontal scalability 259 00:09:42,320 --> 00:09:44,840 and completely eliminate the single point of failure. 260 00:09:44,840 --> 00:09:46,960 That is incredibly clever. 261 00:09:46,960 --> 00:09:48,280 But the sources also mentioned 262 00:09:48,280 --> 00:09:51,500 this specific storage trick they use for attachments, 263 00:09:51,500 --> 00:09:53,640 which I thought was the biggest aha moment 264 00:09:53,640 --> 00:09:55,360 in the entire documentation, 265 00:09:55,360 --> 00:09:57,320 especially from a financial perspective. 266 00:09:57,320 --> 00:09:59,320 Oh, the database splitting. 267 00:09:59,320 --> 00:10:00,860 Yes, this is a profound advantage 268 00:10:00,860 --> 00:10:03,180 for organizations trying to manage costs. 269 00:10:03,180 --> 00:10:04,480 Let's actually do the math on this, 270 00:10:04,480 --> 00:10:07,580 because attachments, you know, heavy PDF reports, 271 00:10:07,580 --> 00:10:10,020 massive video files, or high-res images 272 00:10:10,020 --> 00:10:11,920 take up a ton of space. 273 00:10:11,920 --> 00:10:14,420 Wild Duck's database fundamentally separates 274 00:10:14,420 --> 00:10:16,360 the attachments from the text of the email. 275 00:10:16,360 --> 00:10:17,200 Right. 276 00:10:17,200 --> 00:10:19,900 So imagine a company has 10,000 employees, 277 00:10:19,900 --> 00:10:21,560 and over the years they each accumulate 278 00:10:21,560 --> 00:10:24,140 10 gigabytes of old attachments. 279 00:10:24,140 --> 00:10:27,160 That is 100 terabytes of data, 280 00:10:27,160 --> 00:10:29,920 paying for 100 terabytes of ultra-fast 281 00:10:29,920 --> 00:10:32,080 enterprise-grade SSD storage 282 00:10:32,080 --> 00:10:34,080 would completely bankrupt an IT department. 283 00:10:34,080 --> 00:10:37,000 It would be astronomically expensive, just unfeasible. 284 00:10:37,000 --> 00:10:38,240 Right, but with Wild Duck, 285 00:10:38,240 --> 00:10:40,480 you can store those 100 terabytes of heavy attachments 286 00:10:40,480 --> 00:10:43,400 on large, cheap, spinning SATA hard drives 287 00:10:43,400 --> 00:10:45,380 while keeping the actual text of the messages 288 00:10:45,380 --> 00:10:48,360 on much smaller, blazing-fast SSD drives. 289 00:10:48,360 --> 00:10:50,320 Yeah, the cost savings there are ridiculous. 290 00:10:50,320 --> 00:10:52,280 So when a user searches their inbox 291 00:10:52,280 --> 00:10:54,720 for a specific phrase from a contract, 292 00:10:54,720 --> 00:10:57,160 the system searches the lightning-fast SSDs 293 00:10:57,160 --> 00:10:58,960 and returns the result instantly. 294 00:10:58,960 --> 00:11:02,560 But it's not wasting expensive high-speed storage 295 00:11:02,560 --> 00:11:04,860 on a 10 megabyte PowerPoint presentation 296 00:11:04,860 --> 00:11:06,460 from three years ago. 297 00:11:06,460 --> 00:11:08,720 That's not just a neat tech trick. 298 00:11:08,720 --> 00:11:10,840 That is a massive financial loophole. 299 00:11:10,840 --> 00:11:13,320 It's a level of granular resource management 300 00:11:13,320 --> 00:11:15,360 that traditional setups struggle to achieve 301 00:11:15,360 --> 00:11:18,120 without incredibly complex workarounds. 302 00:11:18,120 --> 00:11:22,080 You're getting SSD search speeds for pennies on the dollar. 303 00:11:22,080 --> 00:11:24,380 But if we follow this logic, 304 00:11:24,380 --> 00:11:27,400 ripping out the file system actually creates a new problem. 305 00:11:27,400 --> 00:11:29,640 Exactly. Okay, so you've ripped out the file system 306 00:11:29,640 --> 00:11:31,640 to save storage and increase speed. 307 00:11:31,640 --> 00:11:33,640 But by doing that, you've also ripped out 308 00:11:33,640 --> 00:11:37,000 the traditional configuration files that IT guys rely on. 309 00:11:37,000 --> 00:11:39,200 Wait, no config files and no file system. 310 00:11:39,200 --> 00:11:40,460 How do you even control it? 311 00:11:40,460 --> 00:11:42,360 You don't use config files at all. 312 00:11:42,360 --> 00:11:44,320 Because if I think about traditional IT, 313 00:11:44,320 --> 00:11:47,220 configuring a server means opening up a terminal window, 314 00:11:47,220 --> 00:11:49,160 digging into a complicated text file, 315 00:11:49,160 --> 00:11:50,440 changing a few lines of code, 316 00:11:50,440 --> 00:11:52,120 and just praying you didn't miss a comma 317 00:11:52,120 --> 00:11:53,400 and break the whole server. 318 00:11:53,400 --> 00:11:56,040 Oh, yeah, we've all been there, but not here. 319 00:11:56,040 --> 00:11:58,040 Here's where it gets really interesting. 320 00:11:58,040 --> 00:12:00,120 Everything, literally everything, 321 00:12:00,120 --> 00:12:02,840 is controlled via a REST API. 322 00:12:02,840 --> 00:12:06,180 I want to make sure we visualize this correctly for everyone, 323 00:12:06,180 --> 00:12:08,840 because a lot of people throw around the term API. 324 00:12:08,840 --> 00:12:12,000 Configuring a traditional server with text files 325 00:12:12,000 --> 00:12:13,960 is like going into a busy restaurant kitchen 326 00:12:13,960 --> 00:12:16,160 and trying to cook the meal yourself, right? 327 00:12:16,160 --> 00:12:17,920 You have to touch the raw ingredients, 328 00:12:17,920 --> 00:12:19,680 navigate the hot stoves, 329 00:12:19,680 --> 00:12:21,720 and hope you don't burn the place down. 330 00:12:21,720 --> 00:12:24,760 But using a REST API is like sitting at your table 331 00:12:24,760 --> 00:12:27,280 and giving a highly specific order to a waiter. 332 00:12:27,280 --> 00:12:29,800 You just pass a standard formatted request, 333 00:12:29,800 --> 00:12:31,920 and the kitchen handles the messy reality 334 00:12:31,920 --> 00:12:33,880 of executing it by enclosed doors. 335 00:12:33,880 --> 00:12:35,520 That is the perfect analogy. 336 00:12:35,520 --> 00:12:38,080 It's clean machine-to-machine communication. 337 00:12:38,080 --> 00:12:41,160 You send an HTTP request, just like loading a webpage, 338 00:12:41,160 --> 00:12:43,120 and the database updates instantly. 339 00:12:43,120 --> 00:12:44,360 And because it's an API, 340 00:12:44,360 --> 00:12:46,360 it means developers can write their own custom scripts 341 00:12:46,360 --> 00:12:48,880 or graphical interfaces to manage the server 342 00:12:48,880 --> 00:12:49,700 programmatically. 343 00:12:49,700 --> 00:12:51,720 It means no one is ever typing raw code 344 00:12:51,720 --> 00:12:53,600 into a live server environment. 345 00:12:53,600 --> 00:12:54,480 Exactly. 346 00:12:54,480 --> 00:12:58,540 And think about what API First Control allows for at scale. 347 00:12:58,540 --> 00:13:00,440 If we connect this to the bigger picture, 348 00:13:00,440 --> 00:13:02,680 you have instant granular management 349 00:13:02,680 --> 00:13:05,400 over mail account settings, server-side filtering, 350 00:13:05,400 --> 00:13:09,240 auto replies, even complex cryptographic setups like DCAM. 351 00:13:09,240 --> 00:13:11,840 DCAM, that's Domain Keys Identified Mail, right? 352 00:13:11,840 --> 00:13:14,240 Basically, the digital wax seal on your envelope 353 00:13:14,240 --> 00:13:16,800 that proves your server actually sent the email 354 00:13:16,800 --> 00:13:17,800 and isn't a spammer. 355 00:13:17,800 --> 00:13:19,680 Spot on, in a traditional setup, 356 00:13:19,680 --> 00:13:22,200 configuring DCAM is a nightmare of text files 357 00:13:22,200 --> 00:13:23,680 and key generations. 358 00:13:23,680 --> 00:13:25,600 Here, you just send an API request, 359 00:13:25,600 --> 00:13:28,280 and the system handles the cryptographic generation 360 00:13:28,280 --> 00:13:29,160 internally. 361 00:13:29,160 --> 00:13:31,440 And it also changes the experience for the end user, 362 00:13:31,440 --> 00:13:32,080 doesn't it? 363 00:13:32,080 --> 00:13:34,600 The sources highlight that their demo webmail application 364 00:13:34,600 --> 00:13:37,480 is blazing fast, but every company 365 00:13:37,480 --> 00:13:38,880 claims their software is fast. 366 00:13:38,880 --> 00:13:41,560 What is the actual mechanism making it faster here? 367 00:13:41,560 --> 00:13:44,640 It comes down to bypassing the translation overhead. 368 00:13:44,640 --> 00:13:47,000 Think about a traditional desktop mail client, 369 00:13:47,000 --> 00:13:50,000 like when you buy a new laptop and set up Microsoft Outlook. 370 00:13:50,000 --> 00:13:52,280 Oh, it takes 20 minutes just to download the headers 371 00:13:52,280 --> 00:13:54,120 and sync thousands of old emails. 372 00:13:54,120 --> 00:13:56,080 You just sit there staring at a progress bar. 373 00:13:56,080 --> 00:13:56,920 Exactly. 374 00:13:56,920 --> 00:13:59,600 That happens because the server and the client 375 00:13:59,600 --> 00:14:01,560 have to talk using IMAP. 376 00:14:01,560 --> 00:14:04,560 And the server has to parse MIME data. 377 00:14:04,560 --> 00:14:07,080 MME is the old heavy formatting language 378 00:14:07,080 --> 00:14:08,520 that emails are sent in. 379 00:14:08,520 --> 00:14:11,360 It tells the computer what is text, what is HTML, 380 00:14:11,360 --> 00:14:12,680 what's an attachment. 381 00:14:12,680 --> 00:14:16,560 Translating all of that takes processing power and time. 382 00:14:16,560 --> 00:14:20,160 But the Wild Duck web mail is a modern Node.js application 383 00:14:20,160 --> 00:14:24,160 that just uses the REST API to talk directly to the database. 384 00:14:24,160 --> 00:14:25,640 It doesn't use IMAP at all. 385 00:14:25,640 --> 00:14:28,840 So it's loading pre-parsed data straight from MongoDB. 386 00:14:28,840 --> 00:14:29,920 Precisely. 387 00:14:29,920 --> 00:14:33,000 It essentially bypasses the heavy lifting entirely. 388 00:14:33,000 --> 00:14:36,120 Instead of syncing files, it's querying a database, 389 00:14:36,120 --> 00:14:38,680 which allows the inbox to load as instantly as a Netflix 390 00:14:38,680 --> 00:14:39,800 catalog. 391 00:14:39,800 --> 00:14:42,600 You open the app, the database returns the specific text 392 00:14:42,600 --> 00:14:45,200 you need in milliseconds, and the UI renders it. 393 00:14:45,200 --> 00:14:47,040 OK, so we have this system that operates 394 00:14:47,040 --> 00:14:49,440 like a high-speed database, controlled entirely 395 00:14:49,440 --> 00:14:52,480 by modern web APIs, routing traffic dynamically, 396 00:14:52,480 --> 00:14:53,680 saving money on storage. 397 00:14:53,680 --> 00:14:55,240 I mean, it sounds incredible. 398 00:14:55,240 --> 00:14:57,600 But my immediate thought, and I'm sure the thought of any IT 399 00:14:57,600 --> 00:15:00,040 director listening to this, is about security. 400 00:15:00,040 --> 00:15:03,000 If everything is controlled by a web API, 401 00:15:03,000 --> 00:15:04,920 and all of a company's sensitive data 402 00:15:04,920 --> 00:15:09,640 is stored in a giant database instead of isolated files, 403 00:15:09,640 --> 00:15:11,320 isn't that a massive target? 404 00:15:11,320 --> 00:15:12,800 Is this actually secure? 405 00:15:12,800 --> 00:15:14,580 Those are the exact right questions 406 00:15:14,580 --> 00:15:17,460 to ask, especially when moving away from battle-tested legacy 407 00:15:17,460 --> 00:15:21,480 software, that the developers behind Wildeck built security 408 00:15:21,480 --> 00:15:23,520 at the foundational level, largely 409 00:15:23,520 --> 00:15:26,780 by removing the vectors that hackers usually exploit. 410 00:15:26,780 --> 00:15:28,240 First off, the entire application 411 00:15:28,240 --> 00:15:31,360 is written in Node.js, which is a memory-safe language. 412 00:15:31,360 --> 00:15:33,200 Let's clarify what that means for a beginner. 413 00:15:33,200 --> 00:15:35,680 A lot of legacy software is written in older languages, 414 00:15:35,680 --> 00:15:36,520 like C, right? 415 00:15:36,520 --> 00:15:39,240 Yes, and older languages like C are vulnerable to what 416 00:15:39,240 --> 00:15:40,800 we call buffer overflows. 417 00:15:40,800 --> 00:15:42,320 Right, which is basically like trying 418 00:15:42,320 --> 00:15:44,920 to pour a gallon of water into a pint glass. 419 00:15:44,920 --> 00:15:47,800 The extra water spills over onto the table. 420 00:15:47,800 --> 00:15:50,340 In a computer, if a hacker sends too much data 421 00:15:50,340 --> 00:15:52,480 to a memory space that can't hold it, 422 00:15:52,480 --> 00:15:55,160 the extra data spills over into other parts of the system's 423 00:15:55,160 --> 00:15:57,240 memory, allowing the hacker to overwrite 424 00:15:57,240 --> 00:15:59,720 the actual instructions the computer is running. 425 00:15:59,720 --> 00:16:00,720 Exactly. 426 00:16:00,720 --> 00:16:02,880 Memory-safe languages like Node.js 427 00:16:02,880 --> 00:16:04,840 automatically manage that glass. 428 00:16:04,840 --> 00:16:06,840 If you try to pour a gallon in, the language 429 00:16:06,840 --> 00:16:08,960 safely stops it from spilling over. 430 00:16:08,960 --> 00:16:10,880 But the security goes much deeper 431 00:16:10,880 --> 00:16:13,000 than just the programming language. 432 00:16:13,000 --> 00:16:15,760 Let's look at how taking away the file system fundamentally 433 00:16:15,760 --> 00:16:18,160 breaks a hacker's standard playbook. 434 00:16:18,160 --> 00:16:20,440 Because there's no hard drive for them to access. 435 00:16:20,440 --> 00:16:21,760 Essentially, yes. 436 00:16:21,760 --> 00:16:23,740 Because of its architecture, Wild Duck 437 00:16:23,740 --> 00:16:27,000 requires absolutely no root privileges to run. 438 00:16:27,000 --> 00:16:29,520 It doesn't touch the server's local file system, 439 00:16:29,520 --> 00:16:31,480 and it doesn't run any shell commands. 440 00:16:31,480 --> 00:16:32,160 That's wild. 441 00:16:32,160 --> 00:16:32,840 It is. 442 00:16:32,840 --> 00:16:34,440 Think about a traditional hack. 443 00:16:34,440 --> 00:16:36,200 A bad actor finds a vulnerability, 444 00:16:36,200 --> 00:16:37,960 and their very next step is usually 445 00:16:37,960 --> 00:16:41,100 to drop a malicious executable file, a payload, 446 00:16:41,100 --> 00:16:44,040 onto the server's hard drive to establish a backdoor. 447 00:16:44,040 --> 00:16:47,720 But if they compromise a Wild Duck application server, 448 00:16:47,720 --> 00:16:50,280 the application functionally doesn't have a hard drive. 449 00:16:50,280 --> 00:16:51,040 Exactly. 450 00:16:51,040 --> 00:16:52,860 The hacker gets in and finds themselves 451 00:16:52,860 --> 00:16:55,100 in an empty, stateless room. 452 00:16:55,100 --> 00:16:57,040 They wouldn't find a traditional file system 453 00:16:57,040 --> 00:16:58,000 to exploit. 454 00:16:58,000 --> 00:17:00,120 They can't save a payload because the server forgets 455 00:17:00,120 --> 00:17:01,560 everything instantly. 456 00:17:01,560 --> 00:17:03,960 And they wouldn't have the permissions to run operating 457 00:17:03,960 --> 00:17:05,640 system commands anyway. 458 00:17:05,640 --> 00:17:08,600 It neutralizes entire categories of cyber attacks. 459 00:17:08,600 --> 00:17:11,560 That is a massive relief for system administrators. 460 00:17:11,560 --> 00:17:13,800 But what about user-level protections? 461 00:17:13,800 --> 00:17:17,400 Because the server itself might be an impenetrable fortress. 462 00:17:17,400 --> 00:17:21,520 But users are, well, notorious for having terrible passwords 463 00:17:21,520 --> 00:17:22,400 or getting phished. 464 00:17:22,400 --> 00:17:23,200 True. 465 00:17:23,200 --> 00:17:25,620 And they've accounted for the human element, too. 466 00:17:25,620 --> 00:17:28,920 Wild Duck has built-in support for application-specific 467 00:17:28,920 --> 00:17:29,640 passwords. 468 00:17:29,640 --> 00:17:30,520 Oh, I love those. 469 00:17:30,520 --> 00:17:33,480 That's when you generate a unique, random 16-karature 470 00:17:33,480 --> 00:17:35,840 password just for your phone's email app. 471 00:17:35,840 --> 00:17:36,480 Exactly. 472 00:17:36,480 --> 00:17:38,840 That way, you don't have to put your actual main account 473 00:17:38,840 --> 00:17:41,240 password into a third-party device. 474 00:17:41,240 --> 00:17:42,960 If your phone gets stolen, you just 475 00:17:42,960 --> 00:17:44,600 revoke that one specific password 476 00:17:44,600 --> 00:17:46,400 without changing your main login. 477 00:17:46,400 --> 00:17:48,800 It isolates the risk perfectly. 478 00:17:48,800 --> 00:17:51,560 Furthermore, it fully supports multi-factor authentication 479 00:17:51,560 --> 00:17:53,600 natively at the database level. 480 00:17:53,600 --> 00:17:57,400 This includes both TOTC, which are those rolling six-digit 481 00:17:57,400 --> 00:17:59,680 codes generated by an app on your phone, 482 00:17:59,680 --> 00:18:03,640 and U2F hardware security keys, like a physical UV key 483 00:18:03,640 --> 00:18:05,080 you plug into your laptop. 484 00:18:05,080 --> 00:18:06,920 So it's fully up to modern standards. 485 00:18:06,920 --> 00:18:08,040 Oh, completely. 486 00:18:08,040 --> 00:18:10,480 It also features strict automatic rate 487 00:18:10,480 --> 00:18:13,880 limiting to prevent brute force password guessing attacks. 488 00:18:13,880 --> 00:18:15,880 But here is the ultimate failsafe 489 00:18:15,880 --> 00:18:18,520 for the highly privacy-conscious users 490 00:18:18,520 --> 00:18:22,000 can even set a GPG public key in their settings. 491 00:18:22,000 --> 00:18:25,000 And Wild Duck will automatically encrypt their stored emails 492 00:18:25,000 --> 00:18:26,320 the moment they arrive. 493 00:18:26,320 --> 00:18:27,160 Wow, wait. 494 00:18:27,160 --> 00:18:30,600 So if they set a GTG key, the server encrypts the message 495 00:18:30,600 --> 00:18:32,960 before saving it to MongoDB. 496 00:18:32,960 --> 00:18:35,960 Which means even if a highly sophisticated hacker somehow 497 00:18:35,960 --> 00:18:38,700 stole a copy of the raw database itself, 498 00:18:38,700 --> 00:18:40,440 all they would see is encrypted gibberish. 499 00:18:40,440 --> 00:18:41,440 Nothing but gibberish. 500 00:18:41,440 --> 00:18:42,680 They couldn't read a single email 501 00:18:42,680 --> 00:18:45,180 without the user's private key, which the server doesn't even 502 00:18:45,180 --> 00:18:45,680 have. 503 00:18:45,680 --> 00:18:46,340 Precisely. 504 00:18:46,340 --> 00:18:48,520 It operates on a zero-knowledge principle 505 00:18:48,520 --> 00:18:50,140 for those specific emails. 506 00:18:50,140 --> 00:18:52,720 There's one more feature I want to highlight from the sources, 507 00:18:52,720 --> 00:18:55,820 because it anchors this highly advanced tech back 508 00:18:55,820 --> 00:18:58,000 to a very basic human level. 509 00:18:58,000 --> 00:19:00,760 And frankly, it shocked me that this is still an issue today. 510 00:19:00,760 --> 00:19:03,320 Wild Duck takes a Unicode-first approach. 511 00:19:03,320 --> 00:19:04,920 Yes, the character support. 512 00:19:04,920 --> 00:19:05,480 Yeah. 513 00:19:05,480 --> 00:19:09,080 The documentation specifically cites a fully valid email 514 00:19:09,080 --> 00:19:11,720 address hosted right now on their instance. 515 00:19:11,720 --> 00:19:13,320 It's entirely in the Cyrillic script. 516 00:19:13,320 --> 00:19:16,280 It reads, eh, eh, hey. 517 00:19:16,280 --> 00:19:18,640 It's just surprising to me that in modern times, 518 00:19:18,640 --> 00:19:21,920 non-Latin characters and email addresses or folder names 519 00:19:21,920 --> 00:19:26,160 still cause so many older systems to completely break down. 520 00:19:26,160 --> 00:19:29,000 It's a remnant of how incredibly old email protocols 521 00:19:29,000 --> 00:19:29,800 actually are. 522 00:19:29,800 --> 00:19:32,400 I mean, they were originally designed in the 1970s and 80s 523 00:19:32,400 --> 00:19:33,920 strictly for the English alphabet 524 00:19:33,920 --> 00:19:36,280 and basic ASCII characters. 525 00:19:36,280 --> 00:19:38,480 While extensions have been bolted on over the decades, 526 00:19:38,480 --> 00:19:40,160 many legacy servers still struggle 527 00:19:40,160 --> 00:19:41,520 with full Unicode support. 528 00:19:41,520 --> 00:19:43,600 They just panic if they see an emoji. 529 00:19:43,600 --> 00:19:44,600 Pretty much. 530 00:19:44,600 --> 00:19:47,680 They throw errors if a folder name has an emoji 531 00:19:47,680 --> 00:19:50,600 or if an email address uses Arabic, Japanese, 532 00:19:50,600 --> 00:19:52,280 or Cyrillic characters. 533 00:19:52,280 --> 00:19:54,520 Wild Duck, being built from the ground up 534 00:19:54,520 --> 00:19:57,160 for the modern web, supports all Unicode extensions 535 00:19:57,160 --> 00:19:59,080 perfectly at the database level, 536 00:19:59,080 --> 00:20:01,760 whether it's the email address itself, the folder names, 537 00:20:01,760 --> 00:20:03,680 or the complex message headers. 538 00:20:03,680 --> 00:20:04,760 So what does this all mean? 539 00:20:04,760 --> 00:20:06,520 Let's step back and look at it. 540 00:20:06,520 --> 00:20:10,080 We have an incredibly scalable opinionated email server. 541 00:20:10,080 --> 00:20:12,220 It operates like a high-speed database, 542 00:20:12,220 --> 00:20:14,920 routing traffic dynamically through stateless nodes. 543 00:20:14,920 --> 00:20:15,840 Yep. 544 00:20:15,840 --> 00:20:18,480 It saves a fortune by splitting heavy attachments 545 00:20:18,480 --> 00:20:20,120 onto cheap hard drives. 546 00:20:20,120 --> 00:20:23,920 It natively speaks modern web protocols via an API, 547 00:20:23,920 --> 00:20:26,200 supports global alphabets flawlessly, 548 00:20:26,200 --> 00:20:27,860 and completely locks down security 549 00:20:27,860 --> 00:20:30,240 by removing file system access entirely. 550 00:20:30,240 --> 00:20:32,240 This raises an important question, though. 551 00:20:32,240 --> 00:20:33,840 How can organizations practically 552 00:20:33,840 --> 00:20:36,600 take back control of their data without sacrificing 553 00:20:36,600 --> 00:20:38,520 that enterprise-level performance? 554 00:20:38,520 --> 00:20:41,200 What we see here is the immense value of open source tools. 555 00:20:41,200 --> 00:20:45,040 Wild Duck is licensed under the EUPL 1.2, the European Union 556 00:20:45,040 --> 00:20:46,640 public license. 557 00:20:46,640 --> 00:20:48,640 It's bringing the kind of scaling and security 558 00:20:48,640 --> 00:20:51,120 architecture that was previously only available 559 00:20:51,120 --> 00:20:53,800 to the massive tech giants, and handing it 560 00:20:53,800 --> 00:20:55,760 directly to independent organizations 561 00:20:55,760 --> 00:20:58,960 without forcing them to rely on proprietary platforms. 562 00:20:58,960 --> 00:21:01,280 It's democratizing the infrastructure. 563 00:21:01,280 --> 00:21:04,200 Which brings us perfectly back to the core use case 564 00:21:04,200 --> 00:21:06,240 that Safe Server focuses on. 565 00:21:06,240 --> 00:21:07,960 Because when an organization, whether it's 566 00:21:07,960 --> 00:21:10,760 a mid-sized business, a massive association, 567 00:21:10,760 --> 00:21:13,680 or any group dealing with thousands of users, 568 00:21:13,680 --> 00:21:15,760 realizes they don't have to be locked 569 00:21:15,760 --> 00:21:19,160 into an expensive proprietary ecosystem from Google 570 00:21:19,160 --> 00:21:22,080 or Microsoft, everything changes. 571 00:21:22,080 --> 00:21:24,000 They gain massive cost savings, certainly, 572 00:21:24,000 --> 00:21:26,080 especially with the hardware efficiencies we discuss. 573 00:21:26,080 --> 00:21:28,800 But more importantly, they gain granular control 574 00:21:28,800 --> 00:21:30,920 over their own infrastructure and achieve 575 00:21:30,920 --> 00:21:32,640 strict data sovereignty. 576 00:21:32,640 --> 00:21:34,600 They know exactly where their data is stored, 577 00:21:34,600 --> 00:21:37,440 exactly how it's being handled, and exactly how it's secured 578 00:21:37,440 --> 00:21:38,960 against modern threats. 579 00:21:38,960 --> 00:21:41,400 And navigating that transition doesn't 580 00:21:41,400 --> 00:21:43,880 have to be an overwhelming process. 581 00:21:43,880 --> 00:21:45,680 That's why Safe Server can be commissioned 582 00:21:45,680 --> 00:21:47,600 for specialized consulting. 583 00:21:47,600 --> 00:21:49,220 They help you look at your current setup 584 00:21:49,220 --> 00:21:52,360 and figure out if a highly scalable, opinionated solution 585 00:21:52,360 --> 00:21:56,120 like Wild Duck is the right fit for your organization, 586 00:21:56,120 --> 00:21:58,520 or if a comparable open source alternative 587 00:21:58,520 --> 00:22:00,680 makes more sense for your specific compliance 588 00:22:00,680 --> 00:22:02,080 and operational needs. 589 00:22:02,080 --> 00:22:03,760 They really take the guesswork out of it. 590 00:22:03,760 --> 00:22:06,280 They guide you from that first fundamental question 591 00:22:06,280 --> 00:22:09,700 all the way to secure everyday operation on German servers. 592 00:22:09,700 --> 00:22:11,160 You can learn how to make the switch 593 00:22:11,160 --> 00:22:14,280 and take back your sovereignty at safeserver.de. 594 00:22:14,280 --> 00:22:16,480 It really is about rethinking what 595 00:22:16,480 --> 00:22:19,600 is possible with the tools we use every single day. 596 00:22:19,600 --> 00:22:23,080 It is, which leaves me with one final provocative thought 597 00:22:23,080 --> 00:22:24,360 for you to mull over. 598 00:22:24,360 --> 00:22:26,960 We started this deep dive by comparing legacy email 599 00:22:26,960 --> 00:22:29,560 to a fragile digital filing cabinet. 600 00:22:29,560 --> 00:22:31,440 But if tools like Wild Duck are successfully 601 00:22:31,440 --> 00:22:34,680 turning the inbox into a blazing fast API-driven NoSQL 602 00:22:34,680 --> 00:22:38,200 database, what entirely new types of applications 603 00:22:38,200 --> 00:22:40,580 or automated workflows can we build on top of our email 604 00:22:40,580 --> 00:22:41,640 in the future? 605 00:22:41,640 --> 00:22:44,080 Once we stop treating email like a dusty filing cabinet 606 00:22:44,080 --> 00:22:47,920 start treating it like a high-speed programmable data stream becomes possible next.