couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From svilen>
Subject Re: decentralized chat
Date Sun, 25 Nov 2012 10:05:34 GMT

i am working on something like this for 2+months already, and 
the chat is just the message carrier, with semantical-interpretation on
top for various application fields - people talk for different
reasons, and putting some structure into messages allows the apps to
do "themed" specialized routine tasks (like recollecting, grouping,
classifying, etc). Having couchdb/plain and touchdb/mobile nodes. i 
chose couchdb as the only thing around having decent replication And
working on mobiles.

i have changed 2 architectures already and probably would do
it again - started with database per discussion with continious repl
(which means 10000s of connections), then passed through once-off
discussion replication when there is change, with one "changes-channel"
continiosly replicated, now i'm using only the channel as
holder of anything. Everything u put or get goes into your channel,
and serverside multiplies messages to and from other channels
(kind-a internal filtered replication but hand-made). These are the
two extreme ends, i guess sometime i may have to have both channels and
databases, when duplicating same thing into 1000 channels becomes
a problem. The database-only can be server-less; channel-only relies on
serverside to multiplex messages. Eventualy it can also go into client
side if u can trust the incoming channels.

i haven't at all thought about anything lower than couchdb - it's my
lowest protocol. 
Even user-authentication is still somewhat a mist - i have to try
auth and replication using cookies/sessions, https, and the like.
There's quite some little issues there, e.g. avoiding impersonalization
and enforcing expelling is only done by server-side (see
 and related).

i'd be happy to exchange thoughts on this or that.. my server-side
(python) is working although untested, now i'm jumping into
client android and that may take... long. native mobiles are.. tedious.
as anything with UI actualy.

for the inclined, in the looong run i'm targetting something much
deeper (read, bottom to top) but it's still only


On Fri, 23 Nov 2012 22:14:18 -0500
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.  

View raw message