Thanks Stefan, Indeed my plan is in any case only to expose a limited set of properties, certainly not the full user objects. Good point about separating user account from person and personal information.
Following your idea, I could imagine having a bare bones _users database with only the accounts, allowing me to authenticate users (already in place now). Next to that I could have a separate "persons" database containing personal information; there would in that case be a 1:1 mapping between a document in _users and one in "persons". Taking that as starting point, one option could indeed be as you propose to copy a subset of that "persons" database into each other database (of course again only a subset of the info, ideally controllable by the end users). One problem that I imagine with that is mainly the amount of incurred data duplication. More importantly the chaining of changes/replication could be really important with that when a user changes something on his/her profile, as the data would need to be copied again to each matching database and replicated to each client needing that information. For now I think that having a single "persons" database and replicating it (filtered) to each end user for offline use is the way to go. I just need to figure out how to handle the filtering and if data that shouldn't be there locally will be removed automatically or not. For instance, imagine that persons contains [A, B, C, D, E, F], then: - If [A, B, C] have access to database X, then those users should have a copy of [A, B, C] locally - If [A, D, E] have access to database Y, then those users should have a copy of [A,D,E] locally Consequently, A should have A, B, C, D, E in his local "persons" database copy. If at some point E is removed from database Y, then user A should not have E in his local database anymore. Does that sound like something that can be handled through filtered replication? I hope that my system will be able to handle hundreds/thousands of databases with 1-100 users in each database; each use having access to ~1-10 database, thus potentially having access to ~1K user documents locally (thus is really just an early guesstimate). The system currently doesn't allow users to manage their own profile but it's indeed a requirement. I'll probably only allow users to modify their own information while online through a dedicated API endpoint checking the user's identity instead of letting them directly write to the "persons" database. Sébastien.
