21 ms·

COI – Chat Over IMAP

660 points by smartmic 8y ago

os2mac 8y ago
Chat over IMAP, isn't that just email... :)
deleted 8y ago
[deleted]
FlatL1ne 8y ago
Hack the Planet
vermilingua 8y ago
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.
- MattHeard 8y ago
  Are server-side changes needed?
  - vermilingua 8y ago
    > The COI ecosystem is the COI Standard plus compatible Client Apps and Email Servers. > COI works with all email severs, but IMAP servers can be enhanced with extra COI capability. I’d take this to mean that no, changes are not explicitly required; but without the changes COI functions the same as email, but in an IM interface.
    - NonEUCitizen 8y ago
      They have a description of the client but I could not find a description of the optional server-side enhancements (besides that it should be advertised via CAPABILITY).
      - Mailtemi 8y ago
        Chat over IMAP seem a bit misleading title. Their proposition is to add additional info in MIME headers. Or later some of them like Message-Id with chat info. So seem more related to MIME and SMTP. A client app can get those headers with different protocols too. MAPI, EWS, JMAP, etc.
        enough 8y ago
        We are working on server specs, the idea is that certain functionality like WebPush, WebRTC calls, channels require the servers to support COI.
        Mailtemi 8y ago
        Do you know, is it going to have a demo/beta server just to play it.
        rafbuff 8y ago
        Chat over SMTP/IMAP/MIME just doesn't sound right, or does it? We also thought of Chat over Email, or Chat over Mail, But Chat over IMAP gave us the COI (fish), which we love. Decision made :)
        chrismorgan 8y ago
        Chat over Email is so much clearer as a name.
- LoSboccacc 8y ago
  > likely to implement a protocol like this into their own servers? just on the homepage "Since this is all based on email, you can communicate with users even when they do not have COI-compatible servers or apps." the likely side effect is that you'd need to filter out chats messages into a folder or something to reduce the inbox clutter
