Hey folks, We just experienced something off in our spicedb instance. LookupNamespacesWithNames went up like crazy. Our db shows that the following query went up x600 in traffic, where all the rest of the traffic remained the same: SELECT serialized_config, "timestamp" FROM namespace_config AS OF SYSTEM TIME _ WHERE ((namespace = _) OR (namespace = _)) This created a hot replica in our crdb database and a bad latency increase. After a reload of spicedb everything went back to normal. We are using "v1.45.4". We haven't changed the schema recently, nor there was a deployment on spicedb, change of traffic to it. Any clue?

Has anyone ever tried pointing SpiceDB at TiDB as a MySQL datastore?

Folks, in about 45 mins @Sam and myself will do a demo of a photo-sharing app with fine-grained permissions using spiceDB. Sam built this as a demo for Kubecon last week. We'll be in the spicedb-live channel

Are there any plans on adding a consistency option to

Watch

? And if not, should I just do a uesless request to fetch a 'latest' ZedToken? I'm writing a few integration tests against in-memory SpiceDb and running into the issue that watches are capturing results from before they were started

Hi. any chance to see the recording?

Anyone using spicedb to authorize access into VMs?

SSH*

hi, we want to upgrade our spicedb version from v.1.0.1 to v1.46.2, but according to what I read we need to run migration, is there another way of doing it without using the operator suggestion? if so would it need to be in stages according to each version that has been released?

hi, what are the best practices for handling schema migrations?

Hey folks, What is the advice to implement workspaces (think of Slack, Figma, notion...) in Spicedb? I would basically want to do something like, give me all the documents in this workspace that user can access. I can use caveats, but the [documentation discourages their usage](https://authzed.com/docs/spicedb/modeling/attributes) > In almost all cases, caveats should only be used when data required to evaluate a CheckPermission request is only available at the time of the request (e.g. user's current location or time of day). Using caveats for static data (e.g. a document's status) can have negative performance impacts. Static attribute data should always be modeled in the schema using patterns similar to those described above. Alternatively, I can use a specific user per workspace. But then, it's hard to keep the correct status up to date. For example, groups cheers

I have a question.....Latency wide, what is the average shaving off time when indexing via Authzed materialize? What has been the overall consumer review of materialize? I am wondering whether this API is critical, "good to have" or borderline superfluous. Would it make more sense to use it on an AWS cloud-based server, when latency may be also effected by other issues such as server bandwidth restrictions and geography or to have it operational on an own server? How effective would materialize be if the local server is also tethered to satellite databases such as Google Drive and/or DropBox?

it depends on the complexity and shape of the data. Materialize is typically used for a subset of your schema, for permissions that you are often LR/LSing or you know are deeply nested or very wide. In those case, if you are making

minimize_latency

calls, it can turn an LR from hundreds of ms into single digit ms. Materialize is only available on our dedicated platform, so it is always run by our team on cloud servers; if you run multi-region, we can deploy it in each region in which calls are being made. Not quite sure what you mean by "tethered" to an external database, but if you mean you're syncing from those inward, that's fine - you just need to be prepared to accept some staleness (a few seconds usually)

I have a question, im currently exploring Auth systems to replace custom auth across multiple applications we maintain. One problem I'm not able to decide on is that we also store additional metadata with users permissions that is retrievable. Kind of like being able to tell the expiry of your permission in the List APIs, both by user and by object. Is there a prescribed way to store and retrieve additional metadata along with permission tuples?

Saw that there is a similar issue open: https://github.com/authzed/spicedb/issues/1970

what's the use case? we've explicitly avoided relation metadata because SpiceDB is not and will never be a general-purpose key-value store, and we recommend storing that kind of data outside of the authorization store.

The use case is that we have an in house auth service that manages your entitlement for trading strategies. You can define a metadata on the entitlement which is an integer count of historical days you can have access for. The strategies are in a nested org/fund/directories/ structure and permissions can be granted at any level. In the api we have to return strategies by users along with the metadata. If i store it elsewhere i have to implement the tree traversal again which kills the usp of spicedb doing it for me

I understand that SpiceDB is not a general purpose data store but im after a scalable solution to define a design pattern on how to solve this use case. Goal is to minimise duplication of logic and keeping it consistent

Any ideas or dropping this is the best way forward?

Is it expected that relation schemas tend to be more static/long-lived while permission schemas grow and evolve more dynamically? Is there a good pattern to manage this, with composable schemas or something else? I'm finding that relations are mostly driven by existing databases and don't change much (as long as the sources themselves don't change!), but permissions are almost entirely driven by the needs of individual use cases, which makes adding new permissions more common. It is kind of "weird" to update the schema to accommodate new queries. On a related note, if I need union/intersection, is adding a new permission better than doing two checks in a CheckBulkPermissions request? Would they be equivalent in practice?

> It is kind of "weird" to update the schema to accommodate new queries. That's why permissions and relations are distinct: it is expected to update the schema to change permissions > On a related note, if I need union/intersection, is adding a new permission better than doing two checks in a CheckBulkPermissions request? Would they be equivalent in practice? Yes, adding a new permission is better, just from a maintainability perspective

hmm... i wonder if it'd be possible with check explains?

define it using caveats, send a request with context for authz and then send a request with explain and without context for the retrieval

see `with_tracing`: https://buf.build/authzed/api/docs/main:authzed.api.v1#authzed.api.v1.CheckPermissionRequest

and you should be able to test with

zed permission check --explain

i think you might not even need a second request 🤔

If i have to join this with the List Objects/User. I will have to call the explain api per row of output right?

Hello again, I assume that Materialize is not an add-on but comes preloaded with your dedicated platform SpiceDB? Do you already provide this application to customers outside the US? From your website I see some big names as current customers. Have you already implemented Materialise to national or regional healthcare providers? We are working with a national health service outside of the US; however, this entity was made up of smaller trusts and some of their data was partitioned separately while some databases were accessible throughout the board. These trusts are merging AGAIN, therefore, they are looking to streamline and integrate the current system and possibly make comprehensive use from the word GO of Materialize for initial audits. Any ideas, tips or experiences?

Hi folks! SpiceDB dev here, would adding a flag to disable tracing for healthcheck calls be useful?

Hi we have the following schema: """" definition user {} definition usergroup { relation direct_member: resoucre_pool_group permission member = direct_member } definition resource_pool_group { relation parent: resource_pool_group relation owner: user | usergroup#member relation can_edit: user | usergroup#member permission edit = parent->edit + owner permission explicitly_permitted = owner permission can_edit_permission = owner + can_edit } definition project { relation resource_pool_group: resource_pool_group relation responsible_team: usergroup relation owner: user | usergroup#member permission edit = owner + responsible_team->member + resource_pool_group->edit permission create_deployment = owner + responsible_team->member permission resources_editor = resource_pool_group->member } """" and we have about 10k objects, when we use checkbulk it takes something like 3 sec, is it normal or we need to change your schema for performance improvement?