FWIW I think I've seen it being referred also as "client dispatch" and "server dispatch" hence the confusion

yeah... the way that dispatch gets wired together is very confusing, and i've re-written it twice and can't seem to make it clear

the concept seems clear! it's perhaps more how consistent is the naming. If I spot specific examples I'll let you know

yeah, PRs are also welcome! Maybe since I've tried it twice it needs a fresh perspective

im naming it "dispatch source" and "dispatch target" in my dashboards, but that may not be that different from client/server

what I pbserved is that the prometheus metrics refer to them as

client_dispach

and

dispatch

right, from the server's perspective, it doesn't know it's a target

it could be the top level request that it's handling

right

Hi everyone, found spice DB project recently, watched a couple a couple of videos about it (how to design scheme, etc), and interesting, is it possible to solve "JWT token revocation" problem via spice DB? Let's imagine we have a set of microservices that are connected to the spiceDB and use particular schema and JWT token as auth mechanism, if we want to block user we need to revoke his JWT token somehow and that may have a significant performance impact (we need to check that list on each request), instead of creating black list of users can we just move user to the special group with no-permissions and remove from prev groups (and save his old permissions in case we will need to unlock it somehow)? Sorry if question is kind of "stupid", I am really new to spicedb and will be happy if there are any articles about "revokation"

don't even need to remove from the previous group

you can just add them to a

banned

relation

aha, so, looks like via spicedb we can easily implement "disable" user feature without additional caches, black lists, etc... I will dive deeper in it, thank you!

as a more concrete example:

definition user {}

definition document {
  relation viewer: user
  relation banned: user
  permission view = viewer - banned
}

if the user is placed into

banned

, even if they are also

viewer

, they would not have

view

permission

i missed office hours 😦 sorry i marked interested and ended up having to do some last minute things for work. any good conversations?

some good conversations among ourselves 😛

😂 it happens

how was the time for you? we debated what would be a good time for more people

oh, it was originally good. i am very fortunate i am open pretty much every morning before 12pm ET. are y'all split across timezones? i'm sure later would be better for the PT folks

we are split across CET, ET, and PT, much like our users

gotcha. same at my company, day starts around 12 ET for me so we can pick up CET as they wrap and PT as they start

SpiceDB v1.6.0 was just released! https://github.com/authzed/spicedb/releases/tag/v1.6.0

Have you given any thought to "relation plugins"? As an example you might want to be able to resolve group memberships from e.g. LDAP. I can imagine supporting some sort of plugin API where you could specify that a relation is virtual and provided by a plugin.

@tnarg yes, although it would be more likely a synchronized copy, as otherwise there are consistency and latency concerns

its those concerns that have made it remain speculative at the moment

I imagine this will be a common need for enterprise customers. Even if it was a service on the side that let you programmatically say "Mirror ActiveDirectory group 'foo' into spicedb", that would be huge.

yeah, that would/should be fairly straightforward to do

there are some questions around what happens if it stops synchronizing, etc

Alternatively, if my client could provide multiple subjects to CheckPermissionRequest, I could supply the user as well as a list of "Member of Group X" subjects?