maybe a coincidence. seems to have settled for the moment

@Joey (sorry for the direct ping) Would it make much a difference if we changed the

resource

to be

definition resource {
  relation reader: user#member | access_token | role#member | service_account#member
  relation writer: user#member | access_token | role#member | service_account#member
  relation manager: user#member | access_token | role#member | service_account#member

  --- CHANGE ---
  permission manage = manager
  permission write = writer + manager
  permission read = reader + writer + manager
}

I am currently building an ecommerce store, this is my first time designing authorization model its quite challenging, hard to think of all possible scenarios from the start at the start, I thought its was trivial just plug two or three roles. then noticed something that this way is static, and may not scale well !! also an idea came to my mind is to hand the users of the system the ability to create their roles, but roles are just names their must be attached to something that is fine grained and atomic -> permissions now, I am thinking, what/who kind of users are able to create roles ? and who are able of assign those roles? so there must be special permissions like : role.assign, role.create. but!! new issue sounded from the horizon . when user is able to assign roles , what limit,boundary they can assign ? can worker assign admin role to another user ? if yes then this is considered as hack ! same thing for users who can able to create roles ! can user create a role with permissions he dont have or own? so decided to : attach a boundary set of permissions for those two spicial assignments: roles are immutable except the name field. Role { id:... name:... permissions:[], create_role_scope:[], assign_role_scope: [], } for which create_role_scope,assign_role_scope both are subset or equal to permissions.

do you want fully user-defined roles or a pre-defined set?

admin,worker, customer as default system non-deletable roles used as fallback ! and I want to hand the users of a deployed instance of the app to customize and create their roles and permissions.

currently I am implementing the above model

where a user can not create role or assign roles beyond the permission scopes of his role.

dumb citizen cant hire a president !!

we generally recommend starting at a simpler schema and then layering on changes, refactoring as you go along

but we do have a user defines roles example

I will check that out .

Hi, I have two questions: 1. In our PostgreSQL database, all of the

relation_tuple

rows were logically deleted (their

deleted_xid

was set). We're not sure what caused it, but we found that the following query was executed six times: UPDATE relation_tuple SET deleted_xid = $1 WHERE deleted_xid = $2 AND namespace = $3; Are you familiar with this query? Could you explain exactly what it is supposed to do and under what circumstances SpiceDB executes it? 2. I noticed entries in the

alembic_version

table such as

create-relationship-counters-table

and

add-index-for-transaction-gc

. What exactly do these values represent? Are they migration identifiers, and what changes do they indicate were applied to the database?

Hey, I have a question towards OAuth integration with SpiceDB. We have multiple services which need to interact with SpiceDB to update, read relationships etc. How can we authorize these services? From the docs I found "Restricted API Access" https://authzed.com/docs/authzed/concepts/restricted-api-access But here it seems that it only supports its own internal user system. Are there any examples or references out there how this could integrate with another OAuth IDP?

Hello ! I'm using SpiceDB for our members and owners "store" in our app. meaning, the full list of members and owner is only present in SpiceDB. when listing members or owners, we use LookupSubject. one of our spaces has a LOT of members (more than 300K) with the obvious error that this thows (message is more than 4Mo, and is expectedly slow) I tried to use the cursor approach (we basically want to list 1000 users, and if there is more, just indicate that and in the user listing, only enumerate that 1000 at a time, and disable sorting and other functionalities of the same kind and enable searching by filtering the users in db via names or email and then batch check in spiceDB to show or not the user in the list. BUT, when trying the cursor approach, I get a

UNIMPLEMENTED : concrete limit is not yet supported

so.... obviously, that doesn't work... I checked the issues on github, and did not find a ticket for that. Am I the first one to have this issue ? to move forward, I set up the readRelationship (the not optimised, not cached, very flexible lookup) but I'd like to avoid that. So is there an alternative ? and in the meantime, is there a way to check the amount of entities with a relation on an item to use lookup when small enough, and falling back to the readRelationships ?

the only solutions today are to increase the message size or use read rels; LS cursoring is not currently supported

is there some work planned for it ? maybe since it's a open source projet, I could try to contribute ?

I started a PR to do it long ago - I abandoned it because it was not really viable

yeah, I think I saw that PR, the approach wasn't viable from what I read. but could another approach work ? has something been though but not started ? maybe a fresh set of eyes could see a way ?

or was it thorougly investigated and is simply not feasable ?

perhaps; I haven't given it much thought in the last few months

the tl;dr: is that wildcards make things annoying and difficult. what's the semantic when a

user:*

would be a top-level subject? what's the semantic when you have

user:*

