title: CouchDB replication strategy with dynamic groups of users
body: <p>This is the situation:<br>
  We have a series of users who share some documents. The documents they can share might change throughout the day, so can the documents themselves (changes and deletions). The users can change some information on the documents.<br>
  E.g.<br>
  Users | Documents<br>
    A   |     X<br>
    A   |     Y<br>
    A   |     Z<br>
    B   |     X<br>
    B   |     Z<br>
    C   |     Y    </p>
  
  <p>Possible groups: A+C, A+B</p>
  
  <p>The server on CouchDB is a replica of a SQL Server DB with this data, an ETL takes care of managing changes on CouchDB. However, the CouchDB database is replicated on each user phone via PouchDB.              </p>
  
  <p>The goal:<br>
  To replicate changes and deletions accordingly.          </p>
  
  <p>What we've tried:<br>
  1) we figured we'd structure our documents with a list of users that can access to it. Each document would have a "Users" array and then a filter in the design document would take care of the replication to the clients. Unfortunately document deletions and document changes that won't pass the filter (e.g. a user is removed from the array) are not present in the _changes feed so cannot be replicated accordingly on the clients<br>
  2) database per user. This is not possible, because users need to see each others work on the documents (they share them)<br>
  3) database per group of users. Pretty much the same problem as the first solution, but worse. In fact:<br>
  - groups of user can change and no longer be present: how do reflect that client-side?<br>
  - a document can shift to a new group: it will have to be redownloaded from scratch. This greatly increases the download size<br>
  - the same document can be in more than one group! (see example above)<br>
  - each client would have to know in which group she is everytime she logs in and replicate multiple databases. Then on the return trip you'd have to know on which databases the document was present        </p>
  
  <p>Is there a recipe for this situation? Am I missing an obvious solution?</p>
  
  <h2>EDIT</h2>
  
  <p>Partial solution for case 1:</p>
  
  <pre><code>    localDB.sync(remoteDB, {
          live: true,
          retry: true,
          filter: 'app/by_user',
          query_params: { "agente": agent }
      })
      .on('paused', function(info){
          console.log("paused");
          localDB.allDocs().then(function(docs){
              console.log("allDocs");
              docs.rows.forEach(function(row){
                  console.log(row);
                  remoteDB.get(row.id)
                         .then(function(doc){
                      if(doc.Agents.indexOf(agent) &lt; 0){
                          localDB.remove(doc);
                      }
                  });
  
              });
          });
      })
      .on('change', function(result){
              console.log("change!");
              result.change.docs.forEach(function(change) {
                  if(!change.deleted){
                      $rootScope.$apply(function(){
                          $rootScope.$broadcast('upsert', change);
                      });
                  }
              });
      });
  </code></pre>
  
  <p>Each remove() is giving me a 409 (conflict), and rightfully so. Is there a way to tell Pouch "no longer consider this as replicable and just remove it from my DB?"</p>