Thanks for your attention.
Hi, I'm Missy Take, for NAMI.
I use state-end pronouns, and I want to talk to you about a bit about the server side of things now.
We just heard a lot about what the DeltaChart line is doing.
So I'm also from DeltaChart team, but technically, this is now about chat mail, which is a separate project,
which we are also doing, oh sorry, I got the logo wrong actually.
So chat mail is not an open-source project.
It gets up on the DeltaChart's chat mail.
It's easy to find.
But why do we actually do this?
Because actually it's not that it's an email client, right?
We already worked with basically any SMTP and I'm a server.
So why actually focus on the chat mail server?
We had a lot of reasons, which basically, yeah, make it more useful at some point to think about, okay?
But how can you optimize a meta server so it works for chatting?
One big problem, the app, for example, is there's this unique expectation.
People install our app, and then we ask them to, for an email in the passwords,
and then people think like, ham, and you already an app.
Why do I need to give you my email password actually?
Like, what password should I enter here now?
And it was very confusing actually.
And then again, it's also, do we even want users to have to memorize passwords?
In many ways, that's super inconvenient.
password managers are not very widespread after all.
So actually, you are just onboarded right with the QR codes,
or maybe just by clicking on create new profile.
Yeah, you didn't actually have to choose the password.
You didn't have to remember one.
There was one generated actually because it is an email account after all.
But also you exercise.
We don't really want users to have to border with that.
And when they migrate to a different device,
then they basically have to export a backup imported to the new device.
But it will work without actually logging in somewhere.
But it's rather file based and access to the device based.
And you have also didn't like that.
You need to give personal data for registration.
We don't like the rate limits many servers have,
because chatting is fast.
And especially if you have a web XEC app where people
edits like in some editor files together,
like that, of course, causes a lot of emails,
which transmit the data to each other.
Or if it's up, we are annoying.
And of course, we also had a long standing grudge
on the centralization of the email system.
So we wanted to make that different too.
And really focus on how can we further decentralize
what is currently more centralized than it has used to be.
Yeah.
So basically, chat mail is a special kind of email server set
with some configuration.
And the main thing why we did it in the beginning
was we wanted an open sign-up server,
we don't need to give any personal data to just get an account
and start chatting.
Because, yeah, if you click in the app,
create and you profile choose a name,
agree and create, something you have an account.
Like that's all you need to do.
That was the goal here.
But then again, we didn't want to become
the next matrix.org.
You maybe you know the login flow of matrix,
element, for example, everyone in the end is on matrix.org.
That's awesome of what we wanted.
So from the beginning focused on,
okay, how can we make this decentralized as possible?
So right now, we have this one main server where you onboard
when you just click, agree and create,
and don't go through the hazard of
cleaning one of these QR codes,
or clicking on use other server and trying to find another server.
You go there at some point.
But yeah, for that, at the moment,
we are building up a decentralized chat mail server network.
And yeah, the main way to do that is to make
email hosting as easy as possible again.
When I started doing sysatman stuff,
I basically told all of this myself about having
a professional education or so,
yeah, people told me don't ever do mayservas.
You probably heard of that notion as well, right?
So yeah, we want to have a mayserver
which you can tell your teacher children how to do sysatman.
And yeah, it's quite easy.
Basically, you clone our repository.
It comes up a small command line tool.
You can use the init command to generate
a config file.
You can use the run command to then run a set-up script.
And which already you just set up the server.
And maybe you know the pioneer who knows
Pian for here?
Okay, who knows Ansible?
Yeah.
Ansible is Pian for just with the demo files.
Pian for as Ansible with Python files instead of the demo files.
It's amazing.
You can do all your comfort logic in Python instead of this
Yamil shit.
You can use Python libraries in your deployments stuff.
It's really great.
I will not go into this here, but check it out.
And yeah, we are basically hiding a Pian for script
inside the CM deploy run command.
Yeah, and we have a script which generates all the DNS records you need.
I mean, that's one of the big pains for many mail
admins or know how does this decim stuff work again.
Or how do I set my SPF record properly?
Like this command just gives you a phone file output
which you can copy paste.
Either in some weapon interface or really
as a phone file you just uploaded.
Yeah, that's, you know the first project which did that,
but I think it may serve a project nowadays.
Really needs to do this because otherwise you will never get people
to just start with this.
Yeah, and then we have because our setup is also very tested with
Python tests for everything and you can just run the
deploy test to verify that everything works.
We also use that for developing for our CI.
So yeah, I think it's as painless as it can get.
And if you find a way to make it more painless,
please open an issue.
That would be great.
It's also customizable in many ways.
If you don't like what we use for our main instance,
then it's not so hard.
It's basically using post-fix and softcard because of course
and open decim,
acmetool and angenex.
So it actually comes with its own kind of auto-generated website
which you can edit and mark down also.
And if you check out some of those other providers
which we put on the handout, they all made some edits,
like someone translated it to Italian,
someone else put a warning against fascists on their website,
stuff like that.
So it's really customizable there.
And yeah, we have this Python for a base clip,
for sending it up and upgrading.
And right now it's Python for base,
but also some people in the community are working on
Chef, Docker, and Ansible setups.
That's not something we're interested in very much right now,
personally, but it would be great, of course,
if people do that.
We don't really have an expertise in these setups.
So if you want to work on that,
yeah, you're invited.
And yeah, and right now we have around a dozen
chat main servers out there, a bit more I think.
We have some announced on this website on our website.
And for example, those on the handout are mostly there,
I think I put one there which isn't publicly advertised,
there's also something to do with censorship.
And because, yeah, authoritarian regimes want to,
yeah, want to block these things.
And so it's always good to have some service out there,
which are not public.
Let's read the kind of views.
Yeah, basically one other thing that was very important for us,
because one of the big problems of our time next to
billionaires and authoritarian regimes is the climate catastrophe.
So we want to be introduced as minimal resources as possible.
And yeah, a recipe or the cheapest VPS you can find,
is totally enough to support hundreds of users, maybe thousands.
And also, it's actually not so much an email server as you know it,
because we don't actually store the messages.
We are not a long time storage provider,
which many messages have to be.
That's what works like that.
That basically, to download the message and then
stay on the device, and the lesions are not necessarily synced
between devices.
So you can have like four gigabyte mailbox on your phone,
but I have just a hundred megabyte mailbox on the server.
And it basically deletes the message as soon as it downloads it,
except if you have a multi device set up,
then it needs to be on the server a bit longer.
So the other devices has a heavy chance of downloading it.
But we delete every message after like 30 days, I think.
Unconditionally, what it was, you know, not.
It's really more an email router than an email server.
Yeah, and the other nice thing about having a very minimal state,
goes through like state, right?
Basically, we do the open sign-up in a way
that the login request.
When you login in the account doesn't exist yet,
the account is created instead of the same password you used for logging in.
So actually, if you delete an account server side,
you cause maybe like you accidentally do an RM-RF slash or whatever,
and you just run CMD Cloud Run again and set up the server again,
the next second GF of the user logs in again,
the account is recreated, and nothing is lost.
So actually for months, for our main instance,
the tens of thousands of users, we didn't have a backup.
Now, we do for by not, but in general, you actually,
you don't really need to keep state,
and this is all designed to make the minds of elements very free of worry.
And yeah, to let children play with the stuff, basically.
Okay, I'm going to bit more into some details,
because you're probably already thought,
oh, what they are running an open sign up,
it may serve out there in the wild.
What about them?
I guess many of you do with spam on a daily basis,
and are quite annoyed by it.
We're taking a quite radical approach with it.
We basically have no inbound spam filtering.
It's not really necessary.
None of our users really have many problems with spam,
because the addresses are randomly generated,
nine character, alpha numeric strings.
No spammer, no spammer tries to brute force that
to find out that address.
And they're typically not published.
It's a private messenger, usually you join with a QR code
over an invite link.
Yeah.
So they actually don't really need inbound spam protection.
And of course, then, outbound filter,
we don't want to pollute the rest of the email network.
I hope I think you're all very grateful for that.
And so we basically do not let messages go outside,
which are not PGP encrypted.
And basically you need an open public open PGP key
of the recipient to if you want to spam them.
So that just doesn't happen so far.
Please, if you like, realize that come to us,
and we will figure out some solution.
But yeah, so far.
This is just not something that must do.
It's not economic at all.
And yeah, there are enough other ways out there to spam.
And yeah, technically, we will,
we also let through messages,
which are part of the security on protocol handshake.
I'll talk about that a bit more later.
Yeah, basically.
I want to accept that for people in the back.
Consider this.
I mean, open PGP.
Open PGP is like known to have,
to be like a problematic ecosystem.
You know, it hasn't been mass adopted.
And we're actually turning this into spam protection.
They don't have our open PGP keys.
We don't even have them ourselves.
So, so even if you use one of these sign-ups
for receiving newsletters and the database of this address gets leaked,
you know, they cannot just create accounts and spam around
because for the regular web sign-up,
you don't specify your open PGP key.
You know, so the database of email addresses
is not usable for addressing spam
to aid from September, so I was at least.
So that's a very interesting turn in open PGP history.
Yeah, and it works because of our contact discovery model.
This is a bit different to how contact discovery usually works in email.
Like, you pass around your business card with an email address on a door
so.
And instead, you would do that with a QR code like that on those handouts.
And also chat.
Basically, this QR code signifies an invite link.
It's also printed on a handout actually.
And this invite link can also be shared via a second channel
if you don't need.
But basically, either you are in person or you're remote,
and one case you can do a QR code scanning introduction.
And the other case you can send out an invite link.
Maybe via the friend who introduces you.
Or via the other second channel you might already have.
But I mean, if you are somehow remotely in contact,
then you have a contact channel,
which you can use to spread that invite link.
There's also one third big thing,
which is also an interesting part of the queue join.
If you're being added to chat group,
you also get the public keys of everyone in the chat group,
and they get yours.
And not only that, it's also spreading the verification.
The queue join is basically the idea that,
yeah, who here does know how autocryp books.
Maybe or not many, okay.
How it does work.
Yeah.
Yeah, okay, I'll explain it a bit.
Basically autocryp is a standard for OpenPJP key transmission.
How can you exchange OpenPJP keys in band?
So basically you put the key in a header, the autocryp header,
you send it around, that's it.
And that's vulnerable against machine and middle attacks.
So, secure join is a standard,
which protects against machine and middle attacks against autocryp keys.
By putting the finger print, I mean it's simplified now,
but you put the finger print into the queue arcode,
or in the invite link.
And then whoever scans the queue arcode or clicks on the invite link,
can already, can then verify by sending around some emails
back and forth between your two accounts.
That actually, yes, this is your key,
and it has not been tampered with by a server in the middle.
There's some malicious machine in the middle.
That's here, yeah.
And no, no, I will come back to that later.
And so the green checkmark you all see in the chat now.
Here, this one.
And this means that with all of those,
56 check members, you now have MITM protected.
OpenPGP and to end encryption.
And I have no, who has been to a crypto party once,
where you like exchange the fingerprints
and verify it and sign everything.
This was just, we did that in the past half an hour
by accident without telling you.
Yeah.
So, yeah.
Now then there's the thing with,
yeah, basically this is how the contact discovery works.
And this enables us to do the same protection stuff.
Yeah, now I already said something about secure join.
I want to clean up a bone out of the move,
that basically email has so much metadata,
and that it cannot secure because it has so much metadata.
If you use a, like the devil chat,
you have basically the only information
which is left on the server if you look at an
actually email, I'm fire.
You have a sender, you have some recipients,
you have the date, and you have the article
of the BGP public key.
That's all you will see, also, as an admin,
for those encrypted males.
And actually, we have some plans to even reduce that
for the coming year.
We don't like to promise things which are not there already.
So we'll not go that much into detail.
But yeah, compared to metrics, for example,
where reactions are unencrypted.
We're all the group membership information
is unencrypted on a server and also
persisted forever instead of being the leader
as soon as you don't need to email any more.
Yeah, that's a very different model here.
And I think, yeah, email has a better reputation here
for no reason, actually.
You can do this much better.
So basically what we propose is
a kind of also for the whole email system to move away.
I mean, a lot of the stuff will not be applicable
to your mail service at home.
You don't want to be open-signer, probably,
or not all of you.
Maybe some of you want to run a chat mail server,
but that would be great.
But yeah, you probably cannot require open PGP encryption.
I mean, we basically don't allow users to send out emails
to normal email addresses if they don't have the PGP key
of them, so that in many ways, for email users,
this is a bit contrary, counter-intuitive.
So they have some constraints here
to basically introduce cryptography-based interoperability
instead of having just centralization-based trust.
Yeah, that's right now.
So we require open PGP and auto-crypt.
We do not require that, so chat.
We require that other mail servers use TKIM
and strict ADKIM, strict DKIM alignment.
But we do actually not require SPF or DMARC.
And this is for basically preventing from forgery.
We do have SPF and DMARC records in our auto-generated
DNS records, of course.
But we do not require others to use outdated standard
specifically, and really try to follow the best practices here.
And we require also, for example, that from HADOM
that's just a login name, we require TLS encryption,
so you cannot send a mail to chat my user
without TLS encryption.
That should not be possible anymore.
And we can do that basically because we do this many
for delta chat users.
We do not, like we can move in that space
because we can sacrifice them into a probability here
for good practice, which is also not a solution for everyone,
which is fine.
So yeah, I will skip that.
Basically, we have still have some suggestions
for classic email admins, classic mail servers,
how they can improve decentralized email,
based on cryptography instead of centralization.
Use standards like decim, and really enforce them,
or do more than the minus one or plus one,
as been the recommendation.
Like that's a bad joke.
That way, decim is in verb, anything.
And yeah, instead of trusting blocklists,
and IP blocklists and all of that stuff.
And yeah, stop grailisting, really, please.
My own, the mail provider where I have my main account
on uses grailisting, and sometimes when there is someone
from a new domain, and I, like, show them my QR code,
it takes 10 minutes until it's complete.
That's super annoying.
And it doesn't really improve anything,
if you could also trust cryptography instead.
And then, generally, for your ask them decet apps,
treat every open PGP encrypted email as ham, not spam,
and treat every valid reply as ham.
Because most Delta chat messages are valid replies,
and IPGP encrypted.
So those are things which are hopefully easy to do
for others, and that would be great.
Thanks.
So thanks, those are the links.
There are also some things.
And yeah, also, maybe one last thing.
We did a poll in our existing chatman operator group
about how much effort it is to operate something like this.
And yeah, nobody said that it's more than two hours
a month, work, and most actually here.
So it's quite easy to get running, if anyone's interested.
Can I also talk later outside?
Thanks.
Thank you.
So Q&A, does anyone have questions or remarks?
Does that join the server?
The question was that there is any moderation
of someone malicious John's to server.
Not really, because they could also then
unlike even if you find out somehow,
you can maybe disable that account by adding a character
to their password file.
They can join with a new account.
These things need to be approached differently,
I think, than with censorship.
But it's also discussion, we are,
it's more nuanced, of course.
Then this is the short answer basically.
You said that I'll write you the script and I'll be
on the same process so that if the server comes,
this will be just that you will be able to do
a new language that's right.
So what happens is that happens so maliciously,
how do you defend somebody's, what on the username,
which other people recognize, do you hijack by somebody?
Yeah, yeah, and to repeat it once,
how can you, yeah, prevent someone
squirting the email address of someone
by logging in with the same username
while you're after the older account was deleted.
I mean, that's a little unlikely scenario, of course,
because rarely user accounts are deleted.
But basically it's prevented by,
and the attacker does not have the private key
of that person who was a customer's deleted.
So it will show a big warning if, like,
when their thing changes and, yeah, maybe,
write out, like, with actually, like, changing the private key
and messaging each other and you will see
that we don't just show a small change set up message,
as long as there was a green check mark, of course.
But instead, actually, show a warning where people are told,
how they can do it, what they can do about it, how they can verify
via a second channel of the person,
change the device, maybe, and stuff like that.
So the problem is also solved by cryptocurrency, if you will.
Oh, sorry.
No, no, I mean, you're with the mask, sorry.
Sorry.
This may actually go back to the talk before,
but I didn't see that this stuff.
So, I'm so up to you, when you, patrons,
Image...
But the question was, a reference Sheila also work
of classic email accounts in Delta Chat. And yes it does. Yeah. Yeah, back there.
Yeah, let that you ask. You go to the settings. And then you click on add second device.
And then you click on continue. And now I cancel this quickly because it shows a QR code.
It shows a QR code, which you can then use to clone, which you can scan in the same local network of another device
to clone your account to a second device.
Yeah, it's the most usable thing we can could come up with.
All right. We are a little bit at the end of the situation. There was one question.
It's sometimes in the very end, but I think it's over right now.
So maybe one very final question.
I don't know who was first.
Sorry. Sorry.
So my question is, maybe I'm asking late, but how dependent is it that really on a group of G.
Could you, if you could read model, it just ripped a group of G out and do something smaller?
We do not use a group of G at all, do you mean open PGP?
PGP, yeah.
Oh, PGP.
I think it's not really, it doesn't really make sense to rip out open PGP.
It's the interoperable email standard.
And yeah, just, we are also coming from that space also.
I don't think that's what we would do.
Also, we come back to your problem.
Yeah, we have an implementation.
That is actually also aiming for to implement post quantum later this year in a summit.
We will talk about this.
We don't need to fight here.
And that's our PGP.
It's a representation of PGP.
And that is very well developed, audited, and so on.
So there's currently no reason, like we don't have problems there.
It's really working well.
And there is, of course, always a possibility.
If you look at this, we have to see a real time.
The blog post that is pinned, I think, on the very verse.
It uses a different encryption format.
It's not PGP.
The real time communication, I mentioned already, forward secrecy and so on.
It's like, it's a different setup.
You know, so it's not like we cannot do other things and so on.
But as everything in cryptography, it really makes sense to think about it.
You know, to have some process and not just jump to whatever kind of scheme you have in mind that might be great.
And so we are kind of bound to using proven things.
Agreed with several other players checked by many experts and so on.
And rather move slowly, then fast and unable to decrypt.
So, for many questions, I think we are at the end of the session.
You can maybe take some stuff offline.
Thank you very much for watching.