You seem to be aware of the past conversations around this topic. So as you may know, the philosophy of RS is to stay as simple as possible for a personal data store, which only provides public access to others via URLs in the public folder. And as other people’s identity isn’t known to the RS server, there cannot be any complicated permissions/ACLs for such use cases.
So, considering this background, your approach is much simpler, and I think it could work. However, I’m not sure (authorized) foreign access should ever make it into the protocol as a principle design decision. The way RS would currently allow for this is by exchanging data via a p2p (or other) transport and simply storing a version in every collaborator’s own storage. But this is not ideal for scenarios where you want to remove someone’s access to data entirely, of course, since they will always have a backup of the last version they were able to access.
For the sake of argument, let’s say the outlined approach is something we’d want to add to the protocol in some way. One problem I see with it (as is) would be that you have to keep track of which token belongs to whom, which requires a bit more detail in the spec and implementation than only adding tokens for arbitrary subdirectories. I guess there would have to be the possibility of adding a string of information to the token, but it could become rather messy if different collaborative apps use different identifiers for other people.
What do others think? Maybe @michielbdejong, you had some (new) thoughts about it in the last couple of years?