together with negation (e.g. it's public minus a banlist)? the likely answer in the long run (and this is how the new query planner will handle it) is that you only return concrete subjects, i.e. the concrete IDs that you can definitely say are a part of the result set, ignoring wildcards. that's different enough from the behavior of the current iteration of the endpoint that we haven't gone and made the change yet.

so matching the already present concreet limit ?

(I mean the parameter)

yes, but with an additional issue: wildcards impact the intermediate tree

so we still need to carry them somewhere

and that causes problems

Hi everyone! How's it going? I have a question about read consistency: If I write a relation to spicedb and try to read it immediately after, is there a chance I might get nothing? I'm using the default consistency option (which I guess is the minimize_latency) I have this scenario in which I write relatioships and, right after, another service tries to check a permission. However, it sometimes gets a falsy response from the check (even though all writes happened successfully)

Yeah, I don't want to disturb the upper thread, so I'll start a new one, but the question is quite related. How should we work with

zedtoken

in a microservice architecture when permissions are granted/revoked by admins? For granting permissions, there is no big problem. You can grant the permission in one service and eventually send the

zedtoken

to another service or store it in a DB. It is acceptable if the user gets access a couple of seconds later. But what happens when we remove/revoke a permission? Revoking a permission should ideally take effect immediately. Imagine an admin revokes a user's permission in one service/pod. We then need to propagate the corresponding

zedtoken

to the service handling the user's queries as quickly as possible. If everything is handled within one microservice, we have the problem of storing the

zedtoken

in two databases (SpiceDB and our DB). Potentially, we could lose the latest

zedtoken

if our DB transactions fail. If the permission management and user queries are handled by different microservices, we have the same persistence problem, plus eventual consistency. We need to somehow transfer the

zedtoken

to another microservice, which could take some time depending on the implementation (Kafka, etc.). So, in this case, understanding whether a relation was deleted by an admin is not immediately possible unless we use

fully_consistent

for such queries. Am I missing something here? Is there a recommended pattern for handling

zedtoken

propagation in this kind of architecture, especially when permission revocation needs to take effect immediately? Thanks in advance.

Hi folks 👋 I'm evaluating SpiceDB for my company and had a question around backups. We'd be using AWS RDS Postgres as the datastore. Based on what I'm reading (e.g. https://authzed.com/docs/spicedb/ops/data/migrations), it seems like

pg_dump/restore

is not recommended and instead we should be using

zed backup

for backups. For the same reasons, should RDS automated backups be avoided, or are they fine as those are physical snapshots of storage rather than logical backups produced by

pg_dump

?

Hi, We've been using SpiceDB for almost two years now, and I would say we have a fairly large schema. We've run into an issue twice where the namespace cache hit ratio suddenly starts dropping, and then two out of our four SpiceDB pods continuously increase their heap memory usage until they eventually stop responding to authorization requests. After the first occurrence, we increased the namespace cache size from 256 MiB to 512 MiB, but the issue happened again. What's interesting is that we haven't been able to identify any clear trigger. One time it started on a Sunday, and the other time it started during a regular weekday morning. Our relevant configuration is: SPICEDB_DATASTORE_REVISION_QUANTIZATION_MAX_STALENESS_PERCENT: "1" SPICEDB_DATASTORE_REVISION_QUANTIZATION_INTERVAL: "5s" SPICEDB_ENABLE_EXPERIMENTAL_WATCHABLE_SCHEMA_CACHE: "true" SPICEDB_DATASTORE_SCHEMA_WATCH_HEARTBEAT: "60s" SPICEDB_NS_CACHE_MAX_COST: "512MiB" SPICEDB_DISPATCH_CACHE_MAX_COST: "256MiB" SPICEDB_DISPATCH_CLUSTER_CACHE_MAX_COST: "512MiB" We are using PostgreSQL as the datastore. Another important detail: our schema is essentially static. We only deploy schema changes together with a new application version and after restarts. The schema itself is roughly 4,000 lines long. I've attached a screenshot showing the namespace cache hit ratio dropping. Under normal conditions it stays close to 100%. After restarting the affected pods, it returned to normal. It also looks like cache entries may have started getting evicted overnight, although unfortunately the screenshot doesn't include the very beginning of the issue. Has anyone seen similar behavior or has ideas about what could cause the namespace cache hit ratio to suddenly drop and memory usage to keep growing on only a subset of pods? https://cdn.discordapp.com/attachments/844600078948630559/1536684965142732900/image.png?ex=6a7c4ce5&is=6a7afb65&hm=3d5c660ca04c593003f547389955c83ae7ab0e72e53ec2c279d38f04c4029588&