Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of ziggythehamster@gmail.com
 designates 209.85.216.52 as permitted sender)
MIME-Version: 1.0
Sender: ziggythehamster@gmail.com
In-Reply-To: <20121124031418.GA1797@canonical.org>
References: <20121124031418.GA1797@canonical.org>
Date: Sat, 24 Nov 2012 00:33:35 -0600
Message-ID: 
 <CAC7vo1CnFKT1LRSC5kuPKPQm=wLg5J6_gOLq=FY2WbtkB-zN4w@mail.gmail.com>
Subject: Re: decentralized chat
From: Keith Gable <ziggy@ignition-project.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=047d7bb043ac3e123e04cf37e15f

--047d7bb043ac3e123e04cf37e15f
Content-Type: text/plain; charset=ISO-8859-1

NB: I was an IRC server/client developer in a past life.

I don't think you're going to be able to reliably solve the dual NAT issue
for everyone. A mesh-type database like CouchDB would work well for
decentralized chat, but one thing I would do would be to digitally sign
every message. You'd have to prompt users to accept conversations from
unverified senders (think SSH login), but that's not too terrible of a
solution. But you'd need some special endpoints in CouchDB to handle this
and give each authorized user a login. You could do this with an external
handler pretty easy.

Also, your design should allow for centralization as well. This is one of
the strengths of Git - you can have a shared remote like GitHub or you can
push and pull from anyone that allows you.

Finally, I would use one database per channel, but you will eventually run
out of file descriptors. So maybe have a lookup database with a standard
name that tells you where to find a particular channel, and it could be the
same server. But all servers in a network replicate this database amongst
themselves.
On Nov 23, 2012 9:14 PM, "Kragen Javier Sitaker" <kragen@canonical.org>
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:
>
> <
> http://jchrisa.net/drl/_design/sofa/_list/post/post-page?startkey=%5B%22Simple-Wins%22%5De
> >
>
> 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](http://swhack.com/logs/2012-11-24#T02-25-22) 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.
>

--047d7bb043ac3e123e04cf37e15f--