going back to a previous conversation: > if you choose to not use ZedTokens, your staleness risk is minimal but still real: if you're okay with staleness for at most a few 10s of seconds (its usually configured much lower), then you can simply not use ZedTokens at all for the "configured much lower" part, does that mean there's some part of the configuration that allows you to dictate how often the cache is invalidated? I ask because my team asked how

minimize_latency

works, and I realized that I'm not actually sure when and how SpiceDB would do the work of going to the datastore and recomputing a particular subproblem if you've got

minimize_latency

selected. (it's obvious to me for both

at_least_as_fresh

and

fully_consistent

- it's looking at the zedtoken and discarding any results that are less than the specified revision)

or is it kind of indeterminate, and that's a part of why

minimize_latency

is discouraged?

> allows you to dictate how often the cache is invalidated not quite, but you can adjust a value that influences that

minimize_latency

is encouraged

but only if you don't need a hard guarantee; otherwise, use

at_least_as_fresh

(most callers can just use

minimize_latency

)

so that way

minimize_latency

works is: SpiceDB will choose a revision from the database within a quantization window (default: 5s + some additional leeway) and then use that revision for the request. so long as the caches are at least as new as that revision, they are used

at_least_as_fresh

just specifies that minimum revision directly

--datastore-revision-quantization-interval

controls the

5s

when you specify

minimize_latency

(or just don't specify anything, since its the default) you're telling SpiceDB to pick a revision that is most likely to already be cached, without any other hard requirements

when you specify

at_least_as_fresh

with a ZedToken (which has a revision ID encoded), you are saying "the cache must contain at least this revision to be used"

fully_consistent

is "pick the latest revision from the database and use it"

gotcha. that helps a lot! thank you!

Hi, I'm doing some proof of concept work for spiceDB/Zanzibar at a larger company. Is there a way to define "indirect objects" in a relationship tuple? Specifically, I want to say that Alice can share X Document but only with the billing team Bob can share the same X Document but only with the marketing team Alice is not allowed to share X with the marketing team And then additionally, could Alice be restricted to share with only one specific person?

so the permission you're checking has a resource, a subject and some additional context?

Yes. The additional context almost always being a specific individual something, like a person or an ID

so generally there are two solutions for these kinds of questions in a Zanzibar-like system: (1) issue two Checks, one for whether Alice can share the document, and one for whether Alice can share to the billing team

(2) define a synthetic resource that combines document X and the billing team (or document X and alice, depending on the use case), and issue a check over that

e.g. can Alice share

documentX-to-billing

or can

documentX

be shared by

alice-to-billing

two checks are usually cleaner

1) isn't viable unfortunately, because it needs to be in the context of that specific document. 2) that's an interesting approach. I'll look into the feasibility of that. Thanks for the insight

longer term, we have the caveats proposal, which would allow you to define additional restrictions on relationships

so then you could say: "alice has share permission on document X, but only for teams {a, b, c}"

Any sort of expected timeline on that?

nothing concrete as of yet, but please put your

+1

and use case in the issue

in this case, I think 1) might still viable because the first check would be "can alice share this doc?" and the second check would be "can this doc be shared with this other person?" (and their relationship via the billing team is part of the permissions check resolution)

it only becomes a problem if the restriction of whom it can be shared with is due to the nature of the share-r, e.g. alice is a billing admin, and so therefore she can only share docs with the billing team

I'll look into it and see if I'm able to do it in two checks, or if that's not practical

I was able to do it in three checks, thanks for the encouragement