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 nebupookins@gmail.com
 designates 209.85.160.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=GwYKngiELMlWxr5opaU5ite/Ub3epWQBc5q34xCNNi6mSogee1TmjLRPmr8Qyedvvm
         GPIcpp1yp7ohw4cC2sfCNbCjWc3I+JJfJ+oE4S1yO9yMiIzwaCpdZtMq/Aav3BidBKcS
         C1YDYZhRW9Kz+tsG45GAQk7tnSO/2xPCWPT0Q=
MIME-Version: 1.0
In-Reply-To: <4D8DDF4B.8010108@gmail.com>
References: <AANLkTin4sy3AQp=tdWMBv+U_UPQpN6wV81Mj5YDHxfDO@mail.gmail.com>
	<4D8BCD50.8080003@gmail.com>
	<AANLkTi=L380Dma4qr4Cq-ENbjSvAzaOwWk-Ysxqa=RQr@mail.gmail.com>
	<4D8DDF4B.8010108@gmail.com>
Date: Mon, 28 Mar 2011 11:38:29 -0400
Message-ID: <AANLkTi=R5h_K+B124njJXZeojJM0wyaeN2adkh0WQJDq@mail.gmail.com>
Subject: Re: Question about validator functions and replication
From: Nebu Pookins <nebupookins@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=UTF-8

On Sat, Mar 26, 2011 at 8:42 AM, Patrick Barnes <mrtrick@gmail.com> wrote:
>> 1) Alice and Bob are friends, and Alice lent her laptop to Bob so that
>> he could do some offline blogging too.
>
> If 'Bob' wants to do some blogging, he *really* should be required to input
> his own credentials to push any of _his_ modifications back to the central
> server.

In theory, you can have a solution where Bob does input his
credentials at some point, but not necessarily exactly when his
changes are getting pushed to the central server. For example, he
could sign his changes, at one date, and then several days later, the
replication occurs and the server verifies the signature. I'm just
unsure of the feasibility of implementing this solution in CouchDB in
practice.

> As I understand it, you have a central server 'C' with a couchdb database,
> and users 'A' and 'B', each of whom have a local copy of C's database.

Your understanding of this example is correct, though I feel I should
now mention I'd like for any solution to also work in a
"decentralized" mode. It'd be a nice-to-have, but if it turns out to
be impossible (I doubt it's impossible, though), I'm also interested
in hearing solutions which depend on a centralized server.

[...]
> A: Users can have a different set of roles on different servers. So on 'C',
> Alice is probably an ordinary user, but on 'A' Alice can have admin
> permissions - the design doc on the target db can check the user roles and
> differentiate.

Thanks, I was worried about this point, but you've clarified to me
that it is possible for users to have different roles on different
instances of CouchDB despite replication.

> If you have some secure data floating around in your db, encryption can
> still be a good idea. Parts of one of my databases are encrypted, because
> users need to be able to see some documents in the db but not others.

I'm curious as how you've implemented encryption in your DB. Was it
pure JavaScript, or did you use native libraries? Elsewhere in this
thread, I've started a new "branch" where I've started outlining my
concerns with a pure JavaScript solution and wondered if cryptography
could be included as a core feature of CouchDB.

> Finally, you can also look at filtered replication, so - *as well as*
> restricting which documents can be replicated back to the central db 'C' by
> whom - you can limit replication pushes to only those docs that should pass
> validation.

Yeah, filtered replication is always in the back of my mind, but it
seems like the requirements for my problem are such that there's going
to be a lot of collaboration amongst the users; the real problem isn't
as simple as just a set of blog posts.

> Hope that helps,
> -Patrick

You've been a great help, thank you.
- Nebu