All right, our next speaker, who Kuri is going to give us a talk, he's a 25-year
fast veteran, or actually, no, sorry.
He's going to be giving us a technical overview of Delta Chat's shift to multi-relay architecture
where user identity is purely cryptographic, device-based, and messages are routed via the
decentralized chat mail relay network.
So he's going to go ahead and give us a presentation right now.
Thank you.
Can we welcome him?
Yeah, so can you hear me?
Everyone?
Yes.
So, yeah, as you said, I'm Hukuri, instead of Misitek, because Misitek is ill, and I'm one of the developers
of the Chat mail call library, and which is used by other different Chatmail clients and
handles the networking and the encryption.
And yeah, I have a talk with a very long name, and basically it's about how to make decentralization
resilient in the case of server failures.
So, first of all, the problem statement, I mean, all of you know about the problems with
centralized services, that's a good centralized service, but then the apps identified in
order to extract my profit, but it's hard to leave, because you would lose your social
graph and data, and you can still use it, but many people then continue to use it,
but it's annoying.
And there are different flash services, where you can choose your server, but maybe the
admin bands out, maybe the admin just has other life priorities, and then you again lose
your social graph and data, so whom in the room has the second term?
Yeah, some, so here, the root of the problem is that you're
an identity is tied to the server, so the server provides your identity and here, user
handle is username at server name, so yeah, your identity is tied to a particular server.
And that's what we want to get rid of, so we want to have your identity tied to cryptographic
identities instead, but exactly this means I will explain data, but first, what, like the
goal we are working towards is you can use not just one server, but multiple servers,
and if one of them goes down, two of them go down, then it doesn't matter, because your
social graph can use other servers to root around the failure, and everything just continues
to work normally, yes friends don't even notice that you switch to us, so now before I explain
how this is done, first for some background about the chat mail, we'll end it back,
but I forgot to explain, so in case you don't know, I'm data chat is, and to end encrypted
messaging app, and chat mail is the network similar to the distinction between
element and matrix, so yes, you have the chat mail relay network, and we don't call the, like, we call
the servers release, because they don't store messages for you, they only want to deliver your messages
there for release, in the background, like, technical level, it uses email protocols as
MTP and IMAP to deliver the messages, and but you, as a user, you don't need to know about
this email, like, about this connection to email in any way, until some years ago, we
tried to make data chat a bit more, like, usable as an email client, but this is where mainly
focusing on making data chat messenger, yeah, so on the servers, you don't have any
plain text, content, or account management, or permanent set, therefore, there is no account,
the server doesn't need to remember your account, and because the server can be so done,
it's enough to have a TPS or Raspberry Pi to host thousands of addresses, and we have around
a hundred to 300 running chat mail relay spanner. Now, another quick aside about
I do you need to trust the relay you're choosing, and the answer is now, so you have the SMTP
from and to, which is seen by the relay, but it's just random, randomly chosen address,
it's nothing, user-identifiable, and then you have the mind message, but it's also just,
you have, again, the from address, and you have a date, but it's actually randomized to
sometimes within the last seven days, and you have some references to other managers, but we actually
want to get rid of this, and yeah, as you can see, the address is just random string.
So finally, how do we manage this, how do we do this on a technical level that you can use
multiple relays? So we prepared a plan out of fast stages, and because we are software developers,
of course, we started counting at zero, and the stage zero, and was that we distinguish
context not by the address, but by the public keyfinger print, and the public keyfinger print is
something like the private key, it's something you have on your private device, and which you
can transfer between devices, and which is really yours, so the public keyfinger print,
identifying you by the public keyfinger print means that you host your on identity on your devices
rather than your server, and then if our contact of mine sends me a message from a different address,
then I will just see it as the same contact, and in the user interface there won't be any difference,
because yeah, it's identified by the public keyfinger print, and as long as this is the same,
it's the same contact as viewed by the client, and this is really the main,
the main difference, the main idea behind multi relay, so then stage one, which is where we are
right now, yes, you can actually have not just one relay, but three, and listen on all of them,
and then if a method arrives on either of the relays, it will arrive just fine,
and you need to choose one of them as your sending address, and then your contact will answer
with the same route as you are sending the messages to them, so if you're changing your sending
address, your contacts will automatically answer to the same sending address again,
and even if you didn't have multiple relays set up yet, and your relay dies, you can just
set up another relay, and then you send a message to your contacts, and then the contacts here,
okay, now apparently you have a new address, let's send to this address, but this only works
if you are on different relays, but if because of everyone is on the same relay, and it goes down,
then you don't know your contacts here addresses, and your contacts don't know your new addresses,
so you can't find each other anymore, which is why next comes stage two, which we have not
implemented yet, where you communicate all of your listening addresses in your public key,
so you contact see which listening addresses you have, and they just send all the messages
to all of your addresses, just in case, so that if either of your addresses fails,
you can your messages will just arrive on the other, via the other relays,
and then your client will, as long as multiple of your relays are on land, your client will notice
that messages arrive, that the same message arrived via multiple relays, and will only download
it once in order to avoid wasting a lot of data traffic, and the good thing, the nice thing about
distributing the addresses in the public key is that it's actually signed by a private key,
which addresses you are using, so your contacts can even gossip your addresses
among each other if you have a group, and one of the people in the group knows that you have
a new listening address, and if you are also in the group, and this contact sends a message
into the group, then your listening addresses will actually be gossiped to all the members in the group
in order to guarantee a quick distribution of listening addresses, but you still need to
use the internet manual user interactions, so you still need to switch a set, which address
you are sending from manually, which is why there will be a set 3, where if you are a client
consent from one of the addresses, then the app will just automatically fail over to a different
address seamlessly, and therefore users won't even notice if a relay fails, everything will just
continue to work without the user noticing any degradation in the service, so much for the user
set, but it's also very interesting for the side of the relay operators, because this makes it
very easy and very low pressure to host a relay, so you are users don't depend on you anymore
as a relay operator, because if in three years you decide sorry I have other life priorities now,
I can't host this relay anymore, then your users can just use one of the other relays,
you have the right for exit for both users and for administrators, which is also a major feature
to getting other people to agree to host some of these relays, and therefore to achieve
more decentralization in the chat mail ecosystem, and as I said, there is rarely an
clear text content, no content at all, and rarely any clear text data on the relay, so there's
very low legal risk of having anything illegal on your relay, and it's very low cost as I said,
and here we have a poll among chat mail operator chat, how many hours they spend per month,
and as you can see 80% are voted that they spend less than two hours per month, and the other
was actually voted that they spend zero hours per month, so it's very easy to host these relays.
Then, finally, so what can you do? Can you contribute, you can say first relay,
and you can also contribute to the chat mail ecosystem, you can write alternative UIs, you can write
words, you can write apps that run inside data chat, and of course you can spread the word about
data chat, and here we have two links, the first one to the chat mail website, and the second one
is a collection to link about everything in the data chat. So that was that, and now you may ask
questions. All right, we actually have a pretty good amount of time for questions, so feel
free to keep them coming. I saw a hand up there. Okay, come on.
Huh? So my account will be my public key essentially, or yeah, write my by key, and
the endpoint of communication will still be an email address that I can then, I register with a
different relay, get a new email address, and add that to my public key, and then people will find me,
or, I mean, the endpoint is still an email address, right? I mean, it's still using SMTP and
I'm at protocols, like the same protocols as used by email for method delivery, and you can
can also set a use classical email account as a transport relay, a few wunter, and can you set
the question? My question would be, so if I use these pure chat mail things, email addresses are
still my final destination where my message is arrived, but they become less important,
they become invisible. Exactly. Okay.
Yeah, you can already, like I'm already with the state run, which we already have, you can in the
delta chat client, or in alternative chat mail clients, like I can chat, you can change, which
address should be used as your transport. You can add multiple, another transport, and change
with run, you're using for sending. Cool. Thanks for the presentation and the work. Two questions,
when, so in the scenario of like faulty network conditions, and a message is sent to multiple,
listening addresses, and eventually arrives at the client. Do the messages stay living in the relay,
or is there some way the client says, oh, I don't need those are the messages anymore, or how is this
handled? Is that clear? I mean, so, messages will anyways be deleted after some time, if you have
just one device, then this one device will delete them immediately, and if you have multiple
devices, then it depends on the configuration of the relay, how long messages are kept. I
guess that might be an optimization for the client to delete messages from all, but one relay,
even if you have multi-transport, but there are no complete plans to do so yet, because the
relay can just be configured to delete all the messages that are to all it. Yeah, great. Thanks.
And yeah, I just be curious how you're, you spoke about these phases, and then the core,
supporting new features, and then this arriving in the relay, and I'm just worried curious how
you're coordinating this with the relay operators, or yeah, how are you doing this just socially,
so, thanks. So, the cool thing is that there are no changes at all required on the relay side.
The relay is addressed, and have already been, before all of this, very dumb story and forward
relays, so that the relays don't need to know about any of this, and among the different clients
for chat mail, what we have, as we have one, this one chat mail call library, which as I said,
handles the encryption and the networking and so on, and this one library is used by all the
you eyes and all the bots, and just all the chat mail clients, and this made it very easy to implement
this quite big change, and just one library, and then everyone else just needed to update this library.
So, this is a question more generally about chat mail and delta chat. So, last I looked,
you guys don't have forward secrecy or deniability yet, what are your plans for fixing that,
because both of those have been around in the crypto ecosystem, even OTR had this 20 years ago,
whatever, they seem kind of important features to have. They actually was a talk yesterday about
how we are going to implement this, which will be specified in the OTR Crypt 2 protocol,
and then implemented within the next year.
Okay, does that cover both forward secrecy and deniability?
No, only forward secrecy.
Okay, so what about deniability? That's pretty important, too.
There are no concrete plans to support deniability, and honestly, it's not,
so in situations where deniability could actually have helped, it has never really been the case
that it actually had because in front of courts usually, especially in dictatorships, but also
in democracy, it has been rarely ever been accepted.
Here's a situation where it would have helped. Hillary Clinton would have loved to be able to deny
that her email zone would use e-leaks or authentic. This is actually a fairly common scenario,
is there? Email scale it.
I'm really not sure whether it would have worked, because then she would have
still needed to say no, all of these are not authentic, but I mean, Hillary's campaign tried to
say that they were faked, and then the decimcing ensures end up screwing her when she said that.
Okay, I mean, I don't know about this specific case. I do know about some papers on usable security,
when it was actually researched how a messengers would do have deniability, sorry,
floodability, how they have, how this works in practice, and it turned out that it did not
really help for multiple reasons, also because users just did not expect this feature to be there,
and then you need to teach all users, which apparently didn't work, because users of signal,
most users of signal apparently don't know about it, and then the expectation about what the
messenger does, deviates from reality, and also that screenshots are just usually accepted as a proof,
and then you can still try, but yeah, it doesn't help.
Okay, but Hillary's campaign clearly was not expecting decimcing to wind up making all of their
messages non-reviewable. As users, they clearly expected the opposite of what you're describing.
Okay, I don't know about Hillary's campaign, and I can't comment anything about this,
maybe it would have happened in this case.
All right, do it. Okay, so I'm down here.
With time for maybe one, possibly two more questions, but I don't like this one.
Thank you. The question is about a running car relay.
You are using standard email tools, which require, I assume, standard products,
standard ports, and some of the providers would block those, and for being scared of spam.
Did you encounter something like that when someone is trying to write it in a relay,
but the traffic will be blocked, because it will be suspicious of spam or something like that,
or this doesn't happen.
So we did have problems with email paths being blocked in some cases, and yeah, we do have plans
to make more things work via HTTP instead. What you can do is, I think, I'm not, that's not my
expert area, but I think you can put reverse, like a proxy in front of your relay, and then people
can use this HTTP proxy to reach your server, but yeah, there are more plans to make these things more
reliable. All right, and now there's some more questions coming up, but we are ready to close now.
So let's get one more round of applause and feel free to grab me if you do afterwards.
Thank you very much. I appreciate your time.