especially with LLVM support

yea

it was the biggest motivation for me to pick up rust

the almost non-existent runtime makes it ideal for it, imo.

yeah, although it does make it harder to display JS in the browser

we'll have to see how that all shakes out if/when WASM gets DOM/API access

yea; very interesting space. Especially serverside

there are some rust browser ui frameworks floating around, like https://yew.rs, but that's. a bit ahead of the curve imo.

yeah

What's the most appropriate way to do a recursive relationship deletion? Let's say for example there's Folder A -> Folder B -> Folder C -> Folder D -> File, when we delete Folder B, Folder C -> Folder D -> File relationships should be deleted too. I couldn't see anything in the docs that made it crystal clear.

I don't believe there is support for such a thing. Ideally the client application has that information and is able to traverse the subgraph and issue deletion to SpiceDB as one single transactional delete. Feel free to open a feature request!

Thanks!

Hello, I need to design a schema where two criteria have to be met for a folder access: Membership of a user group and a license for the module. I came up with the following schema. I used & for a logical AND operator and it seems to work. However, I did not find documentation on the usage. Is this a good approach? Can you point me to some documentation? definition folder { relation reader: usergroup relation editor: usergroup relation shown_in: module relation edited_in: module // direct children only relation direct_child: folder permission edit = editor->member + organization->admin permission read_artifacts = reader->member + edit permission edit_in_module = edit & edited_in->access_to permission read_in_module = read_artifacts & shown_in->access_to } definition module { relation owner: system relation has_license: user permission access_to = has_license + owner->support } definition usergroup { relation direct_member: user permission member = direct_member }

yep, this is generally how'd you require access via multiple paths. you could also define

reader

to take in

reader: usergoup#member

and then you don't need the

->member

, but that's just a small difference in approach

in a microservice environment, I figure I should use one spice deployment for all services, and prefixes on a domain/service-basis (whatever makes sense scope-wise). However, the documentation notes in one part that > SpiceDB supports an optional prefix for Object Types that can be used for enforcing security boundaries when multiple tenants are using the same deployment. But in a different piece of documentation, it's stated that > For SpiceDB, prefixes can be used to logically group types, but are otherwise unnecessary. I would really like to restrict write access based on namespace/prefix, such that services can only update the objects and relations they own. Is this possible in Spice?

the enforcement has to be done in your own code currently; we have a planned enterprise feature to build in smarter and configurable security boundaries that would allow this to be done directly

we'll get the docs updated to make that more clear

Authzed.com does use the prefix for security separation, but it has its own code in front of SpiceDB to do so

On that note, is there some good reference of "this is how we'd recommend you implement it for production use", e.g writing a wrapper service around it. I generally find, with most software, that there's a distinct lack of "this is what a production scenario might actually look like"

if your intention is to have the callers be completely isolated, then we'd generally recommend running isolated stacks

since then you don't add any overhead for the security checks and you won't have noisy neighbors

Nah, I want to restrict writes but not reads

And support declaring dependencies on object types in other prefixes

so this is what our smart token solution will be doing

So I can declare a

user

that depends on

organization

, but I can't update the

organization

if you want to implement something similar yourself, you'd want to write something that exposed the same gRPC API as SpiceDB, and then just does checks before passing the actual calls along to SpiceDB

yeah, guess I could grab the definition from buf and implement the same server to just proxy back to spice

could also modify SpiceDB to use a gRPC interceptor, although that would be harder to maintain longer term

yeah that seems more painful

I guess there'd be a slight latency penalty with it, but shouldn't be too bad