Has there been any discussion on exposing a flatte...
# spicedb
j
Has there been any discussion on exposing a flattened graph of relation/permission changes through the Watch API? For example, let's say that a user has view access to a resource if they are a member of a particular group. If a user is added to the group, two new watch responses would be emitted to clients watching for changes: 1 for the direct group membership change and 1 for the indirect view relationship/permission change as a result of the group membership addition. As another example, if a parent resource has 10 children and view access is revoked from the parent for a particular user, then the watch api would serve 11 responses: 1 for the direct view relationship change on the parent and 10 for the indirect changes to it's children. I recognize that serving a flattened relation change stream could produce a huge set of changes for deeply or widely nested sets with lots of indirections, but it would give clients a simple and streamlined integration to build access-aware search indexes from. This would be in favor of the Lookup API for continuous indexing of any changes in the flattened graph. Doing this would allow external clients creating access aware indexes to not have to "rebuild" the graph of relations.