?

CRDB went BSL

Im wondering if spicedb is going to use features available in the BSL versions, its the reason I was looking at PG

unless CRDB moves more features to BSL, I don't see that being the case

One of the challenges in authz systems is understanding what attributes are required in order to allow someone to be granted access to- especially when they are denied access. I am new to spicedb so can you please help me understand how this problem is addressed?

in what context?

one thing that may help is the

--explain

flag on

zed

calls - it can show you the path by which a user was (or wasn't) granted access. i don't think it will compare it to the entire schema as it's currently implemented - it will only tell you where the path starts and ends. otherwise my usual approach is to manually trace based on reading the schema and issuing readrels to check hops. this could be a nice enhancement for zed, though.

Thank you. I will spend some time looking into --explain - by guess is that its useful for describing why an authz decision was made - and not so much for what would have been required in the event of failures. Its that manual tracing that is cumbersome - especially at scale...

in my experience (e.g. using SpiceDB at my old company) i'm not typically having to do much of it. do you have a particularly complex schema?

like what's the task you're envisioning?

I haven’t designed a schema yet - but here’s a simple example. Let’s say we are locking down access to specific tables using groups - different group for each table - potentially different variation of the group for read vs write. When you have a large no of tables and large number of users it would be ideal for error message returned to say what group is required for access so the user can self serve. That’s a very simple example obviously.

unless everything is dynamic, i'd expect that you'd know something aboout your schema that would be exposed in your UI. if everything is dynamic, i'd probably strive to keep the schema relatively flat, and provide UI elements like AWS IAM or something like that where it tells the user what permission they're missing to do a particular thing, such that it'd be relatively easy for a user to translate missing permission -> missing role. this was something that we talked about at my last company, but things never got complex enough to warrant it.

I’ll take a look in the next few days. Thanks for responding though!

What are permission spaces? Is that the

<space>/user:<id>

on all resources? Can I use that for partitioning relations in the same database / spicedb instances?

just wanted to say how helpful it is that the tooling allows me to build, test, and experiment with my schema without having to touch code while I figure things out

that's the goal 🙂

Hey team, we noticed the latest

authzed-py

release

1.22.0

might have been broken. I've raised an issue [here](https://github.com/authzed/authzed-py/issues/280). We are currently pinning to an earlier version as a workaround but would appreciate a fix at some point. Thank you!

How to sign up for the cloud service? I'm on authzed.com/cloud/signup but there's nothing on this page besides lita cho from moment telling me how great authzed is

Terrible idea to put the last message in this channel up on the website

At least use the display name and not my discord user name

Rewrote my Authzed schema in CUE (essentially an alternative to

zed preview schema compile

). This one file replaces all the other zed files in that directory (

_at.zed

is the previous schema compiled from all the resource.zed files) - https://github.com/blebbit/atproto/blob/main/packages/pds/src/authz/spicedb/schema/atproto.cue - https://github.com/blebbit/atproto/blob/main/packages/pds/src/authz/spicedb/schema/atcue.zed

How should I provide the database pasword if it contains special characters?

sh
spicedb migrate head --datastore-engine=postgres --datastore-conn-uri='postgres://user:-.$[_@localhost:5432/spicedb?sslmode=disable'

7:25AM ERR terminated with errors error="unable to create migration driver for postgres: cannot parse `postgres://user:xxxxxx@localhost:5432/spicedb?sslmode=disable`: failed to parse as URL (net/url: invalid userinfo)"

consider the following schema

typescript
definition document_database {
    relation project_database: project_database
    relation organisation_database: organisation_database

    permission view = ...
}

definition document {
    relation document_database: document_database;
    relation viewer: user;

    permission view = doucment_database->view + viewer & document_database->project // i tried this but it does not work also it does not make sense. What would it even mean to intersect `viewer` and `document_database->project` it probably becomes empty set?
}

is there some way to express that a user has view permission if they have one of 1. they have

document_database->view

2.

viewer

and not document_database->organisation_database (alternatively

viewer

and the document_database->project relation exists) i.e they have view access only if 1. they can view the database that the document belongs to (trivial just document_database->view) 2. or they are related via `viewers`and the document_database is a project_database. (organisation database documents will not be shared with users who are only `viewer`s)

How should I start

spicedb

in production? Say I followed [the instructions](https://authzed.com/docs/spicedb/getting-started/install/debian#installing-spicedb-using-apt-get) to install spicedb on my Debian box. How should I start

spicedb

so that it act as a daemon/service and it can auto restart upon crash? in dev, I simply do

sh
spicedb serve --grpc-preshared-key 12345678 \
    --datastore-engine=postgres \
    --datastore-conn-uri="postgres://postgres:postgres@localhost:5432/spicedb?sslmode=disable"

we'd recommend using the operator if you're planning to run it in production: https://authzed.com/docs/spicedb/getting-started/install/kubernetes#installing-spicedb-using-the-spicedb-operator. If you don't want to run it yourself, you can also use our Cloud service: https://app.authzed.cloud

greetings folks. I'm doing a small load testing scenario with Thumper and adjusting some knobs along the way. One thing that I can't fully understand is

--dispatch-cache-num-counters

flag (which I'm setting with

SPICEDB_DISPATCH_CACHE_NUM_COUNTERS

env var). In my testing it doesn't have any effect at all - whether it's 1 or 1000000. I've prepopulated the database with 10000 users and 10000 grants (1 to 1 relation) and running a following scenario on them:

yaml
{{- range $j := enumerate 2000 }}
---
name: "min latency check"
weight: 80
steps:
- op: CheckPermission
  resource: core/geohash_grant:{{ $j }}
  permission: view
  subject: core/user:{{ $j }}
  consistency: MinimizeLatency
  expectNoPermission: false
---
name: "fully consistent check"
weight: 20
steps:
  - op: CheckPermission
    resource: core/geohash_grant:{{ $j }}
    permission: view
    subject: core/user:{{ $j }}
    consistency: FullyConsistent
    expectNoPermission: false
{{- end }}

On a screenshot there are couple of annotations: - a first one is where I set

SPICEDB_DISPATCH_CACHE_NUM_COUNTERS

to 1 - a second one is where i set

SPICEDB_DISPATCH_CACHE_NUM_COUNTERS

to 1000000 - a third one with improvement is change to datastore quantization interval from 5s to 15s - a fourth one where I've removed fully consistent check from the Thumper script - a fifth one - quantization interval is set to the default value of 5s again LFU cache metrics (second screenshot) show a much higher hitrate (although

SPICEDB_DISPATCH_CACHE_NUM_COUNTERS

doesn't seem to have an effect on it either). Can someone explain what

SPICEDB_DISPATCH_CACHE_NUM_COUNTERS

is suppose to be doing please? https://cdn.discordapp.com/attachments/844600078948630559/1417407970375110686/image.png?ex=68ca5f8a&is=68c90e0a&hm=8e317f384c0b67d17f398af6a1d8c87b1212b731e882fa02cfa2dc7ba5ba9b31& https://cdn.discordapp.com/attachments/844600078948630559/1417407970945273856/image.png?ex=68ca5f8a&is=68c90e0a&hm=00c8718de1b94354e10492461e08413b1bd174a7bae0f94a278e407a5d73de58&

Thinking through the options from the Authzed YouTube video on this, does the following look workable for a reconciliation based system?

ts
      //
      // DUAL WRITE PROBLEM
      //
      await dualWriteTransaction({
        ctx,
        repo: repoDid,

        // (DWP/1) writes to the repo database
        actorOps: async (actorTxn: ActorStoreTransactor) => {

          // space (self/profile) record
          actorTxn.space.insertRecord({
            uri: spaceRecord.uri,
            space: spaceRecord.uri.space,
            collection: spaceRecord.uri.collection,
            rkey: spaceRecord.uri.rkey,
            cid: spaceRecord.cid,
            record: spaceRecord.record,
            did: reqDid,
          })

          // space (owner/parent) record
          actorTxn.space.insertRecord({
            uri: spaceRelation.uri,
            space: spaceRelation.uri.space,
            collection: spaceRelation.uri.collection,
            rkey: spaceRelation.uri.rkey,
            cid: spaceRelation.cid,
            record: spaceRelation.record,
            did: reqDid,
          })

        },

        // (DWP/2) writes to the authz service
        authzOps: async (spicedbClient) => {
          await createRelationship(spicedbClient, resource, relation, subject)
        },
      })

      // TODO, (DWP/3) background reconciliation process

Hi! What are the implications on e.g. performance when defining a large set of permissions and/or relations? i'm in a situation where i think i might need to define a lot of permissions (essentially duplicate my existing set of permissions) on a lot of object type definitions. My hunch is that its not very costly to define permissions since they are calculated upon reqeust whereas additional relations would lead to increased storage usage?

Hello SpiceDB community, I have an issue with User Defined Roles. I followed this blog post: https://authzed.com/blog/user-defined-roles I have two default roles that all companies will have. The issue I'm facing right now is that when two companies have the same feature, let's call that Admin. Then one of the companies pay for a feature so we set enabled_for to be their company. They have a management panel, where they can set which roles should have access to the specific feature, so they would set allow_access to be Admin. Then the other company decides to also buy the feature, then we set enabled_for to be their company and now the feature is allowed by default because the relation is already set. Basically they can both change the allow_access for each other. I can't seem to figure out how I can solve this problem. Any help is appreciated. Thanks in advance 🙂

Hey all, Not sure if it's our specific setup, but I wanted to flag that spicedb v1.45.4 has been breaking our builds. Pinning spicedb to v1.45.3 fixes the issue, but I couldn't see anything suspicious in the release notes. I am also running

authzed/spicedb:v1.45.4

in my local docker-compose setup without any issues. For reference I attached the startup log output. When my application is trying to establish a grpc connection with spicedb all I see is timeouts. https://cdn.discordapp.com/attachments/844600078948630559/1417869914521206794/message.txt?ex=68ccb682&is=68cb6502&hm=365eecfb402485e6aa5a373a79a1d260b7b107885780f6034fefaad6bcc954fc&