Сценарий базы данных CouchDB для каждого пользователя с системой личных сообщений

Мне было интересно, как построить систему, в которой пользователи могут отправлять сообщения другим пользователям. Конечно, каждый должен иметь доступ только к своему почтовому ящику, поэтому для этого нам нужна индивидуальная инфраструктура базы данных. Следуя примеру из http://guide.couchdb.org/draft/notifications.html , мы видим, что пользователи могут просто помещать сообщения в базу данных получателя. Просто и эффективно.

Но что, если мы не хотим, чтобы пользователи знали имя базы данных получателей? Что, если нам нужна система, которая будет разрешать базу данных получателя, просматривая поле от до в документе сообщения (которое может быть именем пользователя, совершенно не связанным с его именем в базе данных):

{
    "to": "john.kowalski",
    "from": "jake.podolski",
    "subject": "hi",
    "message": "..."
}

Похоже как идеальная задача для дополнительного уровня, но тогда это будет неинтересно и не стоит вопросов, поэтому мы попробуем решить ее с помощью репликации:

1. Пользователь помещает документ сообщения в основную базу данных
2. Задача репликации (мы будет иметь задачу для каждого пользователя) выбирает этот документ, используя фильтр, который фильтрует поток _changes по полю с по . Имя «john.kowalski» будет передано как параметр для функции фильтра.
3. Документ заканчивается в базе данных получателей.

Однако это создает проблему, потому что основная база данных должна быть видна всем пользователям! Итак ... что, если бы мы могли добавить также пользовательскую-> основную задачу репликации, чтобы сообщения брались из пользовательской базы данных, передаваемой в основную базу данных, а затем помещались в базу данных получателей (о боже, это становится сложным, мы можем уже зря тратить время, пытаясь решить эту проблему таким образом, но давайте попробуем).

1. Пользователь помещает документ сообщения в свою базу данных.
2. Задача репликации извлекает этот документ, но не может использовать какую-либо функцию фильтрации, потому что фильтр в этом случае принадлежит пользователю, и поэтому ему нельзя доверять.
3. Основная база данных проверяет документ - она ​​проверяет, является ли поле из тем, которое связано с исходной базой данных.
4. Задача репликации, использованная в предыдущем подходе, передает документ получателю.

Здесь есть проблема на третьем шаге (без этого шага пользователи могли бы отправлять сообщения, выдавая себя за других пользователей, заполнив ложную информацию в из поля ) - как мы можем передать дополнительные данные в функции проверки, единственными параметрами, насколько я знаю, являются:

• старый документ
• новый документ
• контекст пользователя (зарегистрированное имя пользователя, роли, база данных, в какой документ записывается)
• объект безопасности?

Обнаружив функциональные возможности базы данных репликатора, представленные в 1.1.0, мы могли передать контекст user_ctx задаче репликации. Возможно ли, чтобы этот объект содержал пользовательские данные, а не настоящую информацию о пользователе? Как это повлияет на стандартный способ, которым CouchDB обрабатывает доступ к базе данных?

Если бы это было возможно, в задаче репликации имя получателя было бы просто заполнено как параметр в user_ctx, тогда функция проверки будет использовать это значение для сравнения с из поле. У пользователя не будет возможности «отправить» сообщение от имени кого-то другого, кроме него.