couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thanos Vassilakis <>
Subject Re: decentralized chat
Date Mon, 03 Dec 2012 04:11:13 GMT
I've used couchdb for a private but audited chat system for traders. It's worked very well.


On Dec 2, 2012, at 7:17 PM, Noah Slater <> wrote:

> If it looks like Couch has 80% of what you need, perhaps you would be
> interested in contributing the remaining 20%? That would be a win for
> everone! Some of the stuff you mention sounds quite exiting...
> On 24 November 2012 03:14, Kragen Javier Sitaker <>wrote:
>> 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
>> Toast:
>> <
>> 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
>> yet.
>> 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
>> on.
> -- 
> NS

View raw message