[Dev-flock] couchdb

[Lucy Mendel]

yo,
i have to ditto the sentiment below. we're not at the stage for
decentralizing the database, but might be useful in the future,
especially if we get shut-down.

quote from another list i'm on:::

Ran across this project when I was reading about Amazon's forthcoming
SimpleDB service:
http://couchdb.org/

It's GPL'd, uses JSON, is REST-ful and seems to be easily replicated
across multiple servers. It's not a relational database, but rather a
collection of documents where you can specify the attributes as you
go. It actually seems like a very good candidate for decentralizing
our database.

 From an IRC session at #couchdb, where I asked about the issue of
permissions:

 > I have a question about authentication... is there any way to
restrict who
+can do what in couchdb?
*** Signoff: dreid ()
 > authorization, rather
<jan____> not in couchdb itself. you'd need requests through a proxy
of some
+sort
 > Is it possible to make a replication read-only?
*** pfein (n=pfein at user-160uenf.cable.mindspring.com) has joined channel
+#couchdb
<jan____> with an apache and mod_rewrite in front, it should be doable
 > I'm interested in using couchdb to replicate on servers not under
my control
+... is there any sane way to recover from a "bad" replication?
*** bobesponja (n=bobespon at bas75-1-82-235-231-146.fbx.proxad.net) has
joined
+channel #couchdb
<jan____> dphiffer: You definitely don't want CouchDB running open to
servers
+not under your control
 > Hehe
<jan____> at this point
 > I'm running a project called ShiftSpace (shiftspace.org), which we're
+looking to decentralize DB-wise. Couch seems like a very good fit
except for
+that one issue.
<jan____> but using apache or a simple script that routes your
replication
+roots to the untrusted peers is probably easy
<jan____> how would that work? Would your users run their own CouchDB
+instances?
*** phuson_ (n=phuson at nat/yahoo/x-d887da8f876a1099) has joined channel
+#couchdb
<jan____> and what would be replicated?
 > I think the content itself ought to be replicated. We'd only need
"several"
+replications -- only a small percentage of advanced users would be
expected
+to have the server resources + know-how.
<jan____> Ah, reading your 'install' site. Each user would have its own
+database that you'd want to replicate to a central server at certain
points?
 > The install instructions are more for setting up a development
environment,
+which uses a local database. In general the database lives out in the
data
+cloud. We just don't want it to stirctly be *our* cloud.
<jan____> BTW: I totally dig shiftspace. It's cool :)
 > Thanks :)
 > Partially we're looking to decentralize for practical reasons (just
got our
+first bandwidth overage) and partially for social reasons (don't want
speech
+to be repressed)
<jan____> dphiffer: CouchDB is a perfect fit.
<jan____> (I'd say :)
<jan____> So ...thinking... Your peers are not really untrusted, but
+semi-trusted and while bad things could happen and you need undo
then, it
+wouldn't be common, right?
 > Yeah, I'm thinking the permissions thing isn't that important ...
 > As long as we trust a small number of peers.
 > And yes, it does seem like a very good fit :)
 > Thanks for the info jan____, I'm definitely going to give this a
try. We're
+currently bumping along with a single SQLite database... which isn't
scaling
+so well.
<jan____> dphiffer: Anytime
<jan____> dphiffer: If you've got any other questions, feel free to ask.
 > Great, thanks!