COI – Chat Over IMAP - <AUTHOR> https://www.coi-dev.org/ <comment><USER3> > 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!

I think they missed the the bit where Matrix is called Matrix because it bridges (matrixes) the existing networks (Slack, IRC, Telegram, Discord, XMPP, etc) in, rather than needing to convince everyone to join. But no matter, we'll just provide a COI bridge if this takes off :)

<comment><USER4> In reality, those bridges work badly and hardly anyone uses them. I had to give up on my attempt at using Matrix as IRC client - it had questionable uptime and some channels even banned Matrix users due to frequent reconnects (on Freenode).

Hackint recently shut down their Matrix bridge due to how maintenance- intensive it was (and the fact that it logged all messages in its own database).

It's great in theory but impractical to use.

<comment><USER3> This info is a bit stale - it's true we had stability problems in Freenode until July 2018 (exasperated by their spam issues), but since then it's been pretty stable and the reconnects are considerably rarer than freenode netsplits. It's not perfect, but many people use it fine as a casual IRC client. There are over 24,000 active users using the Freenode bridge in the last month, for instance, so I'm unsure that 'hardly anyone uses them'...

The Hackint story is a different one; the bridge itself is not maintenance intensive at all. But it is true that the default Matrix server implementation is resource & relatively admin heavy; we're working on that currently. Meanwhile we're also fixing the data retention behaviour - [https://github.com/matrix-org/matrix- doc/blob/matthew/msc176...](https://github.com/matrix-org/matrix- doc/blob/matthew/msc1763/proposals/1763-configurable-retention-periods.md) etc.

<comment><USER5> I tried Matrix last month. It's neat, but slow and a little buggy. Recommending it to anyone other than a Matrix developer right now seems a bit of a stretch.

<comment><USER6> Not to mention that it's just re-solving all the same problems other messaging protocols (XMPP, IRC, etc.) spent time solving 10+ years ago.

I always feel that the Matrix organization is a bit disingenuous. Not only are they not developed by any recognized standards body (meaning they have no long-term sustainable funding model), but if they really just wanted to connect all the other chat protocols and make sure everything was interoperable they could have built bridges for existing protocols instead of reinventing the wheel yet again and making the chat scene even more fragmented. Not invented here syndrome is not okay when there are plenty of good (or at least "good enough" even if they're not my favorite) alternatives on the market already.

<comment><USER3> i'd argue that the Matrix.org Foundation is just as 'recognized' as the XMPP Standards Foundation :) In terms of disingenuousness - i'd argue that the definition of disingenuous is accusing us of reinventing the wheel rather than acknowledging that Matrix is an entirely different type of technology to IRC or XMPP. It's more similar to NNTP or Git than either IRC or XMPP. For better or worse, trying to solve existing problems using new approaches is how things evolve. On which note, it's cool to see delta.chat and COI trying a totally different approach too.

<comment><USER7> > i'd argue that the Matrix.org Foundation is just as 'recognized' as the XMPP > Standards Foundation :)

Recognized by whom? The XSF has standardized their core in IETF. Is there something similar for Matrix.org Foundation?

> trying to solve existing problems using new approaches is how things evolve.

What new approaches? You're just recreating federated IM network using different wire format. How on earth is it innovative or new? Using HTTP+JSON instead of TCP+XML is something new? Bridging to other IM networks is something innovative?

> Matrix is an entirely different type of technology to IRC or XMPP. It's more > similar to NNTP or Git than either IRC or XMPP.

I've heard this argument many times already, but the truth is that XMPP formally speaking is de juro an "XML routing protocol", but both XMPP and Matrix de facto are being used largely as IM protocols.

> For better or worse, trying to solve existing problems using new approaches > is how things evolve.

Since you invented nothing new, you evolve nothing.

<comment><USER3> > Recognized by whom?

The foundations responsible for the protocols look to be pretty similar to me (both non-profit orgs), and would be equally recognized as such by the general public. Obviously XSF contributed XMPP to the IETF after 10 years or so, and perhaps we'll end up contributing Matrix to IETF or W3C or whoever too if they'll have it.

> How on earth is it innovative or new? > Since you invented nothing new, you > evolve nothing.

 _sigh_ \- I wonder if the XMPP community would spend less time constantly complaining about Matrix if they understood what it was :/

The innovative bit of Matrix is that it's a replicated database of objects (events), similar to Git, but designed for syncing conversation history around in realtime. The events for a given room get replicated over all the participating nodes. There is no central server responsible for coordinating the room; instead all the participating ones do so equally. It's impossible to communicate with someone on a different node without effectively giving them a lazy-loaded HA replica of the room. Architecturally this is about as opposite of MUC (or MIX or FMUC or DMUC or whatever) as I can think of.

It's __NOTHING __to do with HTTP+JSON versus TCP+XML - Matrix can use whatever transport and encoding floats your boat. For instance, at FOSDEM we showed Matrix running over CoAP+CBOR to try to spell this out:[https://fosdem.org/2019/schedule/event/matrix/](https://fosdem.org/2019/schedule/event/matrix/).

<comment><USER8> Your description of the Matrix protocol reminded me of this, currently in development by the Atom/xray team: [https://github.com/atom/xray/tree/master/memo_core](https://github.com/atom/xray/tree/master/memo_core)

> Memo – Real-time collaboration for Git

> On its own, Git can only synchronize changes between clones of a repository > after the changes are committed, which forces an asynchronous collaboration > workflow. A repository may be replicated across several machines, but the > working copies on each of these machines are completely independent of one > another.

> Memo's goal is to extend Git to allow a single working copy to be replicated > across multiple machines. Memo uses conflict-free replicated data types > (CRDTs) to record all uncommitted changes for a working copy, allowing > changes to be synchronized in real time across multiple replicas as they are > actively edited. Memo also maintains an operation-based record of all > changes, augmenting Git's commit graph with the fine-grained edit history > behind each commit.

They intend to use this in their WIP xray editor - a possible future replacement for the Atom editor. Meno will be used to provide real-time multi- user collaboration for the editor, like Teletype for Atom: [https://teletype.atom.io/](https://teletype.atom.io/)

I occurred to me, that if your got repo contained chat history, then your edit would then be a chat client, with your chat history version and stored by git.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Looking at the documentation this looks to be at a very early stage, but after reading it I think it's mostly on the right track to become a very interesting platform... It's decentralised by design, has support for most things people expect (read notifications, group chats, polls, images, video, location, contact), almost every feature is usable by someone with a regular e-mail client and integrations should be very easy to develop (any e-mail library is good for developing a COI bot). Looking forward to a client and server to play around with... maybe I'll make my own as a toy!

</comment><comment><USER10> A German newspaper has some more information on that, for example that this is headed by Rafael Laguna of Open-Xchange [https://www.sueddeutsche.de/digital/whatsapp-konkurrent- open...](https://www.sueddeutsche.de/digital/whatsapp-konkurrent-open-source- rafael-laguna-1.4336574)

The aim seems to be to create a system that can replace centralized messenger solutions by allowing use of existing IMAP servers or hosting one yourself. I am not sure if this is correct but the article states that they are already supplying the software for three quarters of all IMAP servers worldwide and seem to be interested in connecting with Google to bring this to fruition.

Pretty interesting read (although only German) but it seems the marketing on this topic may have just started.

<comment><USER11> "COI uses an email address ... means it can already connect 3.8 billion users"

followed by

"After checking for server compatibility..."

Does this reduce the target pool? How much?

Also, how many people still use POP?

<comment><USER12> Looks like native COI compatibility on the server makes life easier for a client, and adds advanced features as opposed to restricting some servers from the party:

>"A COI client should check for COI support from the server first. it will CAPABILITY after having logged into the IMAP service. If the returned capabilities list contains the "COI" capability, then the client does not need to filter messages on the client side. It will also have more advanced options at its disposal, see the server side specifications for details."

The requirements are just an IMAP (or JMAP) server that conforms to the IMAP RFC:

>"The IMAP server may or may not be COI-compatible. The IMAP service MUST be compatible with IMAP v4rev1 as defined in RFC 3501, which is the case for almost any IMAP service in production." An SMTP service for sending messages. Sending services are also called Mail Transfer Agents (MTAs)."

</comment></comment></comment><comment><USER13> How is this different from [https://delta.chat](https://delta.chat) ?

<comment><USER14> Delta Chat is here, now, and has been for a while. It works on Android, Linux, MacOS and is being developed for iOS (limited function beta is available). There is no Windows client yet as far as I know. Delta chat has a simple and concise website which quickly comes to the point and does not try to upsell anything.

This... has a 'modern' website and not much more. The site starts with a page- filling image of a happy woman in an urban environment, she's clearly exited over something the lighted slab in her hand presents her. The thing sorely missing from the site is the download link and the link to the source repository where all those dreams are made true. It does contain one interesting piece of information though:

> _COI for Developers

COI is the only ecosystem that provides openness, a strong messaging basis AND overcomes the network effect. With COI you don't need to develop, host and maintain your own communication servers. Thanks to Delta Chat Core, as a client developer you do not even need to deal with IMAP directly._

Thanks to Delta Chat core... in other words, this is based on Delta Chat. According to one of the project founders they are cooperating with Delta Chat to ensure interoperability [1].

[1] [https://fosdem.org/2019/schedule/event/chat_over_imap/](https://fosdem.org/2019/schedule/event/chat_over_imap/) \- " _...We cooperate with Delta Chat open source project to bundle efforts and ensure interoperability. ..._ "

<comment><USER15> > According to one of the project founders they are cooperating with Delta > Chat to ensure interoperability

Great! Good luck to them.

</comment></comment></comment><comment><USER16> I really like the idea, but I prefer dedicated self-hosted services like Matrix. You can run a suspicious Matrix instance, but I think privacy falls away as you talk to any Gmail user via CoI.

"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!"

I don't find that so problematic. People just needs to see a bit the inner workings to feel a bit comfortable and give it a chance.

<comment><USER17> You can also run your own mail servers, even non-technical people could do that with for example [https://thehelm.com/](https://thehelm.com/). Haven't tried it out myself, though.

<comment><USER18> Which solves nothing if the other party's email is provided by Google. Google is still getting your chats.

<comment><USER19> XMPP and Matrix other people can host their servers on Google as well.

Fundamentally, if you don't trust the decisions of the person you are talking with, you can't guarantee the privacy of your chats.

<comment><USER16> You're forgetting E2E encryption.

<comment><USER20> Delta.chat supports E2E with other Delta users and Autocrypt email clients, so the point stands.

</comment></comment></comment></comment></comment></comment><comment><USER21> So due to HN cross-pollination, I'm now using Delta.Chat on my android which works a treat.

Hopefully once COI has a client, I can try that one out as well; if its android client supports multiple email accounts per install (unlike Delta.chat at the moment), it will almost certainly make its way into normal app rotation and evangelizing BBM/WA/Messages users to a more private, secure instant message client.

<comment><USER22> Interestingly COI is based on deta.chat, as per this comment in this thread. [https://news.ycombinator.com/item?id=19216346](https://news.ycombinator.com/item?id=19216346)

</comment></comment><comment><USER23> This is super clever, and I hope this takes off.

At the same time, I have to worry: SMTP is forever, but I'm not so sure that IMAP is forever.

Email is increasingly becoming a fragmented oligopoly, and the major players are promoting their own alternative protocols. IMAP is becoming a very optional legacy feature.

If the success of this project required additional integrations with EAS and Google's mail APIs, would you do the work or reject the idea on principle?

<comment><USER24> > SMTP is forever, but I'm not so sure that IMAP is forever

Indeed. I was surprised to see that Tutanota, a German privacy-oriented e-mail provider, only provides access via their web front-end. They don't support IMAP because according to them, they couldn't provide end-to-end encryption in combination with full-text search.

</comment></comment><comment><USER25> This is great and all, but you're relying on IMAP, an inherently mobile- unfriendly protocol. They should have worked with Fastmail to get this into JMAP.

<comment><USER26> I would have pointed you to their issue tracker, but all I can find is a horrible Confluence wiki. Kind of discouraging for potential contributors.

There is a mailing list though. At the very least they might add a 'why not (also) JMAP' bullet point to the website if you ask about it:

> […] join the COI developer mailing list by sending a mail to dev-join@coi- > dev.org.

I would guess that they need IMAP to prevent the whole 'nobody uses it' problem.

<comment><USER17> The specs will soon be available on GitHub soon. If the server supports JMAP, there are no principle obstacles to also support COI over JMAP. But as said, currently the market share of JMAP is neglible.

<comment><USER27> i assume for this to work remotely ok the imap idle is a must. also how is it supposed to work on the receiving site ? There has to be some "Folder" where those messages are stored and the imap idle should listen to that folder or else my inbox will be huge mess and mess with my regular mail client.

also was there any tests how long does it take for delivery, because the message could hop around and could be scanned, added addotional headers or mess with those there.

</comment></comment></comment></comment><comment><USER28> If it's basically two mails clients sending emails quickly to eachother, is there anything there that will make sure the user doesn't fill his inbox with tons of "hi","how are you" emails?

Does it delete the messages that were read, or something? If it's really going to put all the messages,is it using some kind of dedicated folder?

<comment><USER29> Chat messages will land in a separate folder for the servers that support COI. For the others they will be collated into normal mail messages with a small delay, but yes, it may end up being many.

</comment></comment><comment><USER30> I think this could be a great solution, but consider going after Slack rather than Whatsapp to being with. Unusually I think enterprise customers will make better early adopters than consumers, as they don't care about network effects and their technological inertia actually aligns with your selling point - <USER2> it is a thin protocol on top of email.

Once people use this for their professional email address they may start to using it for their personal one too.

<comment><USER26> The alternative for Slack is MatterMost, which you can host on-premise, and is free. I can heartedly recommend it.

It's just not an urgent a problem as this is.

<comment><USER31> I've ran a mattermost instance for several years now. Works pretty well, actually better as the years have gone by.

</comment></comment></comment><comment><USER32> I have seen other users bring this up, so I think it should be stated in its own parent comment: most of the public uses yahoo or gmail to host their email, so chatting with them is all tracked by yahoo or google. That is something that needs to be addressed.

</comment><comment><USER33> I like this idea. I could build a client and compete in the messaging space with this tomorrow. As a developer having come of age in a world ruled by FB Messenger, iMessage, Whatsapp etc, this is a whole new freedom and opportunity.

I'm aware that these battles have all been fought in the MSN/ICQ/AIM era too, but it looks like we're going to have to fight them again.

</comment><comment><USER34> It is very difficult to build a decent email client with IMAP. So initially thought it is a no-sense. But after reading the while proposition seem very intriguing. Although it is based on email adoption will be very difficult.

<comment><USER35> > It is very difficult to build a decent email client with IMAP

Why do you say that? I've implemented a couple of embedded IMAP clients over the years and I always found it pretty OK to work with?

<comment><USER36> One issue is that not everyone uses IMAP. What's with POP3 users (they still exist) and Exchange users?

<comment><USER37> It's not unusual for Exchange servers to have IMAP support enabled. Many organizations have bought into Microsoft's subscription model, use O365 for email instead of running Exchange servers themselves, and typically won't disable IMAP access.

</comment></comment></comment></comment><comment><USER17> Thanks all for the great discussion here. We compiled what we can answer into this new FAQ:

[https://confluence-public.open- xchange.com/display/CoiW/FAQ](https://confluence-public.open- xchange.com/display/CoiW/FAQ)

</comment><comment><USER38> I like the spirit of this idea. I'm glad to see existing technologies being leveraged. However, it still seems quite a dog's breakfast of parts and pieces that don't all seem to be necessary.

I'd like to see this split out into several parts, which could then be used together if necessary.

The basic idea -- how to format and transfer short-form (chat-style) messages using existing email standards -- is brilliant. This seems similar to how AMP describes a limited set of HTML, and would be worth defining carefully.

The management of distributed contacts and group lists seems to be a different problem entirely. Personally, I don't need this: I'm fine with using my existing address/contact lists of trusted friends, along with time-tested tools like mailing lists.

The idea of editing/deleting messages seems superfluous and complicated. I've never knowingly used a chat system that provided this feature, nor have I ever wished I had it.

Maybe I missed something, but I didn't see anything about how SMTP would be used. It seems that by the time a short message is wrapped up into its attachments and headers, then sent to to the appropriate SMTP server (along with login & negotiation), I've probably sent over 20KB. That's a lot of data for one tiny message.

I would love to be able to use COI without a special client at all, just my current email client. However, the spec seems to require certain headers that would generally be difficult to configure in most email clients.

I'm concerned that the spec does not include any discussion of error handling. There are many things that can go wrong, especially with an asynchronous protocol like SMTP/IMAP. How are those problems going to be handled?

<comment><USER29> A couple of answers here [https://confluence-public.open- xchange.com/display/CoiW/FAQ](https://confluence-public.open- xchange.com/display/CoiW/FAQ)

</comment></comment><comment><USER39> I mean all this really is is two people sending email really quickly to each other....

<comment><USER40> And all email is is two people sending telegraphs really quickly to each other....

<comment><USER41> I mean metaphorically sure, but in this case it's literally using the exact same system; it's just the clients are changed to look like a chat app instead of an email app. This is more like if two people were sending telegraphs over actual telegraph lines, with morse code and everything, then at the end they type it up into a Word document and say "It's email!"

<comment><USER42> And? What makes "chat" is synchrony and to a certain extent UI, not transport protocol.

<comment><USER29> Yeah, so why not put everything in one bucket that you control, your mailbox. Part of the idea.

</comment></comment></comment></comment></comment><comment><USER43> This is interesting.

Wouldn't it be possible and transparent to the protocol to use PGP for end-to- end message encryption? If the recipient has a public key, the client can automatically use that and the recipient's client could automatically decrypt it.

</comment><comment><USER44> I've created a frontend router/store which allows to make whole backendless applications which share the state by emails: [http://router.maniak.pro](http://router.maniak.pro)

</comment><comment><USER45> I wonder how COI will perform battery and latency wise. I mean, if an email is delivered within 30 seconds to the recipient, that is considered fast, but if instant messengers take that long you wonder what is broken.

<comment><USER46> That's a funny take, considering my experience. I know some email servers are slow, of course, but they don't have to be. When I worked on Gmail, the majority of Gmail-to-Gmail messages were delivered in under a second, and not because they have a special internal protocol; even such internal messages are sent over SMTP. But Gchat was never that fast. 1 second was considered fast delivery by Gchat but it was long tail slow for Gmail.

</comment></comment><comment><USER47> I really don't like that the client would require full access to your e-mail account.

Otherwise it's pretty neat.

<comment> mike-cardwell That's like complaining that your web browser gets full access to your browsing history, or that your IM client gets full access to your plain text conversations, _even_ when using E2E encryption no less!

<comment><USER47> No, it's like complaining your IM gets access to your e-mail conversations. Or browser gets full access to your phone calls history.

Access to your e-mail account allows you to reset password in most services associated with it.

<comment> mike-cardwell No, it's a client that uses your email account for purposes involving reading and sending email. Exactly like Thunderbird, or Evolution Mail, or Outlook, or Android Mail, or iOS Mail or countless other clients that have full access to your email client by design, and without issue.

People generally take issue with handing over access to their email account to third party services. People don't generally take issue with a client under your control accessing an account under your control.

<comment><USER47> OK, fair enough, depends who provides the app. So far the project author(s) seem anonymous.

(And no, the fact of being open source is not enough, at least not until certain popularity is reached)

I've tried many XMPP clients on mobile but I would be afraid to test many e-mail clients.

<comment><USER29> We are [http://www.open-xchange.com](http://www.open-xchange.com), [http://www.dovecot.org](http://www.dovecot.org) plus people from the Delta Chat community and [http://spikenow.com](http://spikenow.com) \- plus whoever whats to join.

</comment></comment></comment></comment></comment></comment><comment><USER48> E-Mail got extended as much as it could and COI doesn't change anything about it. If you want something like COI you can use deltachat [https://github.com/deltachat/deltachat- android](https://github.com/deltachat/deltachat-android) I couldn't find any specification about anything (encryption, contacts, group-chats,...) and the worst part is that it doesn't even solve the arbitrary problems it poses itself. privacy? Fat chance when you use E-mail. "big bad providers" (yes that is the summary of all the other "points") you still have those too

And the solutions that are there and work like matrix or xmpp are no solution, because of user adaption? Hello... Users have to adapt your "protocol" as well and I don't see any added value... It's just an idea for chat over email which I can do right now with the right Client.

Ps matrix AND xmpp both support bridges for other protocols.

Pps they miss the point of what is needed most right now/what the problem is.

Pps [https://xkcd.com/927/](https://xkcd.com/927/)

Edit while writing others postet the same stuff I postet

<comment><USER49> Surely it will use TLS for encrypted transport.

<comment><USER48> That doesn't mean the connection between all servers is encrypted (smtp can be routed through multiple servers) nor does it mean that google or whatever server the data get stored on/routed through can't read your communication.

The whole thing just sets a low bar because it can't implement all the things other messengers already support (for instance not disclosing who you are talking to)

</comment></comment></comment><comment><USER50> I'd like to try this or the similar delta.chat, but have thousands of confidential/sensitive e-mails on my account and don't know what these clients will do to/with them. It's also not an ideal situation from a security perspective (a lot of damage could be done if the clients are exploitable).

</comment><comment><USER51> I understand that from a protocol perspective this is more open, so your data is not going into another silo like Signal etc.

From a consumer standpoint, isn't it still true that you still need to get people to use the new client(s)? (It's not like gmail/hotmail/yahoo/etc. email service providers automatically have a COI client on top of their email client) In the end, you still have the network problem, of getting people to switch over?

That would make statements like this a little bit deceiving: "You can also reach everyone, there are more than double active email users than WhatsApp users, for example."

Yes, all email users (who use services that support IMAP) are technically automatically "users" of this, but before they start using your client, you still can't chat with them over COI. Or is there fall back to email?

<comment><USER52> It explains on the site that it falls back to email. Basically an abstraction layer for real time chat built on top of email.

</comment></comment><comment><USER53> Hey everyone. I don't want to start a debate or anything, I'm just looking for a privacy concerned chat service that I can easily teach my fiance to sign up for and use. She gave up on Pidgin, and I would appreciate any pros/cons for your favorite service of this kind. Thank you in advance!

<comment><USER54> We use Wire. In some respects it's more useful than Signal, because it works on mobile, desktop and web. I think the desktop clients are Electron based, so I use the mobile and the web apps. You don't necessarily need a phone number, it can also use an e-mail address, so it works just fine on the desktop. It also has voice chat and conference. Oh and a good part of it is open source, although it's uses a centralized server.

<comment><USER55> I second the Wire recommendation because you can sign up with an email address, and conversations sync across devices. Its feature set is also good (not as good as Telegram) and improving. I wouldn't recommend Signal as it is still poor in features, speed and stability.

 _With Signal you cannot carry your chats to a new device (this is prohibited by design in the app on iOS)!_

If you want to experiment, try both Wire and Signal at the same time, and you'd observe the differences quickly.

</comment></comment></comment><comment><USER56> In case anyone missed it, here is version 1.0 of the spec. Not yet an RFC.

[https://confluence-public.open- xchange.com/display/CoiW/COI+...](https://confluence-public.open- xchange.com/display/CoiW/COI+Client+Specification+v1.0)

<comment><USER57> thank you!

it's like the only possibly important thing about this and nobody has mentioned that the COI web front runs into nothing when you follow URL toward an RFC:

[https://www.coi-dev.org/popup2?type=1000](https://www.coi- dev.org/popup2?type=1000)

it's a blank page that says they think RFC is essential, which is surely a valid opinion :)

</comment></comment><comment><USER58> What about latency? I don't think a few seconds (or even minutes) are acceptable for Instant Messaging...

[https://askleo.com/long-email-delivery-take/](https://askleo.com/long-email- delivery-take/)

</comment><comment><USER59> The biggest problem with IMAP from my point of view is spam, that is why there is only a couple of email providers in the world, although still decentralized, they trust each other more than any newcomers, which is kind of preventing this initiative.

<comment><USER60> IMAP is for receiving.

<comment><USER61> IMAP is for retrieving. SMTP is for receiving. And sending.

</comment></comment></comment><comment><USER62> Why not build a chat oriented email client instead?

<comment><USER63> Isn't that basically what this is?

</comment></comment><comment><USER64> Doesn't this bring a large overhead since you're sending a ton of header stuff for each short message?

It's true that email is really the number 1 mean of communication, but I wonder if it's not ton and ton of added layers to make it modern enough.

And as it was mentioned, I'm not sure email is really good enough for mobile and other constrained bandwidth.

I might be wrong, but email headers are pretty scary.

In the end, I wonder if any old protocol shouldn't be upgraded, things made deprecated, etc. Every decade or so, protocol should be sanitized.

<comment><USER29> We thought of that a lot. But like our other baby, [http://id4me.org](http://id4me.org) \- where we chose use use DNS and OpenID and mesh it into a federated identity protocol - email infrastructure is simply _there_ , it's federated, robust, run by millions of servers, large and small, tested, filtered, pounded, drowned, abused you-name-it. That buys some extra overhead.

</comment></comment><comment><USER65> "Last but not least, every COI client app can offer a variety of end to end encryption options to keep your communication absolutely private."

The fact I had to read quite so far down the page to find this snippet emphasises to me how unimportant the developers of this protocol see E2E encryption to be :( And leaving it to the client seems like a terrible idea, especially if there are options, as then surely it will depend on what E2E encryption options your and your recipient's clients supports?

<comment><USER66> I don't really understand why or how this is different from your current trust model around email...?

<comment><USER67> I think that was OP's point?

To tout it as an alternative, or "breaking free" of WhatsApp, is to discredit one of the pivotal reasons that people use WhatsApp, which is E2E encryption.

<comment><USER68> I think most people who use WhatsApp don't even know what E2E encryption is and use it only because their peers are using it.

<comment><USER26> _The_ pivotal reason people use WhatsApp is because it can be used without paying (with money that is), _and_ because up to 90% of people in any country use it¹.

That's it. Facebook could remove E2E today, and lose only a fraction of its WhatsApp users. Of course many little annoyances might mean that a competitor may step up, but WhatsApp is incumbent, and this is no longer about features or technology. It's all about the fact that your friends, family, and colleagues are using it. It can safely ride the network effect for years.

I welcome any protocol that makes chat something that is available for everyone with a computing device again — not just on approved smartphone operating systems.

1: Varies quite a bit per country.

<comment><USER5> It must vary a lot. I live in the United States and I've never encountered anyone who wanted to communicate over WhatsApp.

<comment><USER69> In South Africa WhatsApp is almost required. It's ubiquitous.

In Germany I'd say it's by far the most common chat client, even my parents use it.

<comment><USER70> Same in UK, I installed it as almost all my (relatively non-technical) friends and family were using it. It's much more commonly used than Facebook, or email, for direct to groups communications.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER71> Neat. Might be worth implementing for Purelymail, but I'd have to roll my own since I don't use Dovecot. Maybe best to wait for the RFC?

</comment><comment><USER72> This is great but won't we be quickly limited by most providers Email Sending Limits? With IM you're quickly over 100 messages per day.

</comment><comment><USER73> I work for a large consumer facing mail provider. Imap is easily 60% of our cost because it's a very inefficient protocol. Also, we can't put ads in 3rd party imap clients. So we make zero revenue from them. COI will exacerbate the problem. I wonder how we will solve this problem.

</comment><comment><USER74> The problem with smtp and imap is it doesn't work over proxies, which a lot of places still use.

<comment><USER75> Are there many proxies which don't allow IMAP?

</comment></comment><comment><USER76> Are Google, Apple, Microsoft, and other large email providers likely to implement a protocol like this into their own servers? It seems like a major conflict of interest, and without them it is a _massive_ portion of the market that will never see this service work.

<comment><USER77> If I interpret the homepage correctly clients/servers without extra COI enhancements will just receive the messages as emails. Not ideal, but in any client with threading (gmail, apple), it would work decently i guess.

<comment><USER78> According to the spec ([https://confluence-public.open- xchange.com/display/CoiW/COI+...](https://confluence-public.open- xchange.com/display/CoiW/COI+Client+Specification+v1.0)) clients are expected to ask the IMAP server using a CAPABILITY command whether it supports COI extensions. Whether or not the server does support COI, messages are indeed standard mails with an extra Chat-Version: header and the requirement that Message-Ids start with "coi$".

So an existing server need not do anything to support COI clients. But a _malicious_ server could easily decide to reject them, or to filter out COI- specific stuff from messages. I don't think it's _likely_ , but it sometimes big corporations and governments get paranoid about weird things ("network load!!1!") and take technical measures to block them.

<comment><USER23> I wouldn't be surprised if COI encounters issues with automated abuse detection and spam filters in those servers. When you're in an active conversation, the client is rapidly sending 1-line emails with strange headers.

</comment></comment></comment></comment><comment><USER79> "COI uses an email address and any IMAP server as its infrastructure. This means it can already connect 3.8 billion users - anyone with an email address"

Email <> IMAP even though most email providers do provide access to IMAP, this is greatly oversimplified.

<comment><USER80> If I understood it correctly, only your side needs IMAP.

From there outwards the protocol (degrades to/can use) regular mail/smtp, so you can indeed connect with any address capable of receiving email.

</comment></comment><comment><USER81> Seems to me that XMPP already covers all these use cases of COI? Both XMPP and email use essentially the same addressing format but XMPP uses XML formatted messages whereas email uses HTML formatted messages (it's worth noting that XMPP used to support HTML messages).

So you could "send an email" in XMPP just by composing a message and sending it to what amounts to an email address (technically the bare JID). The XMPP client would just need to close the chat window after sending the message to make it seem like typical email experience.

XMPP also has the advantage that it was designed with the IM and multi-user chat use cases in mind (e.g. chat state notifications, message corrections, moderated/members-only chatrooms, etc.) but also can support email use cases.

I think it's easier just to set up your XMPP server to handle IMAP authentication.

</comment><comment><USER82> Anyone else getting a Cisco - warning about malware.opendns.com on the Wiki? wiki.coi-dev.org. It's blocked to me at work on this url. wiki.coi- dev.org&server=lon16&prefs=&tagging=&nref

</comment><comment><USER32> This would be awesome to make an embeddable, html form, so essentially any website you want to share links with your friends from, can be done on the website itself coming from your email address.

</comment><comment><USER83> I remember Microsoft having a chat service build on top of email 2 or 3 years ago, it was called "Send". Whatever happened to it..

</comment><comment><USER84> They will have a problem with greylisting mail.

<comment><USER84> Oh wait, they will not. I can not find any reference to a working client implementation on their website.

Are they expecting others to write implementations?

<comment><USER17> That's one client we are working on. That client uses delta.chat core to which we are also contributing.

<comment><USER9> That's great, I'm really excited about your project.

</comment></comment></comment></comment><comment><USER85> This has potential. We have too many proprietary chat systems now.

How does it avoid spoofing of addresses and spam?

</comment><comment><USER86> I love this but it kind of rules out webapps as clients, no? Who would give their email password to one?

<comment><USER87> Fastmail generates a password for applications that you give access, so you never actually share your real password. I imagine they could use a solution like this.

</comment></comment><comment><USER88> I was wondering a long time, why we don't have chats with user@domain like email or mastodon.

</comment><comment><USER89> All it has to do really is to do some TCP magic so that the messages can flow peer-2-peer!?

<comment><USER29> Current thinking is that the IMAP servers connect directly, but via SMPT for message transfer, but without the store-and-forward, once they are trusted via a token exchange. May be blocked though in server deployments (ports).

</comment></comment><comment><USER90> Nice idea but don't email providers have hard limits on daily sent emails?

<comment><USER43> Never heard of such a thing. Do they?

</comment></comment><comment><USER91> Perhaps a helpful sidebar: This website loads painfully slow.

</comment><comment><USER92> Chat over IMAP, isn't that just email... :)

</comment><comment><USER93> looks like google used it way before but nobody was interested (google hangout)

</comment><comment><USER94> Very bad choice of design for the website. I'm supposed to be interested in this, but this website looks like they're trying to sell me some multi-million contract.

<comment><USER95> Maybe we are looking at different websites (im viewing from a desktop), but I found it very easy to read and access the information I required.

<comment><USER96> Too much white space. They could have condensed it quite a bit. And who needs a hero image that big anyway? That was "modern" when people just started using the word "modern". Like using the word "modern" now, it's pretty dated.

<comment><USER95> Whats the modern word for "modern"?

<comment><USER97> Modern. But beware, it's pretty dated. :)

</comment></comment></comment></comment></comment><comment><USER98> This idea is dangerously simple.

All the same email is pretty siloed, for personal addresses. Running your own server is a hassle for anyone,and the most popular provider stopped being "not evil" some time since 2004 when I got my address there.

<comment><USER99> Running your own server is not a hassle for "anyone". I wish people would stop stating this like it's a fact. Having maintained communal SMTP/IMAP servers for the last 20+ years I can tell you that sometimes a year goes by where I don't have to touch it at all.

</comment></comment><comment><USER100> What of network effect? And in today's fragmented, firewalled and NATed internet, what of ! --dport 80,443 -j DROP?

<comment><USER95> it works over regular smtp and imap, via your usual relays and email servers, etc. If you can send and receive email, then I guess it should work fine.

<comment><USER100> If you can send and receive email, then I guess you have been bitten at least once by its store-and-forward, best-effort nature. In other words, no guarantees on message delivery time (two days delayed? Working as designed!), message ordering, or even whether it's delivered at all. I literally know of no worse medium for chat than email, even considering raw ethernet frames and pigeon post.

"It is sort of available everywhere" is email's only selling point - that's not enough to justify "let's build everything on top of it".

</comment></comment></comment><comment><USER101> IMAP is basically just a way for attackers to test credentials. You should be very very careful about enabling IMAP. Hopefully you (or your provider) are watching the logs and can respond to abnormal login attempts.

<comment><USER102> Huh? What should we be using instead? Surely not POP.

<comment><USER103> obviously we should all use webmail and leave our email locked away to one provider</comment></comment></comment>