- Epskampie 8y ago
  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 8y ago
    According to the spec (https://confluence-public.open-xchange.com/display/CoiW/COI+Client+Specification+v1.0 https://confluence-public.open-xchange.com/display/CoiW/COI+...) 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 8y ago
      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.
- supermatt 8y ago
  The service works as a layer on top of standard email. There will be optional IMAP extensions to reduce the overhead.
- dexterdog 8y ago
  Google already has IMAP. I don't know about the other two, but I would be surprised if they don't.
- davewritescode 8y ago
  I've browsed through the spec and it looks like servers likely won't need to change anything. Most of the interaction between clients happens via mail headers. I really like this idea
Piskvorrr 8y ago
What of network effect? And in today's fragmented, firewalled and NATed internet, what of ! --dport 80,443 -j DROP?
- supermatt 8y ago
  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 8y ago
    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".
Mailtemi 8y ago
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 8y ago
  > 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?
  - Mailtemi 8y ago
    I'm implementing mobile client too :) To sync all mailboxes, not just Inbox need a lot of commands (request/response). Which add a lot of latency which is not very user-friendly on mobile. For example currently, I' exploring JMAP and for the same amount of functionally, the API calls a just 1/10th of what needed with IMAP.
  - Tepix 8y ago
    One issue is that not everyone uses IMAP. What's with POP3 users (they still exist) and Exchange users?
    - extra88 8y ago
      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.
    - rafbuff 8y ago
      POP-only mailboxes are pretty rare these days. A lot of users still use POP, but I guess mostly because they configured the mail client a decade or two ago and are not touching it again.
  - hombre_fatal 8y ago
kfwhp 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      Whats the modern word for "modern"?
      - pofjer 8y ago
        Modern. But beware, it's pretty dated. :)
kelnage 8y ago
"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 8y ago
  I don’t really understand why or how this is different from your current trust model around email...?
  - calgoo 8y ago
    IMO its comparing itself to Whatsapp and other messaging apps that do have end to end encryption. Thats why the current email trust model is not as important.
  - renholder 8y ago
    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 8y ago
      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 8y ago
        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.
tompccs 8y ago
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.
- vermilingua 8y ago
  No, that’s right, they don’t care about network effects; enterprise customers care about a SLA above everything else. An open protocol cannot provide a SLA.
- Freak_NL 8y ago
  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 8y ago
    I've ran a mattermost instance for several years now. Works pretty well, actually better as the years have gone by.
- jbverschoor 8y ago
  "Once people use this for their professional email address they may start to using it for their personal one too." It's usually the other way around.
Y_Y 8y ago
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 8y ago
  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.
dmacvicar 8y ago
How is this different from https://delta.chat https://delta.chat ?
- supermatt 8y ago
  Primarily I guess this is an open specification, whereas deltachat is a closed app? sounds like the same underlying principle to me though. Apparently in the future there would be optional extensions on IMAP servers to make things more efficient. EDIT: looks like delta.chat is open source https://github.com/deltachat/deltachat-desktop https://github.com/deltachat/deltachat-desktop
  - dmacvicar 8y ago
    Deltachat is opensource for every platform it supports: https://github.com/deltachat https://github.com/deltachat It also includes a core library in C: https://github.com/deltachat/deltachat-core https://github.com/deltachat/deltachat-core The spec is documented here: https://github.com/deltachat/spec/blob/master/spec.md https://github.com/deltachat/spec/blob/master/spec.md
- Yetanfou 8y ago
  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. ..."
smush 8y ago
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 8y ago
  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
the_librarian 8y ago
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!
- e1ven 8y ago
  Signal is probably the best combination of easy-to-use/secure.
  - tlynchpin 8y ago
    Signal doesn't support vcard which makes it a non-starter for many people [0][1]. [0]: https://github.com/signalapp/Signal-Android/issues/6520#issuecomment-304572373 https://github.com/signalapp/Signal-Android/issues/6520#issu... [1]: https://github.com/signalapp/Signal-Android/issues/6520#issuecomment-370671001 https://github.com/signalapp/Signal-Android/issues/6520#issu...
    - jka 8y ago
      Interesting comment. How frequently do you think this one vcard-related issue you linked to is a problem for Signal users trying to share contact information with each other? And could you give an example story illustrating how two users would run into this issue in practice?
- Fiaxhs 8y ago
  I would use Signal, quite simple and privacy focused.
- kevingrahl 8y ago
  I personally love Threema [1], which is available for iOS, Android, Microsoft and Web. It uses a random ID to identify users, uses End-to-end encryption, you can make voice calls, send messages, audio messages, GIF’s etc.. Oh, and it has a dark theme! Please note that Threema is not open source. If you want that go for Signal instead. [1] - https://threema.ch/en https://threema.ch/en
ttsda 8y ago
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!
m0dest 8y ago
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 8y ago
  > 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.
Illniyar 8y ago
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 8y ago
  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.
elamje 8y ago
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.
elamje 8y ago
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 8y ago
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.
elvecinodeabajo 8y ago
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 8y ago
  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 8y ago
    Which solves nothing if the other party's email is provided by Google. Google is still getting your chats.
    - richardwhiuk 8y ago
      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 8y ago
        You're forgetting E2E encryption.
        qot 8y ago
        Delta.chat supports E2E with other Delta users and Autocrypt email clients, so the point stands.
Arathorn 8y ago
> 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 8y ago
  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.
  - rschulman 8y ago
    This is completely the opposite of my experience. I'm in probably a dozen Freenode channels via bridge and another 5-6 Mozilla IRC channels, and haven't had a problem in as long as I can remember.
    - jlkuester7 8y ago
      Same. It was a little 'interesting' to get setup (because IRC) but all-in-all it works great!
  - Arathorn 8y ago
    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/msc1763/proposals/1763-configurable-retention-periods.md https://github.com/matrix-org/matrix-doc/blob/matthew/msc176... etc.
comboy 8y ago
I really don't like that the client would require full access to your e-mail account. Otherwise it's pretty neat.
- mike-cardwell 8y ago
  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 8y ago
    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 8y ago
      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 8y ago
        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 8y ago
amaccuish 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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.
sam_lowry_ 8y ago
They will have a problem with greylisting mail.
- sam_lowry_ 8y ago
  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 8y ago
    That's one client we are working on. That client uses delta.chat core to which we are also contributing.
    - ttsda 8y ago
      That's great, I'm really excited about your project.
  - rafbuff 8y ago
    And yes, we want to open the chat ecosystem to many many cool clients made by you all for every taste and use case. Beyond the obvious WhatsAppySnappyChattySlacky varieties, if you think it through, you can even envision Twitter and Facebook-like clients. Sounds crazy but we cannot imagine why not. Plus normal Email clients can be seriously pimped.
davidhbolton 8y ago
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
AnnoyingSwede 8y ago
"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 8y ago
  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.
xDest 8y ago
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-source-rafael-laguna-1.4336574 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.
- richardwhiuk 8y ago
  Note: > three quarters of all IMAP servers doesn't not mean 3/4 of internet users (e.g. I expect Google's IMAP servers represent a disproportionately large number of users). Dovecot is likely more likely to be used by a long tail of smaller nodes.
  - rafbuff 8y ago
    We have about 7bn total unique active (3 months) accounts in the world, 50-60% is Gmail, Outlook.com, Yahoo and a few more, 40-50% are real IMAP servers, of which 76% use Dovecot. Very large deployments include companies like Comcast, Deutsche Telekom, 1&1, LGI (Ziggo, Virgin Media, UPC) with 10m+ user deployments, and yes, a veeery long tail of millions of small servers and anything in between. But COI will also play fine with GMail and friends.
