Hi! I'm looking for feedback on my SpiceDB schema that models hierarchical permissions and want to make sure I'm using the right patterns (completely new to SpiceDB/Zanzibar). Here's my current model: - Resource hierarchy: -

event

-> parent of

instance

-

instance

-> parent of

instance_team

- Permissions inherit top-down (e.g.

event_owner

⇒ permissions on all instances and teams) - Roles are currently predefined: -

admin

(global) -

event_manager

-

instance_manager

-

team_manager

-

team_user

,

invited_team_user

,

pending_team_user

- Each role maps to a fixed set of permissions - Users with enough power can grant custom direct permissions instead of assigning a role Things I'm unsure about: 1. Roles vs direct permissions vs IAM-style role bindings. I already have inheritance working via

parent->permission

. My main question is whether it's worth refactoring toward the IAM blog pattern (

role

+

role_binding

+ intersection) only to support custom permission bundles, or if keeping predefined roles + direct permissions is reasonable 2. I want to guarantee that a user cannot grant a permission they themselves don't have. My understanding is that this can be enforced using explicit

grant_*

permissions checked by the application before writing relationships. Would you agree? 3. I also want to optionally support expiring permissions. Is native relationship expiration the preferred solution here, and is there anything I should know when mixing expiring direct grants with inherited permissions? 4. I've seen in the previous thread that having a global

admin

role unioned into many permissions can cause issues with LookupResources and that it can be solved with impersonation. Is this something that should be supported by a permission in the schema like can_impersonate?

1. unless you need custom roles, it is recommended to keep the well-defined one. if you need custom + well-defined, its usually better to still keep the well-defined ones UNLESS you see yourselves moving to fully custom in the future 2. yep 3. yes, use the native support and declare the subject as

user | user with expiration

to support either without it or with it 4. it can be, yes. In addition to global's causing LR issues, its also risky: if you accidentally grant global permission, now users can do anything. We only recommend supporting impersonation on, say, read-only perms for that reason. It should be noted IF your global admin role only has a few users, its fine for LR

1. so far I don't plan on having true custom roles but my frontend allows the user to give a predefined role to someone or only specific permissions available from a predefined role, ie. they could start with the predefined role's permissions and remove a few ones 3. alright, so as I see it I need to add

with expiration

to most relations in my schema 4. it's likely that I'll be the only user with admin role for now but I don't see this growing past a few users, at least not anywhere in the near future Can you look at this sample of my schema and tell me if this looks right to you? For example I'm using a lot of permissions as pass throughs to relations because of this warning:

Arrow event->owner under permission "event_owner" references relation "owner" on definition "event"; it is recommended to point to a permission (arrow-references-relation)

But I've since seen the IAM example on the playground and it has the same warnings. What's the downside of doing it that way? https://cdn.discordapp.com/attachments/1467953111510552742/1468009150490611927/example.zed?ex=69890d0f&is=6987bb8f&hm=2eb05a049b2ab19ad516ad3d85d510b2de6086a1f349bd7c40513ecdc60daca3&

nothing concrete

Yeah that makes sense. Thanks a lot for the answers!

I will make one suggestion

permission someperm = instance->owner_manager_or_event_manager

for this one, that means in the instance definition I need a permission

permission owner_manager_or_event_manager = event->owner + event->manager + is_manager

, so I guess that also applies to the other permissions where the definition is walked multiple times?

yeah, basically

Thanks a lot, I'm starting to get the hang of it

someone recently showed off this tool: https://www.spicedblens.com

Yeah I tried it just before I asked, it doesn’t seem to work or I haven’t figured out how to. When I go to the schema visualizer it just shows some template

ah, that's frustrating

I was gonna try to fix it myself but it’s closed source unfortunately

oh what? that must be a recent change

Yeah I was a little iffy about downloading it because it looks sketchy, the GitHub links on the website are broken except the report issues one which points to a repo that’s just an issue tracker, no code

that's good to know

No worries! I think I can get by with listing my test cases to make sure I have properly designed my schema, it’ll just be less visual in the meantime haha

here's a thought

For big schemas yeah that looks alright to me although I really don’t know a lot about spicedb, that’s probably something you’d need feedback on from experienced users. But I think you could add options to customize the generated image so we can choose what to render when the schemas get too big?

yeah, my thought is that we'd use some sort of visualization library that renders into a canvas that you can pan/zoom around

I really like the Supabase schema visualizer but I’m not sure if it’s a custom made lib or an oss one, I don’t see it in their GitHub repo so far

i'll check that out as well

Never mind it is, it’s based on react flow: https://github.com/supabase/supabase/blob/master/apps/studio/components/interfaces/Database/Schemas/SchemaGraph.tsx

ooh will check. thank you!

Sorry, didn't see this until now. Thanks for not forgetting about it! It looks really nice, much more usable in my case. One minor issue is that there are contrast issues with the automatic background colors https://cdn.discordapp.com/attachments/1467953111510552742/1472963235920482375/CleanShot_2026-02-16_at_15.29.442x.png?ex=69947b69&is=699329e9&hm=f34f697570b90ae2ff8b9b2922429debdb4d437b610bff4734a12ac43ea6772f&

ooh, that's a good call. i'll make an issue.

Overall it's so much more readable tho, looks really great

good! i'm glad. i've got a few open issues for things that i noticed as we were rolling it out, but lemme know if you find anything else.

It's more of a UX suggestion but are you using any kind of [layouting](https://reactflow.dev/learn/layouting/layouting) in the visualizer? I think it could benefit from having a way to automatically layout the nodes

yes, it uses [dagre](https://github.com/dagrejs/dagre) to do a bottom-to-top hierarchical layout

Yeah it definitely gets busy but I don't think for my test schema there is much more that can be done other than not having the relationships boxes messing up the layout (but I think I saw an issue on GH for that)

ah yeah the issue wasn't quite for this. i might play around with letting what are currently labels on the edges be "nodes" instead such that they participate in the layout.

Could be a good middle ground, or maybe a toggle to show/hide the relations? Don't know if that's possible

a toggle could work too 🤔

Having them as nodes would be easy with the auto layout for sure though

like for each edge, or a global one that shows/hides?

I think global would make more sense rather than having to toggle each one individually

the edge itself would show a tooltip on hover

Oh yeah that would look cleaner

cool, captured that here: https://github.com/authzed/playground/issues/115

I don't think the relationships are critical enough to be always on when you're just trying to visualize your schema but I have little experience in that domain lol

no, that's good feedback

Yeah makes sense. I'm right in the middle of it so I'm just suggesting anything I can think of while I play around with it

yeah keep it coming! we wanna make this stuff as intuitive as it can be