because it ensures the New Enemy Problem cannot occur, which is the primary purpose of ZedTokens

in other words, if you're updating a resource's content and what to guarantee that the content changes are gated on the permission data at the time the content updates, you should store the ZedToken at the same time you store the updated content

if you don't mind some lag on permissions data, then you don't need ZedTokens at all

how much is some?

its depends on the SpiceDB quantization window configuration, but default is ~5s

5 seconds of response lag, or data freshness lag

data freshness

in other words, if you always make a

minimize_latency

Check call, the data it uses could be out of date up to 5s

because it could be using cached results from 5s ago

i see

for most callers, this isn't a major issue

but the scenario where it can become one is where you do something like: (1) remove someone from a document's permissions (2) write something sensitive into the content of that document

(3) that user checks to see if they can read the document, and they get access from timestamp before #1

but now they can see the sensitive data written in timestamp #2

with a ZedToken, you'd issue a check at #2, then write the ZedToken alongside the content update

and then when the (now no longer valid) user tries to access the document, you send the ZedToken along with the Check, the system ensures that the data available at the time the content was updated is used

and thus, the user does not get access to the new, sensitive content

this is the New Enemy Problem

but it only applies IF you have that scenario, or ones like it

how much more expensive is fully consistent?

its bypasses the cache entirely

so, quite a bit more expensive in the common case

if you have concerns about consistency, I would recommend storing ZedTokens next to the other items in your database, or wherever

you can just store the ZedTokens in something like Redis

so the zedtoken is per entity, its not like a global consistency pointer?

it is global

yeah, thats what we're looking at doing

but in general you should only need to store it per resource

yes, you can do that

if you do store the result from any write