The introduction and Abstract don't feel right to me. What you have in the introduction seems to continue in the Abstract. I actually think all of that should go in the detailed description of what is the problem and how we trying to solve it.

thanks for your comments and I agree, this is mostly a paste from earlier, less structured, write-ups

I think this paragraph and the goals are probably all thats needed for an abstract.

I think it might be clearer if you write this as:
design doc's with an _access field will be ignored in an access database

yeah I must have missed this one, I have it that way further down

What happens for a user that previously had access to the document? Is there a way to notify them that they have lost access?

not as per this RFC, but we could consider a mode to _changes, e.g. /_changes?access=true that would include new rows with id/rev/revoked:true that clients could opt into.

I don't think that needs to be solved on CouchDB level. In other systems, if my access gets revoked, I don't necessarily get notified either. It would be easy enough to solve on an application level

The main thing here is that notifying the users device (say) allows the application to remove the document from the users device as a UX convenience (clearly there is no security benefit to this as users could have other copies).

Can you escape the _users. Everything below is ital

s/probelms/problems

A change of this nature leads to pretty gnarly code in consumers of this information, as the type of the data in _access changes. I think we can have a better route here which removes the need for type changes and instead uses extra values on existing fields.

As a suggestion:

"_access": [{"shirly": "readwrite"}]

Version two might extend this to allow:

"_access": [{"shirly": "write"}]

And version 3 (later you note that v1 doesn't support multiple users in _access):

"_access": [{"shirly": "write"}, {"mike": "read"}]

While more verbose, it feels like the most future proof way of expressing this is as follows, which allows us to fill in extra fields later if needed:

"_access": [{"user": "shirly", "access": "readwrite"}, {"user": "mike", "access": "read"}]

For example, adding an ability via an extra field to allow a given user to add and remove users to _access for documents they "owned". Right now we are only dealing in read/write permissions, whereas in later parts of the document we alter this concept to documents "owned" by users; I don't think the access model here captures ownership explicitly, which is likely important as we expand to "sharing" type scenarious.

"user" perhaps for this RFC iteration, as later it's state multiple users are a future thing.

The main thing here is that notifying the users device (say) allows the application to remove the document from the users device as a UX convenience (clearly there is no security benefit to this as users could have other copies).

We've gone from the concept of "able to read and write the document" to a concept of "owning" a document, which is a very different thing (one might imagine that an "owner" can grant "read/write" to a "non-owner", where "owner" is really conveying something like "admin of this document").

Here, rather than owner, I think right now we mean "documents can only have one or zero entries in _access at any one point".

It's hard for me to see here what the behaviour of _access: [] is.

This feels like a more complex security issue - the suggestion that applications work around this feels a little weak given that the user themselves are able to pollute the global document space via direct API access?

I guess here our suggestion is either "use a separate database for system docs" or "use a VDU to prevent system docs with _access set"?

I suggest that using the _access field as a flag for "don't build this on the server" will cause use problems later because it's implicit behaviour. It also feels like it might get in the way later of using this field to control access to views on the server.

Instead, this "don't build this on the server" feels like a new API concept to support the mobile user case of "spoke ddocs" which I'd feel more confident drawing out as just that via either specific flags on the ddoc or even new API paths for the ddocs (/_spoke/design/...).

Does the _access field exist as revision-specific metadata? If it does, then with this implementation we're saying that the _access field on a given revision may not be accurate with respect to who can view this revision. That feels hard to reason about.

Perhaps we are imaging that applications may typically deal with this by creating a document copy with the altered _access?

This may be easier than it seems for documents that, say, typically only differ in a a few low-cardinality fields over their lifetime.

Is there a way to get the documents for which the access has been revoked from the changes feed?

Let's say that a user replicates the documents they have access in a pouchdb. Later, one of those documents is updated and the access for the user is revoked. If the user triggers a replication from CouchDB to PouchDB, they won't get this document from the changes feed (as I understand), and the document will still be in PouchDB with the old values. Is it correct?