For this to work, unless I’m missing something, you have to choose between having a quorum of nodes reaching a consensus about rejecting future writes, or you have to choose to reject all writes that were causally dependent on a rejected write.
Something like this is definitely possible with an adapted version of Yjs. While this is a super interesting topic, I don’t believe that something like this can ever lead to a good user experience. It is never good when edits simply disappear after a time (the reason being that you synced permissions with another peer, so your causally dependent changes are now all getting removed). It is impossible to build a mental model to understand why this happens for casual users.
Another disadvantage is that you must associate a user and a timestamp with all operations that are created. You need to propagate this information so that others can potentially reject them when a user was revoked access in the past.
If I would tackle this problem, I’d try to find a solution that can be easily expressed as a mental model. Ideally, there is a central authority for authorization on a document. But if that’s not possible and we need to have completely decentralized authorization management I have two other ideas:
One approach would be to write edits to a blockchain. Users need to check permission on the blockchain before accepting changes from a user. The blockchain would also help to keep all permissions distributed when users are offline. You want to prevent that a user shares secret information with a user that was revoked access. If authorization is only handled in a small group of users that have access to the document, it might take quite a while for this information to propagate to all clients. My assumption is that the document will be opened very sporadically. The users might live in different timezones and only open their computers for a few hours a day. In some cases, it might take weeks until this information is propagated. Blockchains (or any other always-available entity for authorization) is an appropriate solution for this kind of problem.
Another approach that would work well for pure p2p applications is to fork the document to a new “room” when permissions from a user is revoked. The client that forks the document will propagate information about the new “room” to the other users in a way so that only users with permission can read it. The user that doesn’t have access anymore won’t even know that they don’t have access anymore (unless you make it explicit).
The fork approach has the advantage that there is a clear mental model of what happens when permissions change. Users that are still in the old room and catch up eventually will have to carry over their offline edits manually, which makes this action explicit. This approach also doesn’t have any additional overhead (like storing user information and a timestamp with each operation).
But these are just a few suggestions. Different solutions have different tradeoffs. I believe that the proper permission model is very application-specific and can’t be generalized.