couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kragen Javier Sitaker <>
Subject decentralized chat
Date Sat, 24 Nov 2012 03:14:18 GMT
Hi.  I'm new to CouchDB, but I was just chatting with Noah on IRC about
how IRC sucks and we need to replace it and whether we could do that
using CouchDB.  He mentioned this thing Chris did four years ago called


Right now Skype chat is basically the best thing out there that I've
seen, but it's proprietary.  It has the following features I like:

* Real-time: people normally see your lines within less than a second
  after you send them.
* Peer-to-peer: you don't have to install or manage software on a server
  to make it work, and it knows how to traverse NATs.  (Skype, Inc.,
  does maintain a centralized authentication service, which I regard as
  a significant drawback.)
* Replicated: you can look at chat history and add chat lines when
  you're offline.  When you reconnect to the people you're talking to,
  all the lines get sent.  This is important not mostly because I'm
  trying to chat while I'm on an airplane but because I don't want to
  lose messages when my network gets disconnected, and because I switch
  between devices and want to be able to see messages I typed on my
  laptop on my cellphone and vice versa.  (As far as I can tell, the
  POP-not-IMAP nature of XMPP makes this impossible for XMPP chats.)
* Unified-UI: you can chat with many different people or groups of
  people at once using the same app, and see e.g. a list of chat
  channels where you have unread messages.
* Encrypted: your ISP can't read your chat messages.
* Secure: the people you're chatting with can't subvert your chat
  software to e.g. snoop on your other chats.
* Correct: unlike IRC, doesn't truncate your lines at arbitrary places
  if they get too long.
* File transfers: you can send screenshots and stuff to other people,
  including everybody in a group chat.
* Cross-platform: versions for both GNU/Linux and Android.

So I'm trying to get a sense of whether there's something out there that
would make this feature set easy to replicate.  And maybe CouchDB is it?
Or do I need to build something from scratch?

[Noah suggested]( making
each chat line a new document, using continuous replication, creating a
mapreduce view using datetime as a key and pulling the most recent 40
messages, and using the _changes feed to get Comet updates to the
browser asynchronously.  That sounds pretty reasonable to me, but the
following questions occur to me:

* I'm behind NAT.  If you're behind NAT too, how can we set up
  continuous replication between our CouchDB instances?  Is there STUN
  support for CouchDB replication yet?
* Do I need to create a new CouchDB database for every chat room?  Is
  there any problem with having 20 or 30 databases on my netbook talking
  at once?
* How about if I want to have a single Comet connection from my browser
  to all of them at once?  (Browsers won't let you have 30 Comet
  connections to localhost.)
* Are there security concerns I need to think about?  Like, how do I
  make it so that I can update my DHTML UI, and maybe even automatically
  get updates from someone else, but not *everybody* I chat with can
  update my DHTML UI to a version that spies on my chats?  What are the
  security properties of the replication protocol?  What if I need to
  kick someone out of a chat channel because they're spamming it?

I think the ability to automatically update application code is
necessary for decentralized applications (like email) to start to
successfully compete with centralized ones (like Facebook) again, but
although I have some ideas about how to do that securely, I don't feel
like I've solved the problem because I haven't tried them in practice

Anyway, I don't know if anybody else thinks it's an interesting project,
but it seems to me like every chat system out there today is basically
unusably bad, and decentralized database replication with automatically
incrementally updating views seems like the right substrate to build it

View raw message