- colinprince 8y ago
  "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?
  - rafbuff 8y ago
    You will be able to chat via email even if the IMAP backend does not (yet) support COI. You lose features, though.
madmaniak 8y ago
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
kevinsimper 8y ago
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 8y ago
  IMAP is for receiving.
  - arbitrage 8y ago
    IMAP is for retrieving. SMTP is for receiving. And sending.
    - deleted 8y ago
      [deleted]
arendtio 8y ago
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.
- enough 8y ago
  >90% of mails are delivered really in a couple of seconds, but yeah, turnaround could be quicker. That's why in the longer run we hope to skip the store-and-forward mechanism and instead deliver mails directly by IMAP server to IMAP server.
- shereadsthenews 8y ago
  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.
- deckar01 8y ago
  I doubt most email servers actually take anywhere close to 30s to process an email. I suspect most of the delay is the sending server queueing and email client polling intervals.
z3t4 8y ago
All it has to do really is to do some TCP magic so that the messages can flow peer-2-peer!?
- rafbuff 8y ago
  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).
youdontknowtho 8y ago
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 8y ago
  Huh? What should we be using instead? Surely not POP.
  - ronsor 8y ago
    obviously we should all use webmail and leave our email locked away to one provider
Numberwang 8y ago
This is amazing! I hope we get some good clients soon.
pwpwp 8y ago
I love this but it kind of rules out webapps as clients, no? Who would give their email password to one?
- orf 8y ago
  Would you rather give it to an app?
- jumbopapa 8y ago
  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.
spalt 8y ago
I mean all this really is is two people sending email really quickly to each other....
- titanix2 8y ago
  Which is exactly what Japanese were doing on their legacy "galakei" phones before the iPhone took over.
- VWWHFSfQ 8y ago
  Is there something wrong with that
- repler 8y ago
  And all email is is two people sending telegraphs really quickly to each other....
  - Derek_MK 8y ago
    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 8y ago
      And? What makes "chat" is synchrony and to a certain extent UI, not transport protocol.
      - rafbuff 8y ago
        Yeah, so why not put everything in one bucket that you control, your mailbox. Part of the idea.
BlackLotus89 8y ago
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 8y ago
  Surely it will use TLS for encrypted transport.
  - BlackLotus89 8y ago
    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)
- LeoPanthera 8y ago
  > If you want something like COI you can use deltachat COI is deltachat. https://fosdem.org/2019/schedule/event/chat_over_imap/ https://fosdem.org/2019/schedule/event/chat_over_imap/
lcnmrn 8y ago
Why not build a chat oriented email client instead?
- LeoPanthera 8y ago
  Isn't that basically what this is?
jokoon 8y ago
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 8y ago
  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.
deleted 8y ago
[deleted]
calimac 8y ago
Brilliant and pragmatic use of an existing infrastructure that promotes individual data freedom
_trampeltier 8y ago
I was wondering a long time, why we don't have chats with user@domain like email or mastodon.
victorqhong 8y ago
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.
billfruit 8y ago
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..
throwaway47556 8y ago
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 8y ago
The problem with smtp and imap is it doesn't work over proxies, which a lot of places still use.
- e1ven 8y ago
  Are there many proxies which don't allow IMAP?
codereflection 8y ago
Perhaps a helpful sidebar: This website loads painfully slow.
Animats 8y ago
This has potential. We have too many proprietary chat systems now. How does it avoid spoofing of addresses and spam?
Felz 8y ago
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?
ape4 8y ago
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+Client+Specification+v1.0 https://confluence-public.open-xchange.com/display/CoiW/COI+...
- nydel 8y ago
  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 :)
lildata 8y ago
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.
tennox 8y ago
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/
godot 8y ago
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 8y ago
  It explains on the site that it falls back to email. Basically an abstraction layer for real time chat built on top of email.
