Mmmmh I see, thank you @User! But if I'm understanding correctly that would mean that, when writing my relationships, I need to write both: -

flag:new_admin_dashboard#flag_new_admin_dashboard@organization:my_org

-

organization:my_org#organization@flag:new_admin_dashboard

That's redundant, which makes me sad 😢 For reference, our current system which works very very similarly to SpiceDB (SPARQL-based, also Zanzibar-inspired) is based on checking that a set of relationships exist. So our policy would look something like (this is a made-up policy format):

permission view_new_admin_dashboard: flag:new_admin_dashboard#flag_enabled@organization:{subject} AND user:{object}#admin@organization:{subject}

This does not have the problem of storing duplicated relations, nor do I need the awkward

flag_new_admin_dashboard

relation: I can hardcode a specific flag directly in my policy and have a generic

flag_enabled

relation. I'm super keen to use SpiceDB as it does everything we had to implement ourselves, and very likely it does better! But being able to easily handle feature-flags (and similar things like user settings) is super important for us: is there any other approach I could explore?