Proposal: Replication with document manipulation

[Jann Horn <ja...@thejh.net>]

Hello,
I am currently developing a few small pieces of software for storing all my
mails in couchdb so that syncing local mails and mails on the server becomes
faster, I can easily get notifications about new mail and so on. I already
have a helper that's specified in my .forward file on the mailserver which is
written in C and automatically puts all new mails into a couchdb on the server.
Also, I have set up replication between my server and my computer, written a
small FUSE filesystem in nodejs that lets me access my mails like a Maildir
using mutt and written a small helper that shows notifications on my display
whenever I have new mail.

However, I'm a bit uncomfortable with storing my mails in a couchdb on the server
in plaintext. On my computer, I want the DB to contain plaintext so that it's
easy to use view functions so that I can easily work on views in Futon and so
on, but on the server, I would like the documents to be encrypted using
public-key crypto:
I would have a private key on my devices from which I want to be able to read
mail. The server would only have the public key. My C program that inserts new
mails into the database would first encrypt them using the public key and then
insert them into the database. So, the server-side couchdb would have to do
nothing special.

However, I would like my client-side couchdb to decrypt the documents
together with their attachments during pull replication and to encrypt them
during push replication. For this, I would need couchdb to support either
special crypto options for replication or a generic replication handler with
write access to both the document itself and its attachments.

However, as a generic replication handler would mean that crypto operations
would have to be done in JS, the public-key crypto operations would probably
be unusably slow (2048-bit decryption takes 361ms on my laptop with the JS
implementation at <http://www-cs-students.stanford.edu/~tjw/jsbn/>).
Therefore, this way would also require a native crypto library to be exposed
to the JS code.

So, my question is: How about adding access to a native crypto API for JS code
and adding a document handler for replication that has access to attachments?
Alternatively, in case you don't like that idea, what do you think about adding
special `encrypt` and `decrypt` options to the Replicator API that cause all
replicated documents to be encrypted or decrypted using the key provided as the
option's value?

If you don't totally dislike this idea, I'll try to write a patch (although
that could take quite some time because I don't really know Haskell yet).