lazyjones 8y ago
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).
ecabuk 8y ago
Nice idea but don’t email providers have hard limits on daily sent emails?
- kyberias 8y ago
  Never heard of such a thing. Do they?
kyberias 8y ago
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.
24daemon 8y ago
looks like google used it way before but nobody was interested (google hangout)
enough 8y ago
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 8y ago
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 8y ago
  A couple of answers here https://confluence-public.open-xchange.com/display/CoiW/FAQ https://confluence-public.open-xchange.com/display/CoiW/FAQ

660 points by smartmic 8y ago

os2mac 8y ago

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

deleted 8y ago

[deleted]

FlatL1ne 8y ago

Hack the Planet

vermilingua 8y ago

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.

MattHeard 8y ago
Are server-side changes needed?
- vermilingua 8y ago
  > The COI ecosystem is the COI Standard plus compatible Client Apps and Email Servers. > COI works with all email severs, but IMAP servers can be enhanced with extra COI capability. I’d take this to mean that no, changes are not explicitly required; but without the changes COI functions the same as email, but in an IM interface.
  - NonEUCitizen 8y ago
    They have a description of the client but I could not find a description of the optional server-side enhancements (besides that it should be advertised via CAPABILITY).
    - Mailtemi 8y ago
      Chat over IMAP seem a bit misleading title. Their proposition is to add additional info in MIME headers. Or later some of them like Message-Id with chat info. So seem more related to MIME and SMTP. A client app can get those headers with different protocols too. MAPI, EWS, JMAP, etc.
      - enough 8y ago
        We are working on server specs, the idea is that certain functionality like WebPush, WebRTC calls, channels require the servers to support COI.
        Mailtemi 8y ago
        Do you know, is it going to have a demo/beta server just to play it.
      - rafbuff 8y ago
        Chat over SMTP/IMAP/MIME just doesn't sound right, or does it? We also thought of Chat over Email, or Chat over Mail, But Chat over IMAP gave us the COI (fish), which we love. Decision made :)
        chrismorgan 8y ago
        Chat over Email is so much clearer as a name.
