Question regarding P2P authentication

[Daniel Truemper <tr...@googlemail.com>]

Hi everyone,

I have a question regarding P2P apps in CouchDB and the new authentication method.

The setup could be like that: a central server is the main synchronization point. If the user logs in (via some kind of reverse proxy) she is automatically redirected to her user DB on the server side. So, the central CouchDB instance has a _users database with her user document.

At the same time I want her to run CouchDB locally. I.e. she should have the same user document on her local CouchDB instance so that the passwords are the same. If she changes her user document locally I would like to update this to the server database and vice versa. Could this be done via filtered replication?

If this works like I described it, there is only one open question: how can I prevent the users from replicating all documents P2P, without the synchronization server. I have the usecase where not every user is allowed to see all documents, so I would have to prevent those documents from replicating between two end users. I think this should be done via the validate doc update function?!

If there is a better solution, what would that be?

Best
Daniel

New suscriber question

[Dahmen Manuel <ma...@gmail.com>]

Hello i'm new to couchDB.

I'm asking me some questions about this software.
I'd like to make a platform with messages.
There will be a central server with a couchDB database and http server 
and client applications which can receive and deliver messages 
(message==document).
The user will be notified from messages from his contacts or 
organization, even his own-fixed tasks, sheduled events that he had fix 
him or assigned to him on his agenda.
I think about a very small client app, with calendar and events, task 
lists and deadlines for tasks. Application would take place in the task 
bar as an icon with access to:
- agenda
- event reminder
- event creation
- e-mail received (notification from e-mail client application)
- messages received
- sending messsages to contacts
It would be an application for an organization or a group of friends or 
colleages.

About organization I was thinking about a photography club, a 
photographer could save the location and description where he put his 
new nice photo online. And other members get notified of his post (ie a 
post on Flickr or Picasa)


A new contact/agenda application based on couchDB would be something 
interesting?
That was my first idea of an application based on couchDB when i read 
the website presenting the software.


One question : can couchDB handle binary documents like pictures, music, 
and videos, or simply link to them?
Second question: If I want to make this application, what storage for 
concrete 'documents' (no couchDB Document) like pictures?
- FTP and HTTP?
- P2P but about privacy?
I 'm going to read the book about couchDB and perhaps contribute to this 
project.

Re: Question regarding P2P authentication

[Daniel Truemper <tr...@googlemail.com>]

> 
>> If this works like I described it, there is only one open question: how can I prevent the users from replicating all documents P2P, without the synchronization server. I have the usecase where not every user is allowed to see all documents, so I would have to prevent those documents from replicating between two end users. I think this should be done via the validate doc update function?!
> 
> You can use filtered replication to keep a proxy database on the central server, one for each user, that the user can replicate freely to and from. Then you can use filters when replicating between the central db and the proxy db.
This is what I was thinking of on the central server side.

> A simpler option (depending on your app) would be to allow users to create workgroups, and each workgroup gets a db which members can replicate, read and write to. This is simpler than a central db plus it is easier for users to reason about.
But only a central db for each group may be better. Will have to think about it.

Thanks for the answer!
Daniel

Re: Question regarding P2P authentication

[J Chris Anderson <jc...@gmail.com>]

On Apr 20, 2010, at 11:43 AM, Daniel Truemper wrote:

> Hi everyone,
> 
> I have a question regarding P2P apps in CouchDB and the new authentication method.
> 
> The setup could be like that: a central server is the main synchronization point. If the user logs in (via some kind of reverse proxy) she is automatically redirected to her user DB on the server side. So, the central CouchDB instance has a _users database with her user document.
> 
> At the same time I want her to run CouchDB locally. I.e. she should have the same user document on her local CouchDB instance so that the passwords are the same. If she changes her user document locally I would like to update this to the server database and vice versa. Could this be done via filtered replication?
> 

you won't need a filter, as users are only allowed to update their own user doc. Even if a user defeats the validation locally, the central server will only allow replication to update the correct document.

> If this works like I described it, there is only one open question: how can I prevent the users from replicating all documents P2P, without the synchronization server. I have the usecase where not every user is allowed to see all documents, so I would have to prevent those documents from replicating between two end users. I think this should be done via the validate doc update function?!

You can use filtered replication to keep a proxy database on the central server, one for each user, that the user can replicate freely to and from. Then you can use filters when replicating between the central db and the proxy db.

A simpler option (depending on your app) would be to allow users to create workgroups, and each workgroup gets a db which members can replicate, read and write to. This is simpler than a central db plus it is easier for users to reason about.

I think the model of a central db with complex policy controls for each document is a holdover from the relational days. It's much simpler to think of a database as a shared workspace, where anyone who has access has full access.

Chris

> 
> If there is a better solution, what would that be?
> 
> Best
> Daniel