Hey question. My employer postponed the ship date of our SpiceDB implementation indefinitely, and I'm leaving for bigger and better opportunities (long story). BUT! I'm collecting my postmortem notes for posterity... and I'm curious if a postgres->spicedb sync would be feasible using a WAL tail. Here's the general concept: * Subscribe to the PostgreSQL WAL * On insert/update, if a spiceDB update is needed: * Open a db transaction * Perform the spiceDB update(s) via gRPC * Update the database row(s) with the ZedToken/Zookie received from the spiceDB update * Commit or roll back the transaction

in theory it should work, yes

That's as far as I'd gotten, glad to have it confirmed 😅

Do you suspect any specific trouble in practice?

so long as it doesn't fall behind and can resume from a point, it should work

Is that related to the new enemy problem?

not directly, although that could be another issue if the zedtoken isn't updated

the main benefit of being able to resume is in case the translator falls off

Gotcha, so if there's a crash it needs to know what the last known good txn is and replay from archives

yep

thanks, I'll make a note of that

@Sleipnir I'm interested in this area, I'm struggling to understand what you'd be trying to achieve in doing this?

does this mean that permissions have to be duplicated for all of these types of relationships/hierarchies? it seemed that zanzibar syntax would allow to model these more concisely/generally

what do you mean by

duplicated

?

if I have several layers of this, each will define the same permission(s)

only if those layers are different definitions

if you have that many definitions, then you'd like just use one

and distinguish by the object ID

in the above, a user can supervise another user, which can in turn supervise another

giving access to "user" for many different types of resources

then you can reuse the same schema for any resources

documents (read, edit, comment, etc), foo(read, write, view, eat), bar(read, approve, blah,)

different resource types have different (large) sets of permissions

then the "user" has to have all of them listed

definition user { relation supervisor : user permission approve = supervisor + supervisor->approve permission buy = supervisor + supervisor->buy permission drive = supervisor + supervisor->drive } definition bar{ relation owner : user permission drive = owner permission buy = owner permission approve = owner->approve } definition foo{ relation owner : user permission edit = owner permission delete = owner permission approve = owner->approve }

if they have different permissions, then you need to either set them up for each

or use dynamic permissions

where do I find more about "dynamic permissions" ?

I would not recommend using them, mind you