Live data from Hacker News

COI – Chat Over IMAP

coi-dev.org

171–180 of 259 posts

Re: COI – Chat Over IMAP

#171

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!

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

Re: COI – Chat Over IMAP

#173
post #19
post #8

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.

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

Once you try to integrate with different systems, you'll find one of the major difficulties of IMAP: nobody really cares. Every player is different. Even gmail has its own issues, like creating "folders" for each tag and duplicates the same message to each folder, so your little simple client now has custom de-duplication logic.

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.

Re: COI – Chat Over IMAP

#174

Earlier quoted context omitted.

i'd argue that the Matrix.org Foundation is just as 'recognized' as the XMPP Standards Foundation :) In terms of disingenuousness - i'd argue that the definition of disingenuous is accusing us of reinventing the wheel rather than acknowledging that Matrix is an entirely different type of technology to IRC or XMPP. It's more similar to NNTP or Git than either IRC or XMPP. For better or worse, trying to solve existing…

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

We seem to have this same dead-end conversation every few months, so indulge me as I try to break the impasse with a story instead.

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.

Re: COI – Chat Over IMAP

#178

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

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

Re: COI – Chat Over IMAP

#180

Earlier quoted context omitted.

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

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

Yeah, so why not put everything in one bucket that you control, your mailbox. Part of the idea.
Post reply on HN