Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Subject: Re: decentralized chat
References: <20121124031418.GA1797@canonical.org>
 <CAPaJBx7Wx0BuMfN9FW9a-HHLnQXXoJCc+avW4TFyD11=VT5PJw@mail.gmail.com>
From: Thanos Vassilakis <thanos@infinigongroup.com>
Content-Type: text/plain;
	charset=us-ascii
In-Reply-To: 
 <CAPaJBx7Wx0BuMfN9FW9a-HHLnQXXoJCc+avW4TFyD11=VT5PJw@mail.gmail.com>
Message-Id: <C552274A-6172-4F2A-A5C3-22EB0222AC44@infinigongroup.com>
Date: Sun, 2 Dec 2012 23:11:13 -0500
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)

I've used couchdb for a private but audited chat system for traders. It's wo=
rked very well.=20

Thanos

On Dec 2, 2012, at 7:17 PM, Noah Slater <nslater@apache.org> 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...
>=20
>=20
> On 24 November 2012 03:14, Kragen Javier Sitaker <kragen@canonical.org>wro=
te:
>=20
>> 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:
>>=20
>> <
>> http://jchrisa.net/drl/_design/sofa/_list/post/post-page?startkey=3D%5B%2=
2Simple-Wins%22%5De
>>>=20
>>=20
>> 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:
>>=20
>> * 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.
>>=20
>> 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?
>>=20
>> [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:
>>=20
>> * 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?
>>=20
>> 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.
>>=20
>> 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.
>>=20
>=20
>=20
>=20
> --=20
> NS