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!
COI – Chat Over IMAP
171–180 of 259 posts
Re: COI – Chat Over IMAP
#172Re: COI – Chat Over IMAP
#173It 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?
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
#174Earlier 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.
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
#175Re: COI – Chat Over IMAP
#176Re: COI – Chat Over IMAP
#177The problem with smtp and imap is it doesn't work over proxies, which a lot of places still use.
Re: COI – Chat Over IMAP
#178I 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.
Re: COI – Chat Over IMAP
#179Re: COI – Chat Over IMAP
#180Earlier 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.