
COI – Chat Over IMAP - smartmic
https://www.coi-dev.org/
======
Arathorn
> 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 :)

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

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

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

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

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

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

~~~
Arathorn
> 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/).

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

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

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

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

~~~
bharrison
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)."

------
dmacvicar
How is this different from [https://delta.chat](https://delta.chat) ?

~~~
Yetanfou
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. ..._ "

~~~
gregknicholson
> According to one of the project founders they are cooperating with Delta
> Chat to ensure interoperability

Great! Good luck to them.

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

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

~~~
deadbunny
Which solves nothing if the other party's email is provided by Google. Google
is still getting your chats.

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

~~~
elvecinodeabajo
You're forgetting E2E encryption.

~~~
qot
Delta.chat supports E2E with other Delta users and Autocrypt email clients, so
the point stands.

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

~~~
javajosh
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)

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

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

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

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

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

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

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

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

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

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

~~~
jonnycomputer
I've ran a mattermost instance for several years now. Works pretty well,
actually better as the years have gone by.

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

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

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

~~~
Tharkun
> 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?

~~~
Tepix
One issue is that not everyone uses IMAP. What's with POP3 users (they still
exist) and Exchange users?

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

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

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

~~~
rafbuff
A couple of answers here [https://confluence-public.open-
xchange.com/display/CoiW/FAQ](https://confluence-public.open-
xchange.com/display/CoiW/FAQ)

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

~~~
repler
And all email is is two people sending telegraphs really quickly to each
other....

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

~~~
throwanem
And? What makes "chat" is synchrony and to a certain extent UI, not transport
protocol.

~~~
rafbuff
Yeah, so why not put everything in one bucket that you control, your mailbox.
Part of the idea.

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

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

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

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

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

Otherwise it's pretty neat.

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

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

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

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

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

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

~~~
kwhitefoot
Surely it will use TLS for encrypted transport.

~~~
BlackLotus89
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)

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

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

~~~
robgibbons
It explains on the site that it falls back to email. Basically an abstraction
layer for real time chat built on top of email.

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

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

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

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

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

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

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

~~~
gsich
IMAP is for receiving.

~~~
arbitrage
IMAP is for retrieving. SMTP is for receiving. And sending.

------
lcnmrn
Why not build a chat oriented email client instead?

~~~
LeoPanthera
Isn't that basically what this is?

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

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

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

~~~
Aeolun
I don’t really understand why or how this is different from your current trust
model around email...?

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

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

~~~
Freak_NL
_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.

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

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

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

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

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

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

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

~~~
e1ven
Are there many proxies which don't allow IMAP?

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

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

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

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

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

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

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

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

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

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

------
sam_lowry_
They will have a problem with greylisting mail.

~~~
sam_lowry_
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?

~~~
enough
That's one client we are working on. That client uses delta.chat core to which
we are also contributing.

~~~
ttsda
That's great, I'm really excited about your project.

------
Animats
This has potential. We have too many proprietary chat systems now.

How does it avoid spoofing of addresses and spam?

------
pwpwp
I love this but it kind of rules out webapps as clients, no? Who would give
their email password to one?

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

------
_trampeltier
I was wondering a long time, why we don't have chats with user@domain like
email or mastodon.

------
z3t4
All it has to do really is to do some TCP magic so that the messages can flow
peer-2-peer!?

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

------
ecabuk
Nice idea but don’t email providers have hard limits on daily sent emails?

~~~
kyberias
Never heard of such a thing. Do they?

------
codereflection
Perhaps a helpful sidebar: This website loads painfully slow.

------
os2mac
Chat over IMAP, isn't that just email... :)

------
24daemon
looks like google used it way before but nobody was interested (google
hangout)

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

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

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

~~~
supermatt
Whats the modern word for "modern"?

~~~
pofjer
Modern. But beware, it's pretty dated. :)

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

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

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

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

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

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

~~~
0xffff2
Huh? What should we be using instead? Surely not POP.

~~~
ronsor
obviously we should all use webmail and leave our email locked away to one
provider

