1 00:00:00,000 --> 00:00:05,200 Welcome back to The Deep Dive. This deep dive is proudly supported by Safe Server. 2 00:00:05,200 --> 00:00:08,560 They handle the hosting for this kind of software and can really help with your 3 00:00:08,560 --> 00:00:10,160 digital transformation. 4 00:00:10,160 --> 00:00:15,280 You can find out more and see how they can help you at www.safeserver.de. 5 00:00:15,280 --> 00:00:19,920 So today we're undertaking a mission, a mission to understand what happens when you 6 00:00:19,920 --> 00:00:20,640 just decide to, 7 00:00:20,640 --> 00:00:24,880 you know, burn the communication servers to the ground. If you're tired of these 8 00:00:24,880 --> 00:00:25,360 centralized 9 00:00:25,360 --> 00:00:29,920 tech platforms treating your private conversations as, well, commercial inventory, 10 00:00:29,920 --> 00:00:30,240 or if you're 11 00:00:30,240 --> 00:00:34,380 worried about your data being decrypted years after you hit send, you need to hear 12 00:00:34,380 --> 00:00:34,720 about 13 00:00:34,720 --> 00:00:39,100 ChitChatter. It's a secure peer-to-peer chat application that is, and this is the 14 00:00:39,100 --> 00:00:39,440 key, 15 00:00:39,440 --> 00:00:43,200 truly serverless and ephemeral. And that's our challenge today. We've got a stack 16 00:00:43,200 --> 00:00:43,520 of source 17 00:00:43,520 --> 00:00:46,940 material here, mostly from the project's own GitHub reatomy. Our goal is to 18 00:00:46,940 --> 00:00:47,920 translate these 19 00:00:47,920 --> 00:00:51,920 sometimes intimidating concepts like decentralized web mesh architecture into 20 00:00:51,920 --> 00:00:52,880 something practical 21 00:00:52,880 --> 00:00:56,960 and really understandable. We're going to show you exactly how a modern high-functioning 22 00:00:56,960 --> 00:00:57,520 chat app can 23 00:00:57,520 --> 00:01:02,300 manage real-time video, audio, and file transfers without a single company running 24 00:01:02,300 --> 00:01:03,440 a database or, 25 00:01:03,440 --> 00:01:07,360 you know, a controlling server. That just sounds like a technical impossibility for 26 00:01:07,360 --> 00:01:07,920 most people. 27 00:01:07,920 --> 00:01:11,590 I mean, if you grew up on platforms like WhatsApp or Slack, the whole idea is there's 28 00:01:11,590 --> 00:01:12,240 a central 29 00:01:12,240 --> 00:01:16,620 place. So the paradox is, if there's no place to store the chat, how does the 30 00:01:16,620 --> 00:01:17,440 conversation even 31 00:01:17,440 --> 00:01:22,070 exist? Exactly. And the answer to that fundamentally changes everything for the 32 00:01:22,070 --> 00:01:23,520 user, from their security 33 00:01:23,520 --> 00:01:28,920 to their regulatory exposure. Okay, let's unpack this then. Let's start with the 34 00:01:28,920 --> 00:01:30,000 why, the underlying 35 00:01:30,000 --> 00:01:34,020 risk. Why did the developers feel they even needed to build this? Well, it all 36 00:01:34,020 --> 00:01:35,520 comes down to eliminating 37 00:01:35,520 --> 00:01:40,210 the target and the lever. All the existing user-friendly apps, they rely on a 38 00:01:40,210 --> 00:01:40,720 central 39 00:01:40,720 --> 00:01:44,680 service. And that central service, it just inevitably creates this massive data 40 00:01:44,680 --> 00:01:45,840 target that 41 00:01:45,840 --> 00:01:50,090 hackers or even nation states want to get into. And critically, that central 42 00:01:50,090 --> 00:01:51,200 service also gives 43 00:01:51,200 --> 00:01:55,220 commercial interests and governments a legal lever. They can compel the operator to 44 00:01:55,220 --> 00:01:56,080 hand over user 45 00:01:56,080 --> 00:02:00,720 data or maybe even future decryption keys. Right, so even if the data is encrypted, 46 00:02:00,720 --> 00:02:01,600 which, you know, 47 00:02:01,600 --> 00:02:05,610 most major platforms promise, the real worry is that if they're storing that 48 00:02:05,610 --> 00:02:07,520 encrypted data at rest, 49 00:02:07,520 --> 00:02:12,320 then some future technological breakthrough or judicial pressure could force them 50 00:02:12,320 --> 00:02:12,960 to decrypt it. 51 00:02:12,960 --> 00:02:17,140 Precisely. If the company holds the encrypted data, they hold the eventual risk. Chit 52 00:02:17,140 --> 00:02:18,160 Chatter's whole 53 00:02:18,160 --> 00:02:22,270 architecture is designed to avoid that problem. By making sure there is no central 54 00:02:22,270 --> 00:02:22,880 database, 55 00:02:22,880 --> 00:02:27,280 it means there's nothing for a third party to hack and nothing for a judge to subpoena. 56 00:02:27,280 --> 00:02:31,160 So that's the web mesh architecture in action. To make this work, the sources 57 00:02:31,160 --> 00:02:31,760 highlight what they 58 00:02:31,760 --> 00:02:36,440 call the big three pillars. Let's tackle the jargon head on. First up, 59 00:02:36,440 --> 00:02:38,800 decentralized or serverless? 60 00:02:38,800 --> 00:02:42,240 If they don't have an API server, where does the app itself even live? That's a 61 00:02:42,240 --> 00:02:43,280 great question because 62 00:02:43,280 --> 00:02:47,920 this is where the system gets pretty clever. For its basic functionality, Chit Chatter 63 00:02:47,920 --> 00:02:48,640 only requires 64 00:02:48,640 --> 00:02:53,220 things that already exist publicly. It needs GitHub, which is really just acting as 65 00:02:53,220 --> 00:02:53,600 a public 66 00:02:53,600 --> 00:02:57,640 distribution point. Think of it like a free shelf, where anyone can download the 67 00:02:57,640 --> 00:02:58,800 application code, 68 00:02:58,800 --> 00:03:03,690 the static assets. Then for the connection, it relies on public web torrent and 69 00:03:03,690 --> 00:03:05,360 turn relay servers. 70 00:03:05,360 --> 00:03:09,940 These are just generalized public services used by lots of P2P applications. Okay, 71 00:03:09,940 --> 00:03:11,200 so the app itself 72 00:03:11,200 --> 00:03:15,490 is hosted on one public service and the connection setup relies on other public 73 00:03:15,490 --> 00:03:17,360 services. But, 74 00:03:17,360 --> 00:03:21,280 and this is the key part, none of these third parties are actually managing or 75 00:03:21,280 --> 00:03:21,680 seeing the 76 00:03:21,680 --> 00:03:25,040 conversation. Correct. The conversation is totally private, peer-to-peer. It's sort 77 00:03:25,040 --> 00:03:26,240 of like downloading 78 00:03:26,240 --> 00:03:29,550 an application from a public library and then using a public phone book to find 79 00:03:29,550 --> 00:03:30,240 your contact's 80 00:03:30,240 --> 00:03:34,770 number. But the actual phone call is a direct line-to-line connection, not routed 81 00:03:34,770 --> 00:03:35,440 through the 82 00:03:35,440 --> 00:03:39,200 library's central office. That makes sense. And that leads us to the second pillar, 83 00:03:39,200 --> 00:03:39,760 which is 84 00:03:39,760 --> 00:03:44,440 ephemeral. I know it means temporary, but what's the practical implication of a 85 00:03:44,440 --> 00:03:45,680 chat app being 86 00:03:45,680 --> 00:03:51,440 truly ephemeral? The implication is irreversible loss. The source material is very, 87 00:03:51,440 --> 00:03:51,920 very clear 88 00:03:51,920 --> 00:03:56,570 about this. Message content is never persisted to disk, not on the client, and 89 00:03:56,570 --> 00:03:57,520 certainly not 90 00:03:57,520 --> 00:04:01,960 on any server. If you're in a peer room and you close that window, those messages 91 00:04:01,960 --> 00:04:03,200 are cleared from 92 00:04:03,200 --> 00:04:08,080 your device's memory. They are just gone forever. Wow, okay. That's a huge trade-off 93 00:04:08,080 --> 00:04:09,040 for security. 94 00:04:09,040 --> 00:04:13,200 You gain absolute privacy, but you lose your chat history permanently. That would 95 00:04:13,200 --> 00:04:13,440 have to 96 00:04:13,440 --> 00:04:17,820 change user behavior in a big way. It does, but it absolutely guarantees that 97 00:04:17,820 --> 00:04:18,640 whatever you discussed 98 00:04:18,640 --> 00:04:23,230 cannot be retrieved. And the third pillar, the layer that really seals the private 99 00:04:23,230 --> 00:04:24,000 conversation, 100 00:04:24,000 --> 00:04:28,720 is end-to-end encryption. Since the chat runs on WebRTC, that's the standard 101 00:04:28,720 --> 00:04:29,280 protocol for 102 00:04:29,280 --> 00:04:33,160 browser-to-browser real-time communication, the data is encrypted from the moment 103 00:04:33,160 --> 00:04:33,360 it leaves 104 00:04:33,360 --> 00:04:36,670 your browser until it lands in your peer's browser. All right, that covers the 105 00:04:36,670 --> 00:04:37,040 philosophy 106 00:04:37,040 --> 00:04:40,920 of minimizing risk. Let's get into the mechanics now. If I want to start a secure 107 00:04:40,920 --> 00:04:41,760 chat right this 108 00:04:41,760 --> 00:04:46,400 second, how does a connection actually happen? It starts really simply. You open 109 00:04:46,400 --> 00:04:48,560 https.chitchatter.im 110 00:04:48,560 --> 00:04:53,960 and you join a room. By default, the app generates a long randomized string, a UEID, 111 00:04:53,960 --> 00:04:54,560 right there on 112 00:04:54,560 --> 00:04:58,440 your device in your browser. And that's your room name. And the conversation is 113 00:04:58,440 --> 00:04:59,520 mostly browser-to-browser, 114 00:04:59,520 --> 00:05:04,100 P2P. But what if, you know, my network firewall is being difficult or my peer is in 115 00:05:04,100 --> 00:05:04,480 a tricky 116 00:05:04,480 --> 00:05:08,880 location? P2P connections aren't always a sure thing. That's a critical challenge 117 00:05:08,880 --> 00:05:09,200 for any 118 00:05:09,200 --> 00:05:13,280 decentralized app, and they've thought about it. If a direct P2P connection isn't 119 00:05:13,280 --> 00:05:14,080 possible because 120 00:05:14,080 --> 00:05:18,230 of network conditions, Chit Shatter just gracefully falls back to using a turn 121 00:05:18,230 --> 00:05:19,200 relay server. 122 00:05:19,200 --> 00:05:24,660 This turn server, it acts as a kind of temporary digital bridge. It just relays the 123 00:05:24,660 --> 00:05:25,200 encrypted 124 00:05:25,200 --> 00:05:29,840 packets without ever decrypting or storing the content. So it ensures reliability 125 00:05:29,840 --> 00:05:30,000 while 126 00:05:30,000 --> 00:05:34,000 maintaining that security framework. Now, this feels like the most crucial security 127 00:05:34,000 --> 00:05:34,480 step for 128 00:05:34,480 --> 00:05:38,640 anyone listening to Grasp. Since there's no central key management, the user has to 129 00:05:38,640 --> 00:05:38,880 do the 130 00:05:38,880 --> 00:05:43,330 security handshake themselves. The room name is the key. Yes, and this is 131 00:05:43,330 --> 00:05:44,960 absolutely non-negotiable 132 00:05:44,960 --> 00:05:49,820 for security. Users must share that unique URL which has the room name in it 133 00:05:49,820 --> 00:05:50,960 through a secure 134 00:05:50,960 --> 00:05:56,160 out-of-band channel. The sources specifically recommend tools like BurnerNote or Yo-Pass. 135 00:05:56,160 --> 00:06:02,000 And the reason is simple but profound. The room name acts as the file transfer 136 00:06:02,000 --> 00:06:03,120 encryption key. 137 00:06:03,120 --> 00:06:07,930 Okay, so if I get lazy and I just send that URL in an insecure SMS or an unencrypted 138 00:06:07,930 --> 00:06:08,800 email, 139 00:06:08,800 --> 00:06:12,960 what's the risk? The risk is that anyone who intercepts that insecure message now 140 00:06:12,960 --> 00:06:13,360 has the 141 00:06:13,360 --> 00:06:18,240 room name. That's the key to decrypting any file transfers and maybe even joining 142 00:06:18,240 --> 00:06:19,520 the room itself. 143 00:06:19,520 --> 00:06:23,000 You've basically just centralized the risk right back into the insecure channel you 144 00:06:23,000 --> 00:06:23,520 chose for the 145 00:06:23,520 --> 00:06:27,680 setup. The tech forces you to be the security manager for that initial handshake. 146 00:06:27,680 --> 00:06:28,000 That's a 147 00:06:28,000 --> 00:06:31,920 powerful insight. The biggest weakness in a serverless system is often the human 148 00:06:31,920 --> 00:06:32,320 element 149 00:06:32,320 --> 00:06:35,380 in sharing those initial connection details. Absolutely. Let's shift a little bit 150 00:06:35,380 --> 00:06:35,680 to the 151 00:06:35,680 --> 00:06:39,840 features that build trust. For these privacy-focused tools, what they don't do 152 00:06:39,840 --> 00:06:40,960 often speaks louder than 153 00:06:40,960 --> 00:06:45,540 what they do. I think you call them anti-features. Exactly. And the list is short 154 00:06:45,540 --> 00:06:46,480 and sweet. No 155 00:06:46,480 --> 00:06:51,820 analytics, no tracking, no telemetry. Period. The heavy lifting is all done client-side 156 00:06:51,820 --> 00:06:52,080 right in your 157 00:06:52,080 --> 00:06:56,490 browser, not on some developer's infrastructure. And this leads perfectly to that 158 00:06:56,490 --> 00:06:57,520 optional API 159 00:06:57,520 --> 00:07:02,850 server configuration we saw in the notes. For a self-hosted project, why would they 160 00:07:02,850 --> 00:07:03,280 even include 161 00:07:03,280 --> 00:07:07,490 the option for a server if the core mission is to be serverless? That seems a bit 162 00:07:07,490 --> 00:07:08,640 contradictory. 163 00:07:08,640 --> 00:07:13,040 It's a testament to their commitment to optionality, not necessity. It's a fine 164 00:07:13,040 --> 00:07:14,000 distinction. 165 00:07:14,000 --> 00:07:17,570 That optional server is only for fetching external credentials for better 166 00:07:17,570 --> 00:07:19,120 connectivity like, say, 167 00:07:19,120 --> 00:07:23,660 accessing premium turn servers for even better reliability. But the core 168 00:07:23,660 --> 00:07:24,400 communication works 169 00:07:24,400 --> 00:07:28,280 perfectly without it. If you don't configure that optional server, the application 170 00:07:28,280 --> 00:07:29,120 just disables the 171 00:07:29,120 --> 00:07:33,530 features that rely on it. It reinforces that the core security model requires zero 172 00:07:33,530 --> 00:07:34,480 server-side logic 173 00:07:34,480 --> 00:07:38,860 from the developers. They built an enhancement, not a dependency. That makes the 174 00:07:38,860 --> 00:07:39,360 distinction 175 00:07:39,360 --> 00:07:42,830 much clearer. Okay, so we've established security and trust, but is this just a 176 00:07:42,830 --> 00:07:44,080 basic text messenger 177 00:07:44,080 --> 00:07:48,160 for, you know, super technical people? Far from it. This is where it gets really 178 00:07:48,160 --> 00:07:48,880 practical. 179 00:07:48,880 --> 00:07:54,220 Chit Chatter supports full video and audio chatting, screen sharing, which is huge 180 00:07:54,220 --> 00:07:54,480 for 181 00:07:54,480 --> 00:07:58,890 quick IT troubleshooting, and maybe most impressively, unlimited file size 182 00:07:58,890 --> 00:07:59,760 transfers. 183 00:07:59,760 --> 00:08:04,140 Wait, hold on. Unlimited file size serverless? How does that even work without just 184 00:08:04,140 --> 00:08:04,640 bogging down 185 00:08:04,640 --> 00:08:09,280 the browser or needing some massive upload limit? It's because the transfer happens 186 00:08:09,280 --> 00:08:10,080 directly between 187 00:08:10,080 --> 00:08:15,410 the peers. The file gets encrypted using the room name as the key before it ever 188 00:08:15,410 --> 00:08:16,000 leaves your machine, 189 00:08:16,000 --> 00:08:21,520 and then it's streamed directly to the receiver. No central server ever has to ingest, 190 00:08:21,520 --> 00:08:22,000 store, 191 00:08:22,000 --> 00:08:26,640 or forward that massive file. The system also handles multiple peers limited only 192 00:08:26,640 --> 00:08:26,880 by your 193 00:08:26,880 --> 00:08:32,320 browser's capacity, and it has automatic peer verification using public key cryptography 194 00:08:32,320 --> 00:08:36,080 to confirm who you're talking to. The combination of these high fidelity features 195 00:08:36,080 --> 00:08:37,120 like video with 196 00:08:37,120 --> 00:08:40,650 the ephemerality is really fascinating. You could have a high stakes meeting, share 197 00:08:40,650 --> 00:08:41,440 a huge file, 198 00:08:41,440 --> 00:08:44,790 and then the entire transcript and the file record just vaporizes the moment you 199 00:08:44,790 --> 00:08:45,200 leave. 200 00:08:45,200 --> 00:08:49,440 It creates some really compelling use cases. The sources point to things like 201 00:08:49,440 --> 00:08:50,320 organizing groups 202 00:08:50,320 --> 00:08:55,680 think unions or political movements where historical logs are an extreme liability. 203 00:08:55,680 --> 00:09:01,020 But it's also just incredibly practical for everyday needs like securely sharing 204 00:09:01,020 --> 00:09:01,200 sensitive 205 00:09:01,200 --> 00:09:06,880 info like passwords or just moving a big chunk of text or data instantly between 206 00:09:06,880 --> 00:09:07,600 your own devices 207 00:09:07,600 --> 00:09:11,040 without relying on a cloud sync. For someone listening who's trying to navigate 208 00:09:11,040 --> 00:09:12,240 this landscape, 209 00:09:12,240 --> 00:09:16,000 how do we establish trust in software when we can't see what's under the hood? 210 00:09:16,000 --> 00:09:21,190 By making sure you can see under the hood. It's all about transparency. Chit Chatter 211 00:09:21,190 --> 00:09:21,280 is 212 00:09:21,280 --> 00:09:25,760 fully open source under the GPLv2 license. This means anyone, you, a security 213 00:09:25,760 --> 00:09:26,800 professional, 214 00:09:26,800 --> 00:09:32,140 a whole community is free and encouraged to fully audit the source code. On top of 215 00:09:32,140 --> 00:09:32,400 that, 216 00:09:32,400 --> 00:09:36,080 all the build logs for the application are publicly accessible. You aren't being 217 00:09:36,080 --> 00:09:36,240 asked 218 00:09:36,240 --> 00:09:39,520 to trust a brand, you're being asked to trust publicly verifiable code. 219 00:09:39,520 --> 00:09:43,260 So it's relying on cryptographic proof and community scrutiny, which is the 220 00:09:43,260 --> 00:09:43,600 complete 221 00:09:43,600 --> 00:09:47,200 opposite of the centralized models, just trust us approach. That's the core insight 222 00:09:47,200 --> 00:09:47,760 right there. 223 00:09:47,760 --> 00:09:51,470 Okay, let's try to synthesize all this. If you could take away just one thought 224 00:09:51,470 --> 00:09:51,680 from 225 00:09:51,680 --> 00:09:55,560 our deep dive on Chit Chatter today, what's the single biggest architectural 226 00:09:55,560 --> 00:09:56,240 takeaway? 227 00:09:56,240 --> 00:10:00,880 The biggest takeaway is that Chit Chatter minimizes third party risk down to almost 228 00:10:00,880 --> 00:10:01,280 zero. 229 00:10:01,280 --> 00:10:07,200 By combining true P2P communication, getting rid of the need for any core API 230 00:10:07,200 --> 00:10:08,000 server, 231 00:10:08,000 --> 00:10:12,380 and ensuring total ephemerality, they've created a communication tool that 232 00:10:12,380 --> 00:10:13,200 guarantees that whatever 233 00:10:13,200 --> 00:10:17,780 you say stays between you and your recipient and then it vanishes. And here's where 234 00:10:17,780 --> 00:10:18,560 the architecture 235 00:10:18,560 --> 00:10:21,980 gets really interesting though and it raises a constraint that I think you need to 236 00:10:21,980 --> 00:10:22,480 mull over. 237 00:10:22,480 --> 00:10:27,820 The self-hosting documentation specifies that Chit Chatter peer connections are 238 00:10:27,820 --> 00:10:28,080 fundamentally 239 00:10:28,080 --> 00:10:32,480 bound to the instance's domain. What that means is if you host your own customized 240 00:10:32,480 --> 00:10:33,040 version on a 241 00:10:33,040 --> 00:10:37,420 personal server, let's say securechat.local, you cannot connect to anyone who is 242 00:10:37,420 --> 00:10:38,240 using the main 243 00:10:38,240 --> 00:10:42,900 chit-chatter.iam domain. And that's a critical trade-off. It guarantees you have 244 00:10:42,900 --> 00:10:43,600 localized 245 00:10:43,600 --> 00:10:49,120 control and prevents one instance from, say, polluting another, but it also creates 246 00:10:49,120 --> 00:10:49,440 these 247 00:10:49,440 --> 00:10:54,560 isolated security islands. So while you achieve maximum self-control by self-hosting, 248 00:10:54,560 --> 00:10:55,280 it immediately 249 00:10:55,280 --> 00:10:59,200 limits the breadth and the reach of who you can talk to in that global web mesh. It 250 00:10:59,200 --> 00:10:59,440 really 251 00:10:59,440 --> 00:11:04,780 makes you wonder how much does the desire for absolute self-sovereignty end up 252 00:11:04,780 --> 00:11:05,360 limiting the 253 00:11:05,360 --> 00:11:09,760 utility of a global peer-to-peer connection. Indeed. It's a fundamental tension 254 00:11:09,760 --> 00:11:10,160 between 255 00:11:10,160 --> 00:11:14,560 trust and reach. Thanks for joining us for this deep dive into secure decentralized 256 00:11:14,560 --> 00:11:15,360 communication. 257 00:11:15,360 --> 00:11:19,120 Thank you. And a huge thank you once again to our supporter, SafeServer. SafeServer 258 00:11:19,120 --> 00:11:19,520 supports the 259 00:11:19,520 --> 00:11:23,600 hosting of this software and assists in digital transformation. Find out more at 260 00:11:23,600 --> 00:11:26,080 www.safeserver.de. 261 00:11:26,080 --> 00:11:27,840 We will catch you on the next deep dive.