Ooo I didn't know it had that functionality! I will expand my use case: Our services will be deployed into multiple customer environments, and we need to control both user access to those services, as well as limit communication between services across customer environments. We will have a central spicedb replica set in our own k8s cluster which each service from each customer environment will make permission check calls to - therefore, I would prefer those services to have read only access to the spicedb instance. Does that mean that multiple preshared keys + key rotation is not enough for my use case?

ah, I see. you basically want scoped access, where each token/key can access only a subset of the schema and perform a subset of operations (read only, etc)?

I had to think it through some more, but yes! In fact, some services should be able to create/delete relations for specific schema objects

yeah, that's scoped token access

Ah interesting - is there a public roadmap that might indicate a rough estimate for the release date?

no public timeline on it yet; as it is a paid feature, it'll be prioritized based on which paying customers need it

Thanks for the explanation, that really helps. I will assess our options with the team!

glad to help!

Great thanks - I'm sure I will have lots of questions!

one thing to note: if you need "just" readonly access, you can in theory deploy a "public" facing SpiceDB cluster in read-only mode, and have the "private" cluster in read-write mode, both speaking to the same datastore

Ah that's pretty flexible - the majority of our traffic to spicedb would be permission checks, so a public readonly instance would be great - more food for thought, thanks