COI – Chat Over IMAP
coi-dev.org
coi-dev.org
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 :)
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.
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... etc.
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.
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.
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/.
> 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/
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.
and think, this is basically blockchain workings right? IF we had only created a client that worked on iOs only, could store and send chat coins and log votes for each group, this could be presented in press releases as a new blockchain chat and get all kinds of posts and maybe money thrown at it.
kidding aside - I have more faith in Matrix moving forward than any similar projects at the moment, and I don't see that changing soon - so I hope more can be done to polish clients and make sure bridges and other features are well done.
As soon as moderation tools are enhanced I'll begin to use it on several sites.
I'd love to see some bubbles of related issues that need love and have some people put some estimated time and money on each bubble - maybe we could crowdsource some code for some bubbles and money for others or something -
I feel there are many groups of people who want / need different things in order to increase adoption, and I feel for the folks coders / maintainers who are trying to extinguish all the fires at once.
I put a few hundred into bug bounty like thing to get some features added to rocket chat so we could use it.. then found the amount of other bugs left un worked at the time meant it was not feasible for our usage any time soon. Hopefully with the funding and such of Matrix it can evolve on multiple levels at once and become a solid framework with many clients and ux options.
A bridge for COI and delta chat or any others. I'd love a client that bridges with email address and has one click to keybase auth or pgp and such - and puts things into a timeline / fbook feed like view.. not for me, but for others.. group friends, display on phones and web.. seems these things could be close to reality.
Which mature clients and servers should I choose from, implementing all this (basic) stuff?
What does this have to do with anything? It's used for chat and solves all the same problems. You could easily have done all the same things (including building a system that does syncing like matrix nodes) on top of an existing protocol instead of reinventing the wheel.
When I was about 13, I worked on a really fun chat system at school called (wait for it) iNFERNO][ (it was the second attempt at a chat system called iNFERNO). It was pretty awesome, and worked like this: the school ran a large network of 68k-based Macs (LCs, Centrises, even a Quadra) networked to a single Apple Workgroup Server, which ran a Filemaker Pro db instance that the school used for its HR and record keeping. As it happened, the DB server was set up such that anyone could create DBs on it, so the school geek community spun up a few to play with.
If you've ever used Filemaker, you'll know that it's a visual DB - almost creating Forms as the first-class citizen (a bit like Hypercard) and the fact they're backed by tabular data is almost hidden. Even more excitingly, it even had basic networking so you could run network queries between DB instances - including exchanging arbitrary objects (e.g. images, videos etc), if i remember correctly.
So, what we did was to set up a centralised DB (iNFERNO itself) on the server, shared over the network, which stored a bunch of chatroom history and provided a graphical timeline view onto the room when opened up over the network from a Mac (set up to occupy the top 2/3rds of your screen).
Meanwhile, and this is the fun bit: we also wrote a DB instance called your "iNFERNO Key", which you stored on a 3.5" floppy disk and could run as a local DB off the disk on any Mac you happened to walk up to. It coughed up a window on the bottom 1/3rd of the screen, which provided your composer prompt. Everyone had their own key, and customised it to their heart's content with different themes, colour schemes, buttons, bot-functionality etc. And it stored their credentials (and we even tried some basic shared-secret e2e crypto) to make logging in trivial - you just put the disk in the drive and clicked the DB (which would in turn spawn the separate main window to view the shared DB timeline).
When you sent a message (which could be text, or arbitrary filemaker objects like images, videos etc), Filemaker let you stage the table row locally and then insert it into the shared DB instance, so you ended up with a surprisingly fun and usable server/client chat system, with arbitrary scrollback, multidevice support, file-transfer etc... using a batshit crazy architecture which involved schoolkids running around waving 3.5" disks around and forking each other's "keys" and somewhat unnecessarily authoring messages using a local DB instance when the whole thing could have been done on the serverside DB instead.
The whole thing lasted about 3 months, getting increasingly popular until the school went nuts at their Filemaker server being completely overloaded and tragically turned it all off. And whilst I still probably have my Key somewhere, we surely didn't have a backup of the central server itself :(
So, my point is: this was a chat system, with many of the features shared by XMPP, Matrix, Slack, Discord etc today. Could we have built it on top of something else? Sure, we could have built it on IRC instead or Talk or some BBS based thing. But instead we chose to experiment with a totally different architecture, which had its own weird trade-offs and benefits, and learned a bunch of stuff along the way. (I still miss the idea of literally synchronising rich graphical objects over the network - it almost felt like Croquet or one of the virtual world things).
And so, whilst you're totally right that we could have tried to layer Matrix semantics over the top of XMPP or IMAP or Filemaker(!), we similarly wanted to try a totally different architecture; one without stanzas and message passing; one without all the historical baggage of XMPP; one which only does group conversations; etc. So I'd argue this is how stuff evolves, and sometimes it's good to experiment with building on a new base. And if it doesn't work out; hopefully it at least provided a learning experience for all concerned. The same goes for COI layering chat over IMAP; almost as questionable as layering chat over a networked DB ;). So, let's just get on with building stuff and seeing what works and what doesn't. This isn't a case of re-inventing the wheel for the sake of it, but seeing how well things work if you build on an entirely different set of foundations.
(if you are affiliated with riot/matrix: keep up the good work!)
Not sure what that even means. Worth reporting.
> pictures are a link to the server, so I have to manually download them all.
I think you need to install the image preview plugin.
For gajim make sure it's a recent version. Dino-im https://dino.im/ is decent. poezio https://poez.io/en/ if you want a text client. converse.js https://conversejs.org/ for a web client.
Public server wise I don't have any recommendations (but i'm sure others have plenty) other than movim. https://movim.eu/#try they have a baked in client (and do a whole bunch of other stuff like micro blogging) but once you have a account, there is no reason you can't use any client you want.
Encryption with omemo is a issue and usability could be improved (I believe people are working on that).
EDIT: featured on HN https://news.ycombinator.com/item?id=16948597. Look at the comments and you understand why I'm not the only one thinking, the UX is bad...
then we could see an estimated total, like for $xx we could get most of these apps all on the same page of features running... if that is the major hurdle - a crowdsourced money or and time to get them all modernized may make the whole ecosystem 2.0 and worthy of use?
Surely it can't be that much that is needed - yet it seems that fixing just one or two is not having the same network effects of having them all speaking the 2.0 feature language.
The worst thing isn't that the standard isn't defined or something, but that a lot of projects are claiming to support XMPP when they only support some core functionality...
I don't see a clear relationship between the sentence and its parenthetical.
I don't know about Matrix' funding model. But I do know Signal, for example, isn't developed by a recognized standards body. What can I infer from that about the sustainability of its long-term funding?
The ridiculous crashing every few minutes thing of the IRC bridge has been fixed enough I haven't noticed a problem for quite a while.
I have a looooot of disagreements with matrix, which I have discussed and will discuss with them, but honestly they're not doing it completely wrong anymore.
\o/ :) The other stuff is very much on our radar, fwiw (and in an ideal world i hope we'll finally be able to implement a services or TS6-based bridge). We've been a bit distracted over the last few months with an XMPP bridge (matrix-bifrost) but will be back on IRC bridging shortly.
We should run a general purpose email bridge though, and in fact there's a massive public sector outfit asking for such a thing currently so it'll probably happen sooner than later.
In terms of Matrix not being a spectacular success - well, that's a matter of perspective. The intention for France is absolutely for it to federate with the public network (once there's are sufficient border gateways in place). And France is far from the only high profile Matrix deployment out there, it's just one that we can speak about. But eitherway, COI looks cool, and I hope it helps OX sell more mail servers :)
Yet, there is no option to bridge without involving the administrator of all servers you want to talk to.
That and I had a very bad experience with the other bridges. Outside of IRC it's basically unusable.
But any bridge will be restricted to the lowest common denominator, often you get into weird corner cases where the two ends of the bridge work subtly different.
A Telepathy dev wrote a long post on the subject a while back, worth reading: https://mail.gnome.org/archives/desktop-devel-list/2017-Sept...
> "Jabber is a new project I recently started to create a complete open-source platform for Instant Messaging with transparent communication to other IM systems(ICQ, AIM, etc).
Matthew Hodgson, 2019:
> 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 hey, we are using IMAP and Mail which is already in the picture.
* Wonky unwieldy hypertext systems instead of the WWW
* The Nomad instead of the iPod
* The Blackberry instead of the iPhone
* GNU Hurd instead of Linux
* Geocities instead of Facebook (-- OK maybe that one's a wash :-)
The point is, sometimes it's worth trying again until you can make it work.
We don't have much choice!
Linux had real improvements over Hurd but it'd be silly to suggest that a separate "Linux" brand kernel needed to exist to make those improvements possible.
> * Wonky unwieldy hypertext systems instead of the WWW
Which ones? Gopher wasn't hypertext, but it is still going and still a good idea. A conversion to Gopher would be a huge usability and accessibility upgrade for many current websites.
> * The Nomad instead of the iPod
iTunes is garbage. iPods sucked until (certain models) had Rockbox ported to them.
> * The Blackberry instead of the iPhone
How about the Nokia n900 instead?
> * GNU Hurd instead of Linux
I'm "stuck" with BSD. Send help?
Ambitious projects are cool and should be encouraged. Being an ignoramus about existing developments (not saying that that is what the people behind Matrix are doing) and getting distracted by anything that claims novelty should not be. Hoare had a great bon mot about this: "Here is a language [Algol 60] so far ahead of its time, that it was not only an improvement on its predecessors, but also on nearly all its successors."
Hum, yeah, most of the world is connecting through Gopher...
The blind person that told me about how much better Gopher was than the modern web for blind people was not a techie, and I don't think it is moral to treat disabilities as just a "niche."
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.
followed by
"After checking for server compatibility..."
Does this reduce the target pool? How much?
Also, how many people still use POP?
>"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)."
> 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.
EDIT: looks like delta.chat is open source https://github.com/deltachat/deltachat-desktop
It also includes a core library in C: https://github.com/deltachat/deltachat-core
The spec is documented here: https://github.com/deltachat/spec/blob/master/spec.md
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/ - "...We cooperate with Delta Chat open source project to bundle efforts and ensure interoperability. ..."
Great! Good luck to them.
"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.
Fundamentally, if you don't trust the decisions of the person you are talking with, you can't guarantee the privacy of your chats.
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.
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?
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.
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.
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.
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?
Once people use this for their professional email address they may start to using it for their personal one too.
It's just not an urgent a problem as this is.
It's usually the other way around.
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.
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?
Working with IMAP at a large company was my first "meh, how hard could it be" hubris moment. Their implementation must've had a decade of work put into it. Seemed bizarrely complex to me, so I started a side project of building my own. My little hero developer saves the day fantasy. Could've made your same HN comment early on when my PoC integrated with its first service. My side project never advanced beyond weekendware after I started seeing why it was hard.
Eventually, the guy that worked on it all that time quit over some political drama. They asked me if I wanted to maintain the project. I tried and basically quit over it.
Also, IMAP itself sucks. Did you know the spec doesn't require emails to have a message id? Also, no servers have to return your commands in order, and they don't have ids. So you'll code shit like "if the response looks like this, it must've matched up with this one command." I could go on and on about the nickel and diming that will happen to an IMAP client that you thought would once be simple.
Fun times.
I'm sure you know, but in case someone reads it and doesn't know it this is perfectly as intended: IMAP isn't a request-response protocol, it's more of a pub/sub protocol.
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?
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.
Otherwise it's pretty neat.
Access to your e-mail account allows you to reset password in most services associated with it.
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.
(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.
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.
Edit while writing others postet the same stuff I postet
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)
COI is deltachat.
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?
[0]: https://github.com/signalapp/Signal-Android/issues/6520#issu... [1]: https://github.com/signalapp/Signal-Android/issues/6520#issu...
And could you give an example story illustrating how two users would run into this issue in practice?
Please note that Threema is not open source. If you want that go for Signal instead.
[1] - https://threema.ch/en
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.
https://confluence-public.open-xchange.com/display/CoiW/COI+...
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
it's a blank page that says they think RFC is essential, which is surely a valid opinion :)
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.
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?
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.
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.
WhatsApp simply won the race by being there early on and getting the critical mass. From there on out people are locked in, because everyone else is there.
Even in countries that had free domestic text messages (where the “free” factor was much less important), WhatsApp nailed group messaging better than anything else available at the time. Also, by using phone numbers they skipped the entire “create account / invite friends” stage, making for a much smoother bootstrap.
In Germany I'd say it's by far the most common chat client, even my parents use it.
The prime target of this protocol isn’t power users and developers; it’s the overwhelming majority of users that stick to siloed messaging because it’s convenient, and everyone has it. First and foremost, they need to be shown that this is more convenient, and has a larger and more accessible network.
Someone will probably say something about homomorphic encryption. Not deployed AFAIK, and deploying will be difficult if you want to ensure that you can search your encrypted mail but others cannot.
Okay, suppose that I were to back up all of my mail to each client device; three at the moment, or four if you count my old phone, which is still running because I haven't gotten around to wiping it. Then I'd have five backup sites instead of one. But four of those are backed up to the fifth, so the size of the mail backup would be quintupled, the activity on the backup device would increase and with it the number of possible occasions for a failure, and the age of my oldest backup would be automatically decreased to compensate.
And when it comes to a chat client, it's not a big deal to pick which chat to search, vastly reducing the amount of data you need.
>A COI-compliant client MAY support the Autocrypt standard to ease end to end encryption scenarios.
>TODO: Consider using more secure lookup mechanisms for encryption keys. Also check for existing encryption keys before auto-generating a new encryption key set.
> 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.
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
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.
I really like this idea
Email <> IMAP even though most email providers do provide access to IMAP, this is greatly oversimplified.
From there outwards the protocol (degrades to/can use) regular mail/smtp, so you can indeed connect with any address capable of receiving email.
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.
Are they expecting others to write implementations?
How does it avoid spoofing of addresses and spam?
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.
"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".