Breaking the Messaging Silos with COI: Chat Over IMAP
Virkus, Robert
Slusarz, Michael
Meet COI (Chat over IMAP) - a powerful contender for WhatsApp, Facebook Messenger and other proprietary messengers. Based on email this open standards & open source iniative overcomes the network effect by providing a chat experience to over 3.8 billion active email users worldwide. By being backwards compatible with pure email, you do not need to convince all your friends, family and peers to join the new system - you can still engage with them and they can reach you. We cooperate with Delta Chat open source project to bundle efforts and ensure interoperability. Join this talk to learn about all things COI from Michael (Dovecot) and Robert (OX). The COI standard is the best way to overcome the current messaging silos and allow everyone to compete on the same terms. Read on to learn why COI matters. Problem Most popular messaging services are currently proprietary, closed and operated by single providers. This leads to several problems: Privacy: The provider knows all about your social network: when you communicate with whom, the frequency of your communication and the number, type and length of your messages – even with end to end encryption in place. Unfair competition: Service providers depend on the rules set by the messaging owner and access to the API for participation. If the messaging provider changes the rules or chooses to offer your particular service itself, you are out of luck. Lock in: You cannot simply change to another provider, because your friends and peers are also using that service provider. If you want to switch you would need to convince everyone to join your new service provider. And of course you would lose all your conversation history if you dare to move away. Don’t like the new app version? Bad luck, you cannot choose another app. Silo: the network is only controlled by a single party, you cannot start hosting your own WhatsApp, WeChat or FB Messenger Service. Some providers like Facebook even control several popular messaging apps, like WhatsApp and Facebook Messenger. Why Others do not Solve this Problem Maybe you are thinking “I thought this is why we have Signal, Telegram and the other privacy-centric apps?” – they might very well be better than some of the more popular networks, but in the end, they control the network and other providers are locked out. Basically, you are exchanging one silo with another. “What about XMPP and Matrix.org?” – glad you asked! We love XMPP and Matrix.org because they provide a great solution – this only solves the problem in theory though. With XMPP and Matrix.org-based services you would still need to convince everyone to join your new network. Easy in theory, very complex in practice! “What about RCS? I thought Google fixes this?” – well, are you sure about Google? Google used XMPP in the past but then locked it down. Google tried to push several chat solutions out with only little success. So, Google’s track record is far from perfect. Most notably, however, RCS requires a device to have a phone number (MSISDN). As communication is quickly migrating towards pure IP based solutions, MSISDNs become relics of the past. Most new innovative devices come without MSISDNs, e.g. voice enabled devices such as Alexa or Google Home, VR and AR devices such as HoloLens or Oculus Rift, portable game consoles, etc. With this dependency on MSISDNs, RCS’ future is uncertain. Meet COI COI enhances an already existing communication system: email. This already solves lots of problems: It’s free, open and permission-less. You can reach more than 3.8 billion active email users – this overcomes the network effect! With COI’s backward compatibility, you can reach everyone, even when they are only using traditional email. In this talk Michael and Robert will explain why COI really offers potential, the technical details about the new standards and what the next steps on this exciting journey are.
 Okay, thanks for coming. We will be talking about a new chat initiative that we are starting now, which is called Koi, chat of IMET. This will be Koi, so people won't be using chat. My name is Robert. I have 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 developer guide to the galaxy. That's a booklet from developers, for developers in the mobile industry. And I bought a couple of copies with me, as well as some shirts about this project. If you like it, please grab your shirt later on. And I'm Michael. For those of you familiar with Dovcott, the email server, I'm the product manager for Dovcott. We both work for OpenExchange. Before we start, can I ask you, 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. If we have one main point in this presentation, it's this. Everybody already has an email account, and this is the main difference that we bring to this table here. So this is being recognized throughout the industry. Even within the marketing sphere, they actually find out that everybody is reachable via email and who would have thought that? It's even better than WhatsApp. 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 make zero sense whatsoever? Because generally IMAP is not designed to handle small data low latency messages, because that's really what we just watched Matthew's excellent performance on 90-bite packets being sent across the network. And so the question becomes, are protocols explicitly designed for chat? Why are we not using those protocols? But the big but behind all this is the network. We all understand that we just had the hands go up. We have this email network. There's approximately, we're going to use a number 3.8 billion unique active email users. So that's it. It's the network. Everything else you're hearing of today, I mean XMPP is great, Mate 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 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. And it's 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 our network for us already. So that is the goal or that is the concept of COI is how can we take advantage of this network? And the system is fully operational today. All of you have COI accounts and we haven't even told you what it is yet. Now for IMAP itself, agreed that IMAP is a bit of an old protocol. We can sit here and complain about the semantics of the protocol, but it is well known. It's stable and it's definitely extensible. So there are some tools for us to use to be able to 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 Bronn in here, but there was a discussion about JMAP yesterday. This is not specific to IMAP. This 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, JMAP would be perfectly fine to use for the last mile mail transfer part of this. Very important about all this, especially when we look 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 XMPP, Jabber, you can use email as an identifier, but that's not your account. You still need some sort of account. In Koi, that is your account. And so we actually see a world where you as a chat client author can take your chat client that uses email 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 3.8 billion users potentially, maybe at a degraded level because we only can do certain things at this point. But we feel that 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 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'll be talking now about. We are starting with the specification for the clients now, so on wiki.koi.deaf.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 considerations for the specification. So first of all, we do not want to reinvent the V. 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 thing is if you have all these billions of email users, it's to be actually backwards compatible so people should be able to join in using their existing email clients. And that's one of the most difficult codes actually. Because only then we can really leverage the network. So with respect to compatibility in mind, we need always to have something to show to the users. You know, 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 with 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 GPG 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 sent messages. Or they want to also sync contacts across devices. And these are also goals for the specification to make that possible, at least as much as it 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 will recognize that, you know, there's a from, there's a to, whatever. The only thing that we are doing, like we're heading on a 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 a 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 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 are starting every message ID with a call $ sign. And you will get this reference in the reply from an existing email client as well. And so you can know, 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 add the group ID here after the call $ sign. And this helps me to also identify groups when I get legacy replies back. To edit messages, again, very, very simple. I'm replying to my previous message that I have sent myself. And I said, now, chat content added. 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 type or whatever. Now it's edited. And on Koi, compliant clients, we ask clients to show only the last version of this edited message, but at the same time, we recommend to make the editing visible and also the history available so that we 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 want to store this into a specific sub-folder. We suggest Koi 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 WeCard. It's kind of boring, but 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 the way. 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, you 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 webRTC implementation on that level to leverage audio and video calls. We are also working on some sort of Slack competitor by introducing a channel concept. A channel is a group discussion with additional rights management and also the benefit that you can see the full history when you are joining a channel. And last but not least, we have another interesting idea that is a direct message submission and a micro-explanation. 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 spec over time naturally and it still works, it's still backwards compatible. And we innovate and we provide a better experience. And part of that is framing the problem as let's not look at email, how we make this better for this Koi project. How do we make email better for Koi? 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 have no interest in this, maybe this part interests you. This is going to make 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 decrease delivery times for trusted users. So 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 would be something we would use to make 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, 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 a mail routing might go to locally. Then you got some bug scanning. Then you got outbound. And then you have some fancy expensive cloud MTA service. And there's something, there's unstable high latency MTA, it could be on the moon. That's not going to work. You're going to time out. And then that MX record doesn't point to anything. So that doesn't work. And then you're going to waste time. And then, oh, we'll try this again. And that's going to take forever. And eventually, you've got to go through the bug scanning on that side. And then finally, 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 so the idea being that you just send a message, you don't have to change your client at all. You send it to a local submission server. This is where Dovcott will fit in. Dovcott is not only an IMAP server now. We have a submission part of the server 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 then you deliver the message to the end user. And that end user now has the token. So coming back the other way, so now we have this token. This has to be somebody, the end user has to be, or this area, whatever you have in the end user has to be aware of the submission token process. It can be on either the client or they have, like say, a Dovcott server also. But 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 get a direct connection to the local submission server. So you get to avoid all that mass. And then you can deliver the message much quicker. And this is what we see as being the next step. And now me as being on the Dovcott 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 users. 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 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. This is actually SMTP side of things, not IMAP. So this works for any future JMAP or whatever you want to use to access your mail. Yeah, okay. But back from the future. So that's the future. The future is exciting, wide open, but Robert's going to show you what we have currently. So what are we working on? We are working on, for example, an Oxtalk, which is like our, will become our flagship product. And we are almost running out of time. So it 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 client 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. Also thanks for your attention and if you have any questions, please let us know. Yeah, Bron. One question, Bron. One. Why are we so awesome? That's easy to answer. This is more a comment than a question. The extra working group at IATF 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. The other thing we are looking at reach outering into is SMTP extensions. This looks like a perfect thing to bring. I would love to see you in Prague in a month and a half. Yes. Now where's my boss? He just has to pay for the plane ticket. That's exactly Bron. That's obviously something we want to work on. We have some ideas but we would love to come in. We'd like to bring it through the open standardization process. Yes. Yes. I like that. 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. Thank you. Thank you.
 Okay, thanks for coming. We will be talking about a new chat initiative that we are starting  now, which is called Koi, chat of IMET.  This will be Koi, so people won't be using chat.  My name is Robert. I have 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 developer guide to the galaxy.  That's a booklet from developers, for developers in the mobile industry.  And I bought a couple of copies with me, as well as some shirts about this project.  If you like it, please grab your shirt later on.  And I'm Michael. For those of you familiar with Dovcott, the email server, I'm the product  manager for Dovcott. We both work for OpenExchange.  Before we start, can I ask you, 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.  If we have one main point in this presentation, it's this.  Everybody already has an email account, and this is the main difference that we bring  to this table here.  So this is being recognized throughout the industry.  Even within the marketing sphere, they actually find out that everybody is reachable via email  and who would have thought that?  It's even better than WhatsApp.  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 make zero sense whatsoever?  Because generally IMAP is not designed to handle small data low latency messages, because  that's really what we just watched Matthew's excellent performance on 90-bite packets being  sent across the network.  And so the question becomes, are protocols explicitly designed for chat?  Why are we not using those protocols?  But the big but behind all this is the network.  We all understand that we just had the hands go up.  We have this email network.  There's approximately, we're going to use a number 3.8 billion unique active email users.  So that's it.  It's the network.  Everything else you're hearing of today, I mean XMPP is great, Mate 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 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.  And it's 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 our network for us already.  So that is the goal or that is the concept of COI is how can we take advantage of this  network?  And the system is fully operational today.  All of you have COI accounts and we haven't even told you what it is yet.  Now for IMAP itself, agreed that IMAP is a bit of an old protocol.  We can sit here and complain about the semantics of the protocol, but it is well known.  It's stable and it's definitely extensible.  So there are some tools for us to use to be able to 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 Bronn in here, but there was a discussion  about JMAP yesterday.  This is not specific to IMAP.  This 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, JMAP would be perfectly fine to use for the last mile mail transfer  part of this.  Very important about all this, especially when we look 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 XMPP, Jabber,  you can use email as an identifier, but that's not your account.  You still need some sort of account.  In Koi, that is your account.  And so we actually see a world where you as a chat client author can take your chat client  that uses email 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 3.8 billion users potentially, maybe at a degraded level because  we only can do certain things at this point.  But we feel that 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 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'll be talking now about.  We are starting with the specification for the clients now, so on wiki.koi.deaf.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 considerations for the specification.  So first of all, we do not want to reinvent the V. 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 thing is if you have all these billions of email users, it's to be actually  backwards compatible so people should be able to join in using their existing email  clients.  And that's one of the most difficult codes actually.  Because only then we can really leverage the network.  So with respect to compatibility in mind, we need always to have something to show to  the users.  You know, 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 with 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 GPG 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 sent messages.  Or they want to also sync contacts across devices.  And these are also goals for the specification to make that possible, at least as much as  it 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 will recognize that, you  know, there's a from, there's a to, whatever.  The only thing that we are doing, like we're heading on a 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 a 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 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 are starting every message ID with a call $ sign.  And you will get this reference in the reply from an existing email client as well.  And so you can know, 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 add the group ID here after the call $ sign.  And this helps me to also identify groups when I get legacy replies back.  To edit messages, again, very, very simple.  I'm replying to my previous message that I have sent myself.  And I said, now, chat content added.  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 type or whatever.  Now it's edited.  And on Koi, compliant clients, we ask clients to show only the last version of this edited  message, but at the same time, we recommend to make the editing visible and also the history  available so that we 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 want to store this into a specific sub-folder.  We suggest Koi 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 WeCard.  It's kind of boring, but 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 the way.  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, you 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 webRTC implementation on that level to leverage audio and video calls.  We are also working on some sort of Slack competitor by introducing a channel concept.  A channel is a group discussion with additional rights management and also the benefit that  you can see the full history when you are joining a channel.  And last but not least, we have another interesting idea that is a direct message submission and  a micro-explanation.  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 spec over time naturally and it still works, it's still backwards compatible.  And we innovate and we provide a better experience.  And part of that is framing the problem as let's not look at email, how we make this  better for this Koi project.  How do we make email better for Koi?  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  have no interest in this, maybe this part interests you.  This is going to make 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 decrease delivery times for trusted users.  So 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 would be something we would use to make 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, 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 a mail routing might go to locally.  Then you got some bug scanning.  Then you got outbound.  And then you have some fancy expensive cloud MTA service.  And there's something, there's unstable high latency MTA, it could be on the moon.  That's not going to work.  You're going to time out.  And then that MX record doesn't point to anything.  So that doesn't work.  And then you're going to waste time.  And then, oh, we'll try this again.  And that's going to take forever.  And eventually, you've got to go through the bug scanning on that side.  And then finally, 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 so the idea being that you just send a message, you don't have to change your client  at all.  You send it to a local submission server.  This is where Dovcott will fit in.  Dovcott is not only an IMAP server now.  We have a submission part of the server 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 then you deliver the message to the end user.  And that end user now has the token.  So coming back the other way, so now we have this token.  This has to be somebody, the end user has to be, or this area, whatever you have in  the end user has to be aware of the submission token process.  It can be on either the client or they have, like say, a Dovcott server also.  But 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 get a direct connection to the local submission server.  So you get to avoid all that mass.  And then you can deliver the message much quicker.  And this is what we see as being the next step.  And now me as being on the Dovcott 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 users.  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 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.  This is actually SMTP side of things, not IMAP.  So this works for any future JMAP or whatever you want to use to access your mail.  Yeah, okay.  But back from the future.  So that's the future.  The future is exciting, wide open, but Robert's going to show you what we have currently.  So what are we working on?  We are working on, for example, an Oxtalk, which is like our, will become our flagship  product.  And we are almost running out of time.  So it 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 client  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.  Also thanks for your attention and if you have any questions, please let us know.  Yeah, Bron.  One question, Bron.  One.  Why are we so awesome?  That's easy to answer.  This is more a comment than a question.  The extra working group at IATF 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.  The other thing we are looking at reach outering into is SMTP extensions.  This looks like a perfect thing to bring.  I would love to see you in Prague in a month and a half.  Yes.  Now where's my boss?  He just has to pay for the plane ticket.  That's exactly Bron.  That's obviously something we want to work on.  We have some ideas but we would love to come in.  We'd like to bring it through the open standardization process.  Yes.  Yes.  I like that.  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.  Thank you.  Thank you.
Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_0_167.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_168_1739.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_1740_1871.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_1872_1943.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_1944_2387.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_2388_2879.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_2880_3839.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_3840_8915.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_8916_9503.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_9504_12323.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_12324_14039.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_14040_15971.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_15972_17267.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_17268_19391.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_19392_19931.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_19932_21311.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_21312_22043.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_22044_26219.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_26220_26447.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_26448_27287.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_27288_28103.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_28104_28319.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_28320_30611.png Break_the_Messaging_Silos_with_COI_Get_to_know_the_Chat_Over_IMAP_initiative_F5EEld6-pWc_30612_30724.png
Okay, thanks for coming. We will be talking about a new chat initiative that we are starting now, which is called Koi, chat of IMET. This will be Koi, so people won't be using chat. My name is Robert. I have 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 developer guide to the galaxy. That's a booklet from developers, for developers in the mobile industry. And I bought a couple of copies with me, as well as some shirts about this project. If you like it, please grab your shirt later on. And I'm Michael. For those of you familiar with Dovcott, the email server, I'm the product manager for Dovcott. We both work for OpenExchange. Before we start, can I ask you, 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. If we have one main point in this presentation, it's this. Everybody already has an email account, and this is the main difference that we bring to this table here. So this is being recognized throughout the industry. Even within the marketing sphere, they actually find out that everybody is reachable via email and who would have thought that? It's even better than WhatsApp. 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 make zero sense whatsoever? Because generally IMAP is not designed to handle small data low latency messages, because that's really what we just watched Matthew's excellent performance on 90-bite packets being sent across the network. And so the question becomes, are protocols explicitly designed for chat? Why are we not using those protocols? But the big but behind all this is the network. We all understand that we just had the hands go up. We have this email network. There's approximately, we're going to use a number 3.8 billion unique active email users. So that's it. It's the network. Everything else you're hearing of today, I mean XMPP is great, Mate 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 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. And it's 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 our network for us already. So that is the goal or that is the concept of COI is how can we take advantage of this network? And the system is fully operational today. All of you have COI accounts and we haven't even told you what it is yet. Now for IMAP itself, agreed that IMAP is a bit of an old protocol. We can sit here and complain about the semantics of the protocol, but it is well known. It's stable and it's definitely extensible. So there are some tools for us to use to be able to 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 Bronn in here, but there was a discussion about JMAP yesterday. This is not specific to IMAP. This 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, JMAP would be perfectly fine to use for the last mile mail transfer part of this. Very important about all this, especially when we look 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 XMPP, Jabber, you can use email as an identifier, but that's not your account. You still need some sort of account. In Koi, that is your account. And so we actually see a world where you as a chat client author can take your chat client that uses email 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 3.8 billion users potentially, maybe at a degraded level because we only can do certain things at this point. But we feel that 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 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'll be talking now about. We are starting with the specification for the clients now, so on wiki.koi.deaf.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 considerations for the specification. So first of all, we do not want to reinvent the V. 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 thing is if you have all these billions of email users, it's to be actually backwards compatible so people should be able to join in using their existing email clients. And that's one of the most difficult codes actually. Because only then we can really leverage the network. So with respect to compatibility in mind, we need always to have something to show to the users. You know, 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 with 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 GPG 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 sent messages. Or they want to also sync contacts across devices. And these are also goals for the specification to make that possible, at least as much as it 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 will recognize that, you know, there's a from, there's a to, whatever. The only thing that we are doing, like we're heading on a 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 a 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 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 are starting every message ID with a call $ sign. And you will get this reference in the reply from an existing email client as well. And so you can know, 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 add the group ID here after the call $ sign. And this helps me to also identify groups when I get legacy replies back. To edit messages, again, very, very simple. I'm replying to my previous message that I have sent myself. And I said, now, chat content added. 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 type or whatever. Now it's edited. And on Koi, compliant clients, we ask clients to show only the last version of this edited message, but at the same time, we recommend to make the editing visible and also the history available so that we 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 want to store this into a specific sub-folder. We suggest Koi 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 WeCard. It's kind of boring, but 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 the way. 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, you 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 webRTC implementation on that level to leverage audio and video calls. We are also working on some sort of Slack competitor by introducing a channel concept. A channel is a group discussion with additional rights management and also the benefit that you can see the full history when you are joining a channel. And last but not least, we have another interesting idea that is a direct message submission and a micro-explanation. 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 spec over time naturally and it still works, it's still backwards compatible. And we innovate and we provide a better experience. And part of that is framing the problem as let's not look at email, how we make this better for this Koi project. How do we make email better for Koi? 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 have no interest in this, maybe this part interests you. This is going to make 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 decrease delivery times for trusted users. So 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 would be something we would use to make 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, 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 a mail routing might go to locally. Then you got some bug scanning. Then you got outbound. And then you have some fancy expensive cloud MTA service. And there's something, there's unstable high latency MTA, it could be on the moon. That's not going to work. You're going to time out. And then that MX record doesn't point to anything. So that doesn't work. And then you're going to waste time. And then, oh, we'll try this again. And that's going to take forever. And eventually, you've got to go through the bug scanning on that side. And then finally, 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 so the idea being that you just send a message, you don't have to change your client at all. You send it to a local submission server. This is where Dovcott will fit in. Dovcott is not only an IMAP server now. We have a submission part of the server 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 then you deliver the message to the end user. And that end user now has the token. So coming back the other way, so now we have this token. This has to be somebody, the end user has to be, or this area, whatever you have in the end user has to be aware of the submission token process. It can be on either the client or they have, like say, a Dovcott server also. But 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 get a direct connection to the local submission server. So you get to avoid all that mass. And then you can deliver the message much quicker. And this is what we see as being the next step. And now me as being on the Dovcott 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 users. 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 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. This is actually SMTP side of things, not IMAP. So this works for any future JMAP or whatever you want to use to access your mail. Yeah, okay. But back from the future. So that's the future. The future is exciting, wide open, but Robert's going to show you what we have currently. So what are we working on? We are working on, for example, an Oxtalk, which is like our, will become our flagship product. And we are almost running out of time. So it 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 client 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. Also thanks for your attention and if you have any questions, please let us know. Yeah, Bron. One question, Bron. One. Why are we so awesome? That's easy to answer. This is more a comment than a question. The extra working group at IATF 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. The other thing we are looking at reach outering into is SMTP extensions. This looks like a perfect thing to bring. I would love to see you in Prague in a month and a half. Yes. Now where's my boss? He just has to pay for the plane ticket. That's exactly Bron. That's obviously something we want to work on. We have some ideas but we would love to come in. We'd like to bring it through the open standardization process. Yes. Yes. I like that. 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. Thank you. Thank you.
copies with me, as well as some shirts about this later on. And I'm Michael. For those of you email and who would have thought that? It's even better than WhatsApp. But I feel, looking at the use a number 3.8 billion unique active email worry about the network anymore. That network is hard. And it's really, really hard. Why not use them, but they run our network for us already. So that is the goal or that is the concept of COI is what it is yet. Now for IMAP itself, agreed that of that. And for the record, I don't know if I IMAP. This chat over IMAP is in the name. That's using IMAP right now because it is the standard can, but XMPP, Jabber, you can use email as an get access to 3.8 billion users potentially, goal of Koi is to allow clients to innovate. already exist in the email, the current email wiki.koi.deaf.org. You can show them. We will reinvent the V. We want to use open standards as should be able to join in using their existing to compatibility in mind, we need always to have 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 making sure that all your clients can use any encryption scheme that you want to. Typically, chat, there might be clients who want to differentiate between a chat user experience and that. And that's why we have this version for now will this be like a traditional email conversation? And if you want to differentiate between that, you can still do that because we type or whatever. Now it's edited. And on Koi, the same time, we recommend to make the editing the users about that. So thinking context is also now we are also working on the server side stuff. exciting things to do. For example, you can also Blocking by the way means not like deleting any 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 the full history when you are joining a channel. backwards compatible. And we innovate and we provide a better experience. And part of that is working on currently. And the problem is the solution is this direct message submission. And again, this is not tied to this particular it's not tied to the project. I'm not sure if one endpoint to another, the problem is a mail finally, it's sent to the other side. Now this is in. Dovcott is not only an IMAP server now. We the message to the end user. And that end user now. What's important really more is the abstract for example. But once you do that, you get a what we see as being the next step. And now me as could do that on your own. And this is mail API the future. The future is exciting, wide open, almost running out of time. So it will be very messages already. We are working with several partners. I already mentioned Delta Chat, cool conversational email experience and they want to become quite compatible in the future. We are are looking to reach out having done most of the that. Thanks again. If you want to have a free stickers, please come to the front or talk to us.