WEBVTT 00:00.000 --> 00:10.400 All right, our next speaker, who Kuri is going to give us a talk, he's a 25-year 00:10.400 --> 00:13.560 fast veteran, or actually, no, sorry. 00:13.560 --> 00:19.320 He's going to be giving us a technical overview of Delta Chat's shift to multi-relay architecture 00:19.320 --> 00:24.280 where user identity is purely cryptographic, device-based, and messages are routed via the 00:24.280 --> 00:27.280 decentralized chat mail relay network. 00:27.280 --> 00:29.520 So he's going to go ahead and give us a presentation right now. 00:29.520 --> 00:30.520 Thank you. 00:30.520 --> 00:36.520 Can we welcome him? 00:36.520 --> 00:40.520 Yeah, so can you hear me? 00:40.520 --> 00:41.520 Everyone? 00:41.520 --> 00:42.520 Yes. 00:42.520 --> 00:52.960 So, yeah, as you said, I'm Hukuri, instead of Misitek, because Misitek is ill, and I'm one of the developers 00:52.960 --> 01:01.240 of the Chat mail call library, and which is used by other different Chatmail clients and 01:01.240 --> 01:07.280 handles the networking and the encryption. 01:07.280 --> 01:15.800 And yeah, I have a talk with a very long name, and basically it's about how to make decentralization 01:15.800 --> 01:21.600 resilient in the case of server failures. 01:21.600 --> 01:27.560 So, first of all, the problem statement, I mean, all of you know about the problems with 01:27.560 --> 01:34.280 centralized services, that's a good centralized service, but then the apps identified in 01:34.280 --> 01:40.560 order to extract my profit, but it's hard to leave, because you would lose your social 01:40.560 --> 01:48.040 graph and data, and you can still use it, but many people then continue to use it, 01:48.040 --> 01:51.080 but it's annoying. 01:51.080 --> 01:58.360 And there are different flash services, where you can choose your server, but maybe the 01:58.360 --> 02:06.760 admin bands out, maybe the admin just has other life priorities, and then you again lose 02:06.760 --> 02:12.080 your social graph and data, so whom in the room has the second term? 02:12.080 --> 02:21.000 Yeah, some, so here, the root of the problem is that you're 02:21.560 --> 02:28.920 an identity is tied to the server, so the server provides your identity and here, user 02:28.920 --> 02:41.440 handle is username at server name, so yeah, your identity is tied to a particular server. 02:41.440 --> 02:50.000 And that's what we want to get rid of, so we want to have your identity tied to cryptographic 02:50.080 --> 02:58.520 identities instead, but exactly this means I will explain data, but first, what, like the 02:58.520 --> 03:05.440 goal we are working towards is you can use not just one server, but multiple servers, 03:05.440 --> 03:12.520 and if one of them goes down, two of them go down, then it doesn't matter, because your 03:12.600 --> 03:21.640 social graph can use other servers to root around the failure, and everything just continues 03:21.640 --> 03:34.480 to work normally, yes friends don't even notice that you switch to us, so now before I explain 03:34.560 --> 03:41.200 how this is done, first for some background about the chat mail, we'll end it back, 03:41.200 --> 03:47.600 but I forgot to explain, so in case you don't know, I'm data chat is, and to end encrypted 03:48.320 --> 03:54.000 messaging app, and chat mail is the network similar to the distinction between 03:54.960 --> 04:06.960 element and matrix, so yes, you have the chat mail relay network, and we don't call the, like, we call 04:06.960 --> 04:16.240 the servers release, because they don't store messages for you, they only want to deliver your messages 04:17.200 --> 04:24.240 there for release, in the background, like, technical level, it uses email protocols as 04:24.240 --> 04:35.120 MTP and IMAP to deliver the messages, and but you, as a user, you don't need to know about 04:35.120 --> 04:41.840 this email, like, about this connection to email in any way, until some years ago, we 04:41.920 --> 04:50.480 tried to make data chat a bit more, like, usable as an email client, but this is where mainly 04:50.480 --> 04:58.960 focusing on making data chat messenger, yeah, so on the servers, you don't have any 04:59.040 --> 05:08.720 plain text, content, or account management, or permanent set, therefore, there is no account, 05:08.720 --> 05:16.960 the server doesn't need to remember your account, and because the server can be so done, 05:17.760 --> 05:24.800 it's enough to have a TPS or Raspberry Pi to host thousands of addresses, and we have around 05:24.880 --> 05:34.000 a hundred to 300 running chat mail relay spanner. Now, another quick aside about 05:35.360 --> 05:44.800 I do you need to trust the relay you're choosing, and the answer is now, so you have the SMTP 05:44.800 --> 05:56.640 from and to, which is seen by the relay, but it's just random, randomly chosen address, 05:56.640 --> 06:02.960 it's nothing, user-identifiable, and then you have the mind message, but it's also just, 06:04.320 --> 06:09.440 you have, again, the from address, and you have a date, but it's actually randomized to 06:09.520 --> 06:15.360 sometimes within the last seven days, and you have some references to other managers, but we actually 06:15.360 --> 06:21.280 want to get rid of this, and yeah, as you can see, the address is just random string. 06:23.520 --> 06:34.560 So finally, how do we manage this, how do we do this on a technical level that you can use 06:34.560 --> 06:43.600 multiple relays? So we prepared a plan out of fast stages, and because we are software developers, 06:43.600 --> 06:52.560 of course, we started counting at zero, and the stage zero, and was that we distinguish 06:52.560 --> 07:01.520 context not by the address, but by the public keyfinger print, and the public keyfinger print is 07:01.520 --> 07:08.720 something like the private key, it's something you have on your private device, and which you 07:08.720 --> 07:15.280 can transfer between devices, and which is really yours, so the public keyfinger print, 07:15.280 --> 07:22.240 identifying you by the public keyfinger print means that you host your on identity on your devices 07:22.320 --> 07:34.320 rather than your server, and then if our contact of mine sends me a message from a different address, 07:34.320 --> 07:43.280 then I will just see it as the same contact, and in the user interface there won't be any difference, 07:44.000 --> 07:51.680 because yeah, it's identified by the public keyfinger print, and as long as this is the same, 07:51.760 --> 08:01.280 it's the same contact as viewed by the client, and this is really the main, 08:04.560 --> 08:14.400 the main difference, the main idea behind multi relay, so then stage one, which is where we are 08:14.480 --> 08:21.120 right now, yes, you can actually have not just one relay, but three, and listen on all of them, 08:22.400 --> 08:30.240 and then if a method arrives on either of the relays, it will arrive just fine, 08:31.280 --> 08:39.440 and you need to choose one of them as your sending address, and then your contact will answer 08:39.440 --> 08:44.800 with the same route as you are sending the messages to them, so if you're changing your sending 08:44.800 --> 08:50.640 address, your contacts will automatically answer to the same sending address again, 08:52.480 --> 09:01.760 and even if you didn't have multiple relays set up yet, and your relay dies, you can just 09:01.760 --> 09:10.720 set up another relay, and then you send a message to your contacts, and then the contacts here, 09:10.720 --> 09:19.680 okay, now apparently you have a new address, let's send to this address, but this only works 09:19.680 --> 09:24.880 if you are on different relays, but if because of everyone is on the same relay, and it goes down, 09:24.880 --> 09:31.920 then you don't know your contacts here addresses, and your contacts don't know your new addresses, 09:31.920 --> 09:38.560 so you can't find each other anymore, which is why next comes stage two, which we have not 09:38.560 --> 09:46.880 implemented yet, where you communicate all of your listening addresses in your public key, 09:47.440 --> 09:58.880 so you contact see which listening addresses you have, and they just send all the messages 09:58.880 --> 10:06.640 to all of your addresses, just in case, so that if either of your addresses fails, 10:08.320 --> 10:13.920 you can your messages will just arrive on the other, via the other relays, 10:14.880 --> 10:24.160 and then your client will, as long as multiple of your relays are on land, your client will notice 10:24.160 --> 10:31.360 that messages arrive, that the same message arrived via multiple relays, and will only download 10:31.360 --> 10:41.600 it once in order to avoid wasting a lot of data traffic, and the good thing, the nice thing about 10:41.680 --> 10:47.520 distributing the addresses in the public key is that it's actually signed by a private key, 10:47.520 --> 10:53.760 which addresses you are using, so your contacts can even gossip your addresses 10:53.760 --> 11:03.280 among each other if you have a group, and one of the people in the group knows that you have 11:03.680 --> 11:10.960 a new listening address, and if you are also in the group, and this contact sends a message 11:10.960 --> 11:17.520 into the group, then your listening addresses will actually be gossiped to all the members in the group 11:17.520 --> 11:24.880 in order to guarantee a quick distribution of listening addresses, but you still need to 11:25.440 --> 11:32.320 use the internet manual user interactions, so you still need to switch a set, which address 11:32.320 --> 11:42.800 you are sending from manually, which is why there will be a set 3, where if you are a client 11:42.800 --> 11:51.440 consent from one of the addresses, then the app will just automatically fail over to a different 11:51.440 --> 12:01.200 address seamlessly, and therefore users won't even notice if a relay fails, everything will just 12:01.200 --> 12:12.960 continue to work without the user noticing any degradation in the service, so much for the user 12:12.960 --> 12:21.200 set, but it's also very interesting for the side of the relay operators, because this makes it 12:21.200 --> 12:29.760 very easy and very low pressure to host a relay, so you are users don't depend on you anymore 12:29.760 --> 12:36.400 as a relay operator, because if in three years you decide sorry I have other life priorities now, 12:36.720 --> 12:43.360 I can't host this relay anymore, then your users can just use one of the other relays, 12:45.120 --> 12:54.720 you have the right for exit for both users and for administrators, which is also a major feature 12:54.720 --> 13:03.680 to getting other people to agree to host some of these relays, and therefore to achieve 13:03.840 --> 13:13.680 more decentralization in the chat mail ecosystem, and as I said, there is rarely an 13:13.680 --> 13:22.960 clear text content, no content at all, and rarely any clear text data on the relay, so there's 13:22.960 --> 13:30.960 very low legal risk of having anything illegal on your relay, and it's very low cost as I said, 13:30.960 --> 13:39.120 and here we have a poll among chat mail operator chat, how many hours they spend per month, 13:39.120 --> 13:48.000 and as you can see 80% are voted that they spend less than two hours per month, and the other 13:48.000 --> 13:55.600 was actually voted that they spend zero hours per month, so it's very easy to host these relays. 13:55.920 --> 14:07.760 Then, finally, so what can you do? Can you contribute, you can say first relay, 14:08.400 --> 14:14.400 and you can also contribute to the chat mail ecosystem, you can write alternative UIs, you can write 14:14.400 --> 14:24.160 words, you can write apps that run inside data chat, and of course you can spread the word about 14:24.160 --> 14:32.560 data chat, and here we have two links, the first one to the chat mail website, and the second one 14:32.560 --> 14:42.880 is a collection to link about everything in the data chat. So that was that, and now you may ask 14:42.880 --> 14:52.000 questions. All right, we actually have a pretty good amount of time for questions, so feel 14:52.000 --> 15:00.800 free to keep them coming. I saw a hand up there. Okay, come on. 15:01.200 --> 15:14.320 Huh? So my account will be my public key essentially, or yeah, write my by key, and 15:15.200 --> 15:22.240 the endpoint of communication will still be an email address that I can then, I register with a 15:22.240 --> 15:28.160 different relay, get a new email address, and add that to my public key, and then people will find me, 15:28.160 --> 15:35.760 or, I mean, the endpoint is still an email address, right? I mean, it's still using SMTP and 15:35.760 --> 15:42.480 I'm at protocols, like the same protocols as used by email for method delivery, and you can 15:42.480 --> 15:51.040 can also set a use classical email account as a transport relay, a few wunter, and can you set 15:51.040 --> 15:58.880 the question? My question would be, so if I use these pure chat mail things, email addresses are 15:58.880 --> 16:04.800 still my final destination where my message is arrived, but they become less important, 16:04.800 --> 16:07.600 they become invisible. Exactly. Okay. 16:11.920 --> 16:18.000 Yeah, you can already, like I'm already with the state run, which we already have, you can in the 16:18.560 --> 16:26.080 delta chat client, or in alternative chat mail clients, like I can chat, you can change, which 16:26.880 --> 16:32.800 address should be used as your transport. You can add multiple, another transport, and change 16:32.800 --> 16:40.320 with run, you're using for sending. Cool. Thanks for the presentation and the work. Two questions, 16:40.320 --> 16:46.800 when, so in the scenario of like faulty network conditions, and a message is sent to multiple, 16:47.200 --> 16:54.320 listening addresses, and eventually arrives at the client. Do the messages stay living in the relay, 16:54.320 --> 17:01.280 or is there some way the client says, oh, I don't need those are the messages anymore, or how is this 17:01.280 --> 17:10.240 handled? Is that clear? I mean, so, messages will anyways be deleted after some time, if you have 17:10.240 --> 17:16.480 just one device, then this one device will delete them immediately, and if you have multiple 17:16.560 --> 17:23.680 devices, then it depends on the configuration of the relay, how long messages are kept. I 17:23.680 --> 17:31.600 guess that might be an optimization for the client to delete messages from all, but one relay, 17:31.600 --> 17:39.040 even if you have multi-transport, but there are no complete plans to do so yet, because the 17:39.200 --> 17:49.680 relay can just be configured to delete all the messages that are to all it. Yeah, great. Thanks. 17:49.680 --> 17:56.080 And yeah, I just be curious how you're, you spoke about these phases, and then the core, 17:56.080 --> 18:00.800 supporting new features, and then this arriving in the relay, and I'm just worried curious how 18:00.800 --> 18:08.560 you're coordinating this with the relay operators, or yeah, how are you doing this just socially, 18:09.440 --> 18:16.800 so, thanks. So, the cool thing is that there are no changes at all required on the relay side. 18:18.400 --> 18:25.760 The relay is addressed, and have already been, before all of this, very dumb story and forward 18:25.840 --> 18:36.560 relays, so that the relays don't need to know about any of this, and among the different clients 18:36.560 --> 18:44.400 for chat mail, what we have, as we have one, this one chat mail call library, which as I said, 18:44.400 --> 18:52.800 handles the encryption and the networking and so on, and this one library is used by all the 18:52.880 --> 19:00.480 you eyes and all the bots, and just all the chat mail clients, and this made it very easy to implement 19:00.480 --> 19:07.200 this quite big change, and just one library, and then everyone else just needed to update this library. 19:11.440 --> 19:20.080 So, this is a question more generally about chat mail and delta chat. So, last I looked, 19:20.080 --> 19:27.680 you guys don't have forward secrecy or deniability yet, what are your plans for fixing that, 19:27.680 --> 19:33.520 because both of those have been around in the crypto ecosystem, even OTR had this 20 years ago, 19:33.520 --> 19:40.560 whatever, they seem kind of important features to have. They actually was a talk yesterday about 19:40.640 --> 19:51.520 how we are going to implement this, which will be specified in the OTR Crypt 2 protocol, 19:51.520 --> 19:54.720 and then implemented within the next year. 19:58.240 --> 20:03.040 Okay, does that cover both forward secrecy and deniability? 20:03.680 --> 20:05.120 No, only forward secrecy. 20:05.120 --> 20:07.920 Okay, so what about deniability? That's pretty important, too. 20:08.880 --> 20:15.680 There are no concrete plans to support deniability, and honestly, it's not, 20:15.680 --> 20:26.000 so in situations where deniability could actually have helped, it has never really been the case 20:26.000 --> 20:33.840 that it actually had because in front of courts usually, especially in dictatorships, but also 20:33.840 --> 20:39.840 in democracy, it has been rarely ever been accepted. 20:39.840 --> 20:44.560 Here's a situation where it would have helped. Hillary Clinton would have loved to be able to deny 20:44.560 --> 20:49.920 that her email zone would use e-leaks or authentic. This is actually a fairly common scenario, 20:49.920 --> 20:52.000 is there? Email scale it. 20:52.000 --> 20:57.440 I'm really not sure whether it would have worked, because then she would have 20:57.440 --> 21:03.600 still needed to say no, all of these are not authentic, but I mean, Hillary's campaign tried to 21:03.600 --> 21:09.520 say that they were faked, and then the decimcing ensures end up screwing her when she said that. 21:10.080 --> 21:17.360 Okay, I mean, I don't know about this specific case. I do know about some papers on usable security, 21:17.360 --> 21:25.520 when it was actually researched how a messengers would do have deniability, sorry, 21:25.600 --> 21:36.800 floodability, how they have, how this works in practice, and it turned out that it did not 21:36.800 --> 21:42.800 really help for multiple reasons, also because users just did not expect this feature to be there, 21:43.360 --> 21:48.480 and then you need to teach all users, which apparently didn't work, because users of signal, 21:48.480 --> 21:55.040 most users of signal apparently don't know about it, and then the expectation about what the 21:55.120 --> 22:04.720 messenger does, deviates from reality, and also that screenshots are just usually accepted as a proof, 22:04.720 --> 22:09.120 and then you can still try, but yeah, it doesn't help. 22:12.160 --> 22:18.320 Okay, but Hillary's campaign clearly was not expecting decimcing to wind up making all of their 22:18.320 --> 22:23.600 messages non-reviewable. As users, they clearly expected the opposite of what you're describing. 22:23.760 --> 22:32.400 Okay, I don't know about Hillary's campaign, and I can't comment anything about this, 22:32.400 --> 22:33.920 maybe it would have happened in this case. 22:36.240 --> 22:38.000 All right, do it. Okay, so I'm down here. 22:40.880 --> 22:44.560 With time for maybe one, possibly two more questions, but I don't like this one. 22:47.200 --> 22:50.720 Thank you. The question is about a running car relay. 22:51.680 --> 22:59.120 You are using standard email tools, which require, I assume, standard products, 22:59.120 --> 23:07.680 standard ports, and some of the providers would block those, and for being scared of spam. 23:08.480 --> 23:13.360 Did you encounter something like that when someone is trying to write it in a relay, 23:13.360 --> 23:17.920 but the traffic will be blocked, because it will be suspicious of spam or something like that, 23:18.000 --> 23:19.680 or this doesn't happen. 23:21.280 --> 23:28.400 So we did have problems with email paths being blocked in some cases, and yeah, we do have plans 23:28.400 --> 23:35.600 to make more things work via HTTP instead. What you can do is, I think, I'm not, that's not my 23:36.160 --> 23:45.280 expert area, but I think you can put reverse, like a proxy in front of your relay, and then people 23:45.280 --> 23:53.840 can use this HTTP proxy to reach your server, but yeah, there are more plans to make these things more 23:53.840 --> 23:58.880 reliable. All right, and now there's some more questions coming up, but we are ready to close now. 23:58.880 --> 24:02.080 So let's get one more round of applause and feel free to grab me if you do afterwards. 24:03.440 --> 24:05.680 Thank you very much. I appreciate your time.