COI – Chat Over IMAP

> 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 :)

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!

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...

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.

How is this different from https://delta.chat ?

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.

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.

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?

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.

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?

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 - that 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.

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.

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.

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.

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

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?

I mean all this really is is two people sending email really quickly to each other....

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.

I've created a frontend router/store which allows to make whole backendless applications which share the state by emails: http://router.maniak.pro

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.

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

Otherwise it's pretty neat.

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 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/

Edit while writing others postet the same stuff I postet

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).

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?

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!

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+...

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/

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.

Why not build a chat oriented email client instead?

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.

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

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?

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.

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.

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

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.

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

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.

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

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.

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..