LoSboccacc 8y ago
> likely to implement a protocol like this into their own servers? just on the homepage "Since this is all based on email, you can communicate with users even when they do not have COI-compatible servers or apps." the likely side effect is that you'd need to filter out chats messages into a folder or something to reduce the inbox clutter
Epskampie 8y ago
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 8y ago
  According to the spec (https://confluence-public.open-xchange.com/display/CoiW/COI+Client+Specification+v1.0 https://confluence-public.open-xchange.com/display/CoiW/COI+...) 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 8y ago
    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.
supermatt 8y ago
The service works as a layer on top of standard email. There will be optional IMAP extensions to reduce the overhead.
dexterdog 8y ago
Google already has IMAP. I don't know about the other two, but I would be surprised if they don't.
davewritescode 8y ago
I've browsed through the spec and it looks like servers likely won't need to change anything. Most of the interaction between clients happens via mail headers. I really like this idea

Piskvorrr 8y ago

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

supermatt 8y ago
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 8y ago
  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".

Mailtemi 8y ago

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 8y ago
> 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?
- Mailtemi 8y ago
  I'm implementing mobile client too :) To sync all mailboxes, not just Inbox need a lot of commands (request/response). Which add a lot of latency which is not very user-friendly on mobile. For example currently, I' exploring JMAP and for the same amount of functionally, the API calls a just 1/10th of what needed with IMAP.
- Tepix 8y ago
  One issue is that not everyone uses IMAP. What's with POP3 users (they still exist) and Exchange users?
  - extra88 8y ago
    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.
  - rafbuff 8y ago
    POP-only mailboxes are pretty rare these days. A lot of users still use POP, but I guess mostly because they configured the mail client a decade or two ago and are not touching it again.
- hombre_fatal 8y ago

kfwhp 8y ago

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 8y ago
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 8y ago
  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 8y ago
    Whats the modern word for "modern"?
    - pofjer 8y ago
      Modern. But beware, it's pretty dated. :)

kelnage 8y ago

"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 8y ago
I don’t really understand why or how this is different from your current trust model around email...?
- calgoo 8y ago
  IMO its comparing itself to Whatsapp and other messaging apps that do have end to end encryption. Thats why the current email trust model is not as important.
- renholder 8y ago
  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 8y ago
    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 8y ago
      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.

tompccs 8y ago

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.

vermilingua 8y ago
No, that’s right, they don’t care about network effects; enterprise customers care about a SLA above everything else. An open protocol cannot provide a SLA.
Freak_NL 8y ago
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 8y ago
  I've ran a mattermost instance for several years now. Works pretty well, actually better as the years have gone by.
jbverschoor 8y ago
"Once people use this for their professional email address they may start to using it for their personal one too." It's usually the other way around.

Y_Y 8y ago

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 8y ago
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.

dmacvicar 8y ago

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

supermatt 8y ago
Primarily I guess this is an open specification, whereas deltachat is a closed app? sounds like the same underlying principle to me though. Apparently in the future there would be optional extensions on IMAP servers to make things more efficient. EDIT: looks like delta.chat is open source https://github.com/deltachat/deltachat-desktop https://github.com/deltachat/deltachat-desktop
- dmacvicar 8y ago
  Deltachat is opensource for every platform it supports: https://github.com/deltachat https://github.com/deltachat It also includes a core library in C: https://github.com/deltachat/deltachat-core https://github.com/deltachat/deltachat-core The spec is documented here: https://github.com/deltachat/spec/blob/master/spec.md https://github.com/deltachat/spec/blob/master/spec.md
Yetanfou 8y ago
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. ..."

smush 8y ago

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 8y ago
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

the_librarian 8y ago

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!

e1ven 8y ago
Signal is probably the best combination of easy-to-use/secure.
- tlynchpin 8y ago
  Signal doesn't support vcard which makes it a non-starter for many people [0][1]. [0]: https://github.com/signalapp/Signal-Android/issues/6520#issuecomment-304572373 https://github.com/signalapp/Signal-Android/issues/6520#issu... [1]: https://github.com/signalapp/Signal-Android/issues/6520#issuecomment-370671001 https://github.com/signalapp/Signal-Android/issues/6520#issu...
  - jka 8y ago
    Interesting comment. How frequently do you think this one vcard-related issue you linked to is a problem for Signal users trying to share contact information with each other? And could you give an example story illustrating how two users would run into this issue in practice?
Fiaxhs 8y ago
I would use Signal, quite simple and privacy focused.
kevingrahl 8y ago
I personally love Threema [1], which is available for iOS, Android, Microsoft and Web. It uses a random ID to identify users, uses End-to-end encryption, you can make voice calls, send messages, audio messages, GIF’s etc.. Oh, and it has a dark theme! Please note that Threema is not open source. If you want that go for Signal instead. [1] - https://threema.ch/en https://threema.ch/en

ttsda 8y ago

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!

m0dest 8y ago

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 8y ago
> 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.

Illniyar 8y ago

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 8y ago
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.

elamje 8y ago

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.

elamje 8y ago

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 8y ago

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.

elvecinodeabajo 8y ago

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 8y ago
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 8y ago
  Which solves nothing if the other party's email is provided by Google. Google is still getting your chats.
  - richardwhiuk 8y ago
    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 8y ago
      You're forgetting E2E encryption.
      - qot 8y ago
        Delta.chat supports E2E with other Delta users and Autocrypt email clients, so the point stands.

Arathorn 8y ago

> 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 8y ago
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.
- rschulman 8y ago
  This is completely the opposite of my experience. I'm in probably a dozen Freenode channels via bridge and another 5-6 Mozilla IRC channels, and haven't had a problem in as long as I can remember.
  - jlkuester7 8y ago
    Same. It was a little 'interesting' to get setup (because IRC) but all-in-all it works great!
- Arathorn 8y ago
  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/msc1763/proposals/1763-configurable-retention-periods.md https://github.com/matrix-org/matrix-doc/blob/matthew/msc176... etc.

comboy 8y ago

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

mike-cardwell 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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 8y ago

amaccuish 8y ago

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 8y ago
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 8y ago
  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 8y ago
    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.

sam_lowry_ 8y ago

They will have a problem with greylisting mail.

sam_lowry_ 8y ago
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 8y ago
  That's one client we are working on. That client uses delta.chat core to which we are also contributing.
  - ttsda 8y ago
    That's great, I'm really excited about your project.
- rafbuff 8y ago
  And yes, we want to open the chat ecosystem to many many cool clients made by you all for every taste and use case. Beyond the obvious WhatsAppySnappyChattySlacky varieties, if you think it through, you can even envision Twitter and Facebook-like clients. Sounds crazy but we cannot imagine why not. Plus normal Email clients can be seriously pimped.

davidhbolton 8y ago

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

AnnoyingSwede 8y ago

"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 8y ago
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.

xDest 8y ago

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-source-rafael-laguna-1.4336574 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.

richardwhiuk 8y ago
Note: > three quarters of all IMAP servers doesn't not mean 3/4 of internet users (e.g. I expect Google's IMAP servers represent a disproportionately large number of users). Dovecot is likely more likely to be used by a long tail of smaller nodes.
- rafbuff 8y ago
  We have about 7bn total unique active (3 months) accounts in the world, 50-60% is Gmail, Outlook.com, Yahoo and a few more, 40-50% are real IMAP servers, of which 76% use Dovecot. Very large deployments include companies like Comcast, Deutsche Telekom, 1&1, LGI (Ziggo, Virgin Media, UPC) with 10m+ user deployments, and yes, a veeery long tail of millions of small servers and anything in between. But COI will also play fine with GMail and friends.
