Project: Cognax AI Multiple organisations, each organisations have admin and users Admin give permission to user Files are in Folders, files can have Tags assigned to them. Files can have Domain assigned to them. Similarly there are modules like Dashboards, Automation Workflow, Data Tables etc Can anyone help me with the schema

we're here to help 🙂

if you load the playground at play.authzed.com, under Examples there are some with folders, organizations, etc

that's a good starting point

are the tags in your example supposed to grant permission somehow?

Tags and Domain are actually to combine multiple files, we use it in RAG

Suppose there are multiple files with Domain "Insurance", and then user selects the same domain in RAG module and then chats with it

do you need to filter the tags on the permissions side?

Are there any reference / example implementations for protecting a simple web app with a backend db?

i've seen a few in a handful of languages but they're a bit scattered about. what language are you looking for? is there a particular part of the puzzle that you're interested in?

also fwiw i probably wouldn't reach for SpiceDB in an otherwise monolithic codebase

@yetitwo The project is meant to implement an internal Platform Services architecture to manage / integrate with our infrastructure. So right now we are starting off with a simple 1 service, but want to expand to n services. With a few different people / teams maybe in the future managing their particular service. Copying gcp approach with http / rpc endpoints, iam and hierarchy.

Was hoping for an example in go that protected a nested hierarchy like org-> folder -> folder -> project a simple iam policy creating the relations.

hmmm... yeah, i haven't seen a full project in go like that yet. you've seen the example schemas in the playground though?

any more inputs for this? https://github.com/authzed/spicedb/pull/2504

Howdy. We're running into issues with our DB load and have narrowed down the permissions causing problems. Here's a simplified schema:

definition user {}

definition organisation {
    relation admin: user
    relation teacher: user
    relation deactivated_member: user
    permission active_staff = admin + teacher - deactivated_member
}

// ID is Org:Subject pair
definition capability {
    relation organisation: organisation // only ever one organisation here
    relation capability_official_content: user:* | organisation:*
    permission capability_applies = organisation->active_staff + organisation
    permission official_content = (capability_official_content & capability_applies)
}

definition subject {
    relation capability: capability
    permission official_content = capability->official_content
}

definition activity {
    relation subject: subject
    relation official_content: user:* | organisation:*

    permission view = subject->official_content & official_content
}

Checking

activity:x#view

seems to blow up our database due to needing to evaluate thousands of

capability

per

subject

. An

--explain

shows that it's evaluating a lot of tuples (the output was ~600kb of text) Logic is: Organisation is granted access to various subjects. Orgs may be granted different capabilities for each subject. A user may be in multiple organisations. Users should only be granted access to activities their current org (contextually) has access to. We're trying to avoid caveats so this involves 2 checks, one for the user and one for the org (hence the additional org wildcards):

activity:a_1#view@user:u_1
activity:a_1#view@organisation:o_1

It doesn't seem like this should be a problem for SpiceDB to handle - do we just need a beefier DB? I don't know if it's related to this issue in particular but our cache hit ratio has also tanked recently, it usually sits around 2:1 but is between 1.2-1.5:1 recently 😱

> Checking activity:x#view seems to blow up our database due to needing to evaluate thousands of capability per subject yeah, we call this the "wide relation" problem. it's theoretically something that we'll be able to optimize around in the future as we start figuring out statistics and query planning, but right now when this condition is encountered it just has to evaluate a lot of tuples. we're also looking at an API for checks/LRs where you could provide a relation that the walk has to go through, which would potentially reduce the amount of work that needs to be done: https://github.com/authzed/spicedb/issues/1317 in the meantime, though, yeah, we usually recommend scaling up your db as the first step. in our experience, keeping PG and cockroach CPU usage below 60% is a decent heuristic. another thing that might be worth looking at is using a self relation to express binary logic instead of wildcards:

definition activity {
  relation subject: subject
  relation official_content: activity

  permission has_official_content = subject->official_content
  permission view = official_content->has_official_content
}

with the idea being that you'd write an

official_content

relation from an activity to itself to mark that boolean. this isn't necessarily the optimization that's going to fix things, but using arrows instead of intersections means that SpiceDB doesn't have to evaluate as many tuples before it can decide that it's got a match, and you can propagate that same pattern up the tree

What kind of tooling do Authzed/SpiceDB have? I am considering using it for authorization but want to see if I can use my existing database or what advantage would I have with SpiceDB

that's a fairly broad question; I recommend taking a look at the docs at docs.authzed.com and then we can help answer specific followup questions here

More specifically I wanted to use my own database, and think I might need to write an adapter if possible for SurrealDB

there is a datastore interface that you can implement; no idea on whether SurrealDB supports the necessary primitives though

Can you reference it for me?

Hi team we are facing the issue mentioned in this document, But I see there is no redirect to the fix link. https://authzed.com/docs/spicedb/concepts/datastores#transaction-ids-and-mvcc Can someone point me to an fix We have done pg_restore, to a new spicedb instance but we are facing empty schema error and relationships

run

spicedb datastore repair

We have run that command , But still unable to get latest results from lookup resources API

"latest"?

are you receiving an error, or are you receiving results and they don't look like what you'd expect?

Folks, @bison and @adin and myself will be on livestream talking about building AuthZed Dedicated on AWS, Azure and GCP - and what we learned along the way. Stream starting in few mins

Hi all, at my company we've run into an issue. We use SpiceDB with a postgres datastore, with our app DB as the source of truth for all the relationships in SpiceDB. We have a process running that is `Touch`ing all relationships that should exist in SpiceDB based on the app DB's state, and also extending expiration, since we use expiration on all relationships as suggested to me here as well maybe a few months ago. It runs once every 23 hours. we have about 1.3M relationships in our datastore based on

relation_tuple

, not counting any deleted ones, but at the moment only 680k of those that were written in the last day (so others will expire eventually), so maybe something in that ballpark would be how many relationships this process has to write once a day, and it takes around 20 minutes generally. Of course we also usually have concurrent usage of SpiceDB by our application for mostly

CheckBulkPermissions

requests whenever these syncs happen Now with that context, we are seeing two types of errors in the spicedb pod logs, that I can confirm appear during these syncs, and I can reliably reproduce them by re-running the sync process. What is interesting is, the

WriteRelationships

calls on the sync process side seem to all succeed, which is why we didn't notice this error for some time (we didn't have alerts for the SpiceDB pod's errors so we didn't notice them). From our side it looked like the sync was succeeding, but we were not seeing some relationships that we thought we should be seeing (we were relying on the sync to create them in that case). Will split the rest of the message with the actual errors into a second message.