hey team, qq on at_least_as_fresh_as, just to make sure i understand the doc correctly:

definition user {
  relation is_visible: user  // self relation 
  permission is_visible = is_visible 
}

definition account {
  relation owner: user 
  permission read = owner->is_visible 
}

we're storing zedtoken per object, so there's token t1 for user , and token t2 for the account. Now, user's is_visible is removed, so there's a new token t3 stored for user. If we check read permission on the account after, the token stored is still t2 (before user update), would the check permission result use the cache and not necessarily reflect the update in user relation? In other words, could the read permission check on the account at this point actually still return true?

My understanding is that, if the checkpermission lands within the quantization window and it's usign t2, it may give u true, yes

yes - this is one of the nuances around the new enemy problem. the idea is that if the contents of the object haven't changed from the perspective of the user, they haven't gained any new information. that said, i don't understand this schema snippet. why is the important relation for the calculation on the user rather than between the document and the user?

it's a stylized example - we are trying to capture user sharing consents which is a user-level thing, and there is another account level consent setting. so the full schema on account is more like

permission read = is_account_visible -> (owner->is_visible)

no - it's more that you'd be writing a relation between the document and the user, and then you could store that zedtoken on the resource at that time, and then reading the document and providing the zedtoken will give the behavior that you're looking for

yea - and just to make sure i'm understanding right, with the current schema even if we query LookupResources then attempt to read the document directly, it could still return a yes instead of access denied

yeah - you'd need to give the zedtoken associated with the user, not the zedtoken associated with the resource, for this particular schema

relatedly - how do we know what the "max staleness" is for the scenario above? i've seen 5s ish floated around but wondering if there's an upper bound, like after x secs we know for sure the permission check will return false (correctly)?

it's your configured quantization window (which defaults to 5s) +- a margin of error

yup understood! tyvm