colinprince 8y ago
"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?
- rafbuff 8y ago
  You will be able to chat via email even if the IMAP backend does not (yet) support COI. You lose features, though.

madmaniak 8y ago

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

kevinsimper 8y ago

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 8y ago
IMAP is for receiving.
- arbitrage 8y ago
  IMAP is for retrieving. SMTP is for receiving. And sending.
  - deleted 8y ago
    [deleted]

arendtio 8y ago

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.

enough 8y ago
>90% of mails are delivered really in a couple of seconds, but yeah, turnaround could be quicker. That's why in the longer run we hope to skip the store-and-forward mechanism and instead deliver mails directly by IMAP server to IMAP server.
shereadsthenews 8y ago
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.
deckar01 8y ago
I doubt most email servers actually take anywhere close to 30s to process an email. I suspect most of the delay is the sending server queueing and email client polling intervals.

z3t4 8y ago

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

rafbuff 8y ago
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).

youdontknowtho 8y ago

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 8y ago
Huh? What should we be using instead? Surely not POP.
- ronsor 8y ago
  obviously we should all use webmail and leave our email locked away to one provider

Numberwang 8y ago

This is amazing! I hope we get some good clients soon.

pwpwp 8y ago

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

orf 8y ago
Would you rather give it to an app?
jumbopapa 8y ago
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.

spalt 8y ago

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

titanix2 8y ago
Which is exactly what Japanese were doing on their legacy "galakei" phones before the iPhone took over.
VWWHFSfQ 8y ago
Is there something wrong with that
repler 8y ago
And all email is is two people sending telegraphs really quickly to each other....
- Derek_MK 8y ago
  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 8y ago
    And? What makes "chat" is synchrony and to a certain extent UI, not transport protocol.
    - rafbuff 8y ago
      Yeah, so why not put everything in one bucket that you control, your mailbox. Part of the idea.

BlackLotus89 8y ago

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 8y ago
Surely it will use TLS for encrypted transport.
- BlackLotus89 8y ago
  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)
LeoPanthera 8y ago
> If you want something like COI you can use deltachat COI is deltachat. https://fosdem.org/2019/schedule/event/chat_over_imap/ https://fosdem.org/2019/schedule/event/chat_over_imap/

lcnmrn 8y ago

Why not build a chat oriented email client instead?

LeoPanthera 8y ago
Isn't that basically what this is?

jokoon 8y ago

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 8y ago
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.

deleted 8y ago

[deleted]

calimac 8y ago

Brilliant and pragmatic use of an existing infrastructure that promotes individual data freedom

_trampeltier 8y ago

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

victorqhong 8y ago

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.

billfruit 8y ago

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

throwaway47556 8y ago

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 8y ago

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

e1ven 8y ago
Are there many proxies which don't allow IMAP?

codereflection 8y ago

Perhaps a helpful sidebar: This website loads painfully slow.

Animats 8y ago

This has potential. We have too many proprietary chat systems now. How does it avoid spoofing of addresses and spam?

Felz 8y ago

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?

ape4 8y ago

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+Client+Specification+v1.0 https://confluence-public.open-xchange.com/display/CoiW/COI+...

nydel 8y ago
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 :)

lildata 8y ago

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.

tennox 8y ago

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/

godot 8y ago

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 8y ago
It explains on the site that it falls back to email. Basically an abstraction layer for real time chat built on top of email.

lazyjones 8y ago

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

ecabuk 8y ago

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

kyberias 8y ago
Never heard of such a thing. Do they?

kyberias 8y ago

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.

24daemon 8y ago

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

enough 8y ago

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 8y ago

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 8y ago
A couple of answers here https://confluence-public.open-xchange.com/display/CoiW/FAQ https://confluence-public.open-xchange.com/display/CoiW/FAQ