Joseph Schorr

> Putting the burden on the client to invoke a WatchAccessibleResources request per resource type would be non-ideal for the majority of the use cases that we want this API...

> A client such as myself will ultimately be invoking this API multiple times (concurrently) to watch a variety of resource types (e.g. Projects, Tasks, Documents, etc..). That is my...

> I don't see why an external Watch service couldn't also create a read-only connection to the changelog of the persistent store and then serve the Watch API outside of...

@jon-whit Yeah, that's fine. You'll also need the relation then too. I originally let it out because originally the caller was specifying the object information, but now that the API...

@gonzalad If you intend to use the tiger cache with roaring bitmaps, correct.

@gonzalad If you can find a stable and supported 128-bit roaring bitmap implementation in Go and other languages, we can remove that restriction

`~>` is certainly simpler to implement, but not sure if there is a strong connection between `~` and the intersection operation here

Another idea: `requirement->&viewer`, since it is the intersection of all the `viewer`'s

@phdowling Right now you'd need to issue the checks yourself and compute it client side. Intersection currently only operates over distinct relations, not within one.

Suggestions are welcome for the operator to use, as it is the main blocker for adoption