well, currently it all goes through the logging interface 😉

tracing usually comes with sampling, so you could limit it to 1% of requests or similar

I might add some additional fluff in the coming weeks, currently trying to set up a production ready cluster though

I didn't see this discussion earlier. Could this also have been configured by setting an environment variable (

OTEL_EXPORTER_OTLP_INSECURE

or

OTEL_EXPORTER_OTLP_TRACES_INSECURE

)?

I am trying to understand how subproblem caching works. Specifically, how is the locally cached result for a subproblem invalidated when some change to a relationship results in the subproblem outcome to be different. Assume for this discussion that the application does not care about the new enemy problem and therefore does not pass a ‘zedtoken’ in the check request.

I think it can. I thought that the other providers also defaulted to WithInsecure, but if that's wrong, it might be worth reverting that and just suggesting the env var.

every call to SpiceDB is assigned a revision; if you pass a ZedToken, then you're telling SpiceDB the minimum revision to use. If you use

minimize latency

, then you're asking SpiceDB to choose a revision to use

every result is cached based on a revision

so, if you choose revision

4

, but the last cache was at revision

3

, then the cache won't be used

since every subproblem is computed using the same revision, they all move in lockstep

We don't specify

WithInsecure

with the others, and I agree that this should be done via env var instead of a default. This would prevent SpiceDB users from configuring otelgrpc with TLS. https://github.com/jzelinskie/cobrautil/blob/855a6821f7f0bb9ccbb997f2a6f854ac6ca4d0c2/otel.go#L101-L110

I reverted the change.

I have a question in modelling permissions. Are there some best practices to model global permissions in spicedb? Lets say I have a video service and users have view access to some videos. Furthermore there are some people (but not all) that can flag videos but when they can, they can flag all videos that they can view. How to model this? An example could be

definition user {}
definition root {
  relation video_flagger: user
}
definition video {
  relation root: root
  relation viewer: user
  permission view = viewer
  permission flag = viewer & root->video_flagger
}

I have the feeling that it should work but it feels weird to make a singleton resource type just for global permissions. Is this a good idea, why or why not?

I do that @LarsRan (called it

platform

rather than

root

but same thing). I don't think there's a problem with it, and I think I read about this technique somewhere, maybe authzed blog

I think I need a primer on revision, zedtokens, consistency guarantees. - Is a revision simply a timestamp, or it is a monotonic sequence number. - When you say spicedb chooses a revision, is it a globally significant revision number? Does it rely on datastore capabilities to do this atomically? If such a primer is available, I'd be happy to read it first. Wasn't able to find something at this level of detail.

Alternatively, if you can give me some pointers in code that works too

I also find that v0 APIs allows applications to specify revisions, while v1 talks in terms of consistency levels. Is the consistency level simply a higher level semantic built on top of revision?

https://docs.authzed.com/reference/zedtokens-and-zookies talks about them

a revision is based on the datastore, but it represents a point-in-time

Finally I have read messages that talk about quantization. How does this apply to revisions?

its how SpiceDB is choosing which revision to use for "minimize latency"

Is quantization used to enforce an upper bound on how stale an evaluation might be (when minimize latency is used)?

In other words, if minimize latency is used, is there any reasonable bound to the staleness that a query would be subjected to?

the optimized revision computation is handled per datastore implementation

but there is an upper bound for all current implementations

for CRDB and Spanner it is the revision quantization period + a 5s fixed offset, for all others the max staleness is just the quantization period

are the quantization periods configurable or are they internally chosen by spicedb. What are the quant periods for the different datastores.

they are configurable, all currently default to 5s I believe

thanks

so if using crdb, the max staleness I can expect if using minimize latency is 10s (5+5) by default