 Okay, I yeah, thanks for coming. We will be talking about a new chat initiatives that we are starting now Which is called? Koi chat of I'm Okay, so And my name is Robert. I've been involved in various open source projects over the years in 2004 I started J2M polish, which was a feature phone framework or an application Framework for developing for feature phones in 2009. We started the mobile developers guide to the galaxy That's a booklet from developers for developers in the mobile industry and a bottom cup of copies with me As well as some some some shirts about this project. If you like it, please grab your shirt later on And I'm Michael No, but I'm the for those of you familiar with dovecott the email server I'm the product manager for dovecott and we both work for open exchange Yeah, before we start can I ask you like please raise your hand? Who of you has an active email account? Look at all these people with Koi accounts, Robert Yeah, so obviously everybody has an active email account You know that's something and and you're like if we have like one main point in this presentation It's this, you know, like everybody already has an email account and and this is the main Difference that we bring to the stable here So this is being recognized throughout the industry like even Within the marketing spheres, you know, they say actually Find out that everybody's reachable via email who would have thought that it's even better than what's up, you know Yeah Yes, but I feel looking at the schedule of this room There's probably a lot of you in here who may prefer other chat protocols And so you're probably asking that the big question is IMAP is a chat protocol Does this makes zero sense whatsoever? because generally IMAP is not designed to handle small Small data low latency messages because that's really what we just watched Matthew's excellent performance on 90 millisecond or not 90 bite packets being sent across the network And so the question becomes there are protocols explicitly designed for chat. Why are we not using those protocols? But the big but behind all this is it's the network. I mean we all know we all understand that we just had that the hands go up We have this email network. There's a approximately, you know, we're gonna we're gonna use a number 3.8 billion million 3.8 billion unique active email users. So that's it. It's the network Everything else you're hearing of today. I mean XMP P is great make matrix is great There's all kind of cool things that are coming along with that But the network is not anywhere near that so our our goal or the design of this whole project is the idea that we have to tap Into this existing network because that means we don't have to worry about the network anymore that network is hard Federation is really really hard Why not use the network that already exists and already has built-in abuse and security you have millions of people I say thousands of people you have millions of people that are involved in the network We don't know them we don't employ them, but they run their our network for us already So that is the goal or that is the the the concept of Koi is how can we take advantage of this network? And the system is fully operational today. All you have Koi accounts and we haven't even told you what it is yet Now for IMAP itself Agree that IMAP is a bit of an old protocol People we can sit here and complain about the semantics of the protocol, but it is well known. It's stable It's it and it's definitely extensible so there are some tools for us to use to be able to you know have a baseline of what we can provide today and Then extend on top of that and for the record I don't know if I see Bronnan here, but we had there's a discussion about j-map yesterday This is not specific to IMAP. It's chat over IMAP is in the name That's for marketing reasons or whatnot the idea being this is really more chat over email And so we're using IMAP right now because it is the standard and it's the standard that we can immediately deploy But in the future j-map would be would be perfectly fine to use for the male the last mile male transfer part of this Very important about all this especially when we look at in respect to other chat protocols out there Generally your chat ID or your email is your chat ID Identifier, but in Koi that's your account for example in matrix or matrix or excuse me I think in matrix you can but XNPP jabber you can use email as an identifier, but that's not your account You still need some sort of account in Excuse me in Koi that is your account and so we actually see a world where you as a chat Chat client author can take your chat client that uses email as a potential You know as an account ID and if you implement Koi behind the scenes You don't really have to do anything authentication wise or change your login page or identifier And now you get access to three point eight billion Users potentially maybe at a degraded level because we only can do certain things at this point But we feel that that right the rising tide lifts all boats And so that is the goal of Koi is to allow Clients to innovate We're going to give you the the the pieces the pieces already exist in the email the current email network and Instead of waiting for a network to build up or working on network issues or Infrastructure issues that exists so the client should be the one driving change and innovation in this ecosystem Robert Yeah, so that's what I will be talking now about We are started with a specification for the clients now so on wiki.coyslashdef.org you can Show them. We will also publish them on github in due time Right now we are finding out and talking with everybody about these ideas and To make it better So we have some Design kind of considerations for the specification. So first of all, we do not want to reinvent the VV We want to use open standards as much as possible. We want to use what's out there so for example using vCard for the contact data using existing Content disposition notification reports for the read receipts and so on The important things like if you have like all these billions of email users Is to be actually backwards compatible So people should be able to join in using their existing email kinds and that's one of the most difficult codes actually Because only then we can really leverage the network, you know, so With respect to compatibility in mind, we need always to have something to show to the users You know, so there should always be a text plane or an HTML or a binary Message part for example, and we also want to make it really really simple So in group discussions, for example, it's just a subject as a group name You can just add somebody on to or CC and change the participants list as you would expect from email In regards to secure messaging, we are not specifying anything that goes against encryption So we are making sure that all your clients can use any encryption scheme that you want to typically that would be like some sort of GBG or similar encryption Last but not least we want to provide some modern user experience on top of emails for example People expect that they can also block undesired contacts They want to edit and delete already send messages or They want to also sync contacts across devices And these are also goals for for the specification to make that possible at least as much as it is Can be done on the existing infrastructure Now let me show you some very very simple examples So if you have ever ever written an email, you know, then you know, you will recognize that, you know There's a from there's a to whatever the only thing that we are doing that we're heading on chat version header That marks this message actually as a chat there might be clients who want to differentiate between a chat user experience and an email user experience and We want to enable that and that's why we have this version for now when you have User of an existing email client that doesn't know anything about the chat version So when he replies, you know the question it's it's a client to decide but the question is Will this be a chat conversation or will this be like a traditional email conversation? And if you want to differentiate between that You can still do that because we have in the message idea We're starting every message ID with a coin dollar sign and you will get this reference in the reply from an Existing email client as well. And so you can now. Hey, this is originating from a chat context and this helps you to channel it into it group messages very very simple same idea chat version header the group name is a subject and additionally I Also at the group ID here after the coin dollar sign and This helps me to also identify groups when I get legacy replies back To edit messages again very very simple I am replying to my previous message that I have sent myself and I said now chat content edit now On existing email clients. This will be just a duplicate message, but people will hopefully recognize. Ah, okay so I had previously made a typo or whatever now it's edited and on Coy compliant clients We asked clients to show only the last version of this edited message, but at the same time we recommend to make the The editing visible and also the history available so that we do not do not create a false sense of security so that people think ah, I've Sent something embarrassing, but I can't delete it. No problem because on existing email clients. It will still show up, right? So we want to be very honest with the users about that so Thinking context is also like just a large message. So we envision we we want to store this into a specific Subfolder we suggest to call contacts for that We will store some metadata about the contact inside here. For example, what kind of groups? Is this contact associated with or what kind of notification? Does the user want to get when there's an incoming message from that specific user and then we are also storing The actual data as I said like in a plain old we cut It's kind of boring, but it's it's a repeating Theme in this whole specification if you read through it. We are reusing what's out there We are not reinventing that we are just putting things together in a different sort of way and That is the client specification and now we are also working on the server side stuff and with the server side stuff We get more exciting things to do. For example, you can also automate like this differentiation between chat and normal email messages by Like letting the server do the hard work for you or the server can also block incoming messages for you Blocking by the way means not like deleting any messages. They will just be moved to a blocked folder. That's at least our suggestion here We will enable push notifications. We will probably leverage the web notifications standard for that And so you will need to have your own middleware that is Application-specific, but it's much much easier than running your own service that Also, then requires the user credentials to poll for new messages and then informs your app We are working on web RTC implementation on that level to leverage audio and video calls We are also working on a yeah some sort of slack competitor by introducing a channel concept a channel It's a group discussion with additional rights management and also the benefits that you can see the full history when you're joining a channel And last but not least we have another interesting idea. This is a direct message submission and Michael explain it. Yeah, which gets into the idea of now that we have this base spec that works with existing email clients or email servers How do we extend this this spec over time naturally and it still works? It's still backwards compatible and we innovate and and we provide a better experience and part of that is framing the problem as Let's not look at email How how we we make this better for for this Koi project? How do we make email better for Koi? It's let's look at email in general Find some things we can improve on and then we can take advantage of that in Koi But then if you walk away from this room and say screw this we're going to do XMPP I don't I have no interest in this maybe this part interests you know This is going to make just the email experience. We feel better in general We'll use this one example because this is something that we're working on currently And the problem is the email delivery that can be high latency And an idea would be to develop a secure way to discreet to decrease delivery times For for trusted users. So we that has to be some sort of trust model built in the solution Is this direct message submission and again? This is not tied to this particular project It'll be something we would use to make our the chat messages over email better, but it's not tied to the project I'm not sure if anybody here is familiar with mail Delivery so we'll do a quick. This is my example of the mesh. It's not quite is there's no docker things being thrown up or anything This is crappy PowerPoint graphics But we all know today that the number one use of email is to send around cat memes So if you have a cat meme and you want to send from one endpoint to another The problem is is a routing a mail routing might go to locally then you got some bug Scanning and you got outbound and then you have some fancy expensive cloud MTA service And there's something you know that there's unstable high latency MTA, you know could be on the moon That's not going to work You know you're going to time out and then know yeah that MX record doesn't point to anything So that doesn't work and then you're going to waste their time and then oh, we'll try this again And that's going to take forever and eventually, you know Oh, you got to go through the bug bug scanning on that side and then finally It's it's it's it's sent to the other side now This is obviously a very contrived example and most email doesn't work like this But if you have this as a user experience consistently, this is not good So the idea being is how do we sort of get rid of all that mess in the middle and maybe figure out a way to more directly? Deliver messages to each other and see the idea being that you just send in a message You don't have to change your client at all you send it to a local submission server This is where dovecott will fit in Dovecott is not only an IMAP server now We have a submission part of the server that that ties in with the IMAP server or I should say mail server And what that server will do is it will add a token to this message now This and then you're you deliver the message to the end user that end user now has the token So coming back the other way, so we now we have this token this this has to be somebody You know the the end user has to be or this area Whatever you have in the end user has to be aware of this submission token process But it can be on either the client or in they have a like say a dovecott server also That's not important for now What's important really more is the abstract idea that once you have this token there's going to be an auto detection Method that allows you to find what is the original submission server now you have this token This is done over a secure connection. So there is some domain checking certificate wise. This may also be Secure DNS for example But once you do that you it you get a direct connection to the local submission server So you get to you get to avoid all that mass and then you can deliver the message much quicker and And this is what we see as being the next step and now me as you know being a dovecott Being on the dovecott side. We have a fairly large reach of our server So we feel that one thing that we can do is kind of push forward these kind of standards to make mail better And actually we already have a built-in user base that may be interested in using these kind of improvements to mail Then hopefully other people would agree and then join us as we work on these kind of efforts And so what's important about all this too is it's transparent to end user end users Don't even know this is going on it can be supported by the client unidirectionally. It works better if you have a server But you know if you're you as a client author if you wanted to add this you could do that on your own And this is mail API agnostic It's it's this is actually SMTP side of things not IMAP So this works for any you know future j-map or whatever you want to use to access your mail Yeah, okay about Back from the future. That's the future. It features exciting wide-open, but Robert's going to show you what we have currently Yeah, so what are we working on we are working on for example an ox talk Which is like our will become our flagship product and we are almost running out of time So I will be very quick. It's MPL license. So it's completely free to use commercially reusable We are cooperating with data checks there. We are reusing the data check core library It's on github. You can already check it out It's in very very early technical preview You know it contains many bugs, but at least it allows you to exchange messages already We are working with several partners. I already mentioned Delta chat cool product check it out Spike is another conversational email experience and they want to become quite compatible in the future We are talking with Thunderbird. We are very open to talk to any Email service if you have any ideas around that if you have maybe already an existing chat plan And you want to really leverage some of these billions of users on email. It might be a good idea to also Integrate joy compliance into it. That's very easy Now I'm skipping this slide because that pretty much only sums up what we have and we are running out of time So thanks for your attention and if you have any questions, please let us know Yeah, you get one one question brah one Why are we so awesome that's easy to answer this is more a comment than a question No, the extra working group at itf is doing IMAP extensions right now And we are looking to reach out having done most of the IMAP extensions that are sitting in the queue One of them is IMAP submit which I think would fit in very nicely there And the other thing we're looking at rechartering into is SMTP extensions. This looks like a perfect thing to bring I'd love to see you in Prague in a month and a half. Yes Yeah Yes Now where's my boss just has to pay for the plane ticket. No, that's exactly that's exactly obviously something We want to work on we have some ideas, but we would love to come in and yes Yes, yes Yeah, so thanks again if you want to have a free t-shirt or booklet this guide or we've got stickers Please come to the front or talk to us. Thank you You