why can't you just do that like so?

definition thing {
  relation registered_user: user:*

  permission view = registered_user
}

@williamdclt ^

I'd then need to write a relationship

thing:XXX#registered_user@user:*

for each

thing

. That seem unnecessary, I'd just like to statically defined that the

view

permission is given for any

user

(or possibly any subject at all)

yeah, if thing rolls up to some other object, you could put the "policy" on the related object, like if you were using a

platform

object

ideally we don't make it too easy to accidentally completely open a permission

Having a

platform

object would work indeed, but it's still an additional concept and relations for a use-case that doesn't really need it 😄 it's a lot of friction I find. Not the biggest of deals, but it means I have to make sure that all my `thing`s have a relation to

platform

, it's one more thing to implement and maintain

@williamdclt do you think you'd want it statically for a specific class of subject, or just all subjects?

since you said "possibly any subject at all"

Either would work for me. I would need it to work for at least 2 subject classes I think

we recently added

permission someperm = nil

which always returns no permission

mostly for ease of development as a temp placeholder

but I wonder if an inverse might be useful, with the caveat that it might be too unsafe to actually allow

permission someperm = always

or somesuch

I'd say that if the user wants to give universal permissions, there's no reason to prevent them? As long as it can't be done by mistake. It's really not a blocker for me, to be clear!

yeah, just a pie-in-the-sky discussion 🙂

Hi all, is it possible to utilize authzed without switching over to spice DB? Just using it at the api level?

Do you mean without running it yourself?

I'm currently using spanner/bigquery for housing my data, thinking of switching over to postgres/bigquery. I'm not sure I want to replace my database with a new one which is what I was assuming was the expectation for using spiceDB. Is spiceDB instead used in tandem with existing databases?

Spicedb sits on top of another durable datastore such as spanner or Postgres, but the expectation is that you still need to put all of your relations in spicedb

There’s no way to connect the spicedb permissions engine to existing data in another datastore

ahhh interesting that makes sense

Are there any stats anywhere around SpiceDB usage just to try to gauge how established/battle tested it is?

We publish some stats at status.authzed.com

As far as customer adoption for enterprise/open source, taking a look at who is interacting with this channel is probably the best I can offer

You can set up a call with one of us through the link on the landing page and we would be able to go into more detail

Ok, thanks!

Hello! I started experimenting with SpiceDB a couple weeks ago to replace our current authorization system. Currently I'm creating the relations for about half of our production data and I came up with some questions in the meantime. 1. What are the resource requirements for about 600 million relations? For now I placed spicedb on an instance with 4 cores and 16GB of ram (aws t3a.xlarge) and it responds to the check requests fast enough (with a 95th percentile of 20ms and median of 7ms), but the lookup resources requests (which would be very important for our use case) only complete in 1-3 second in the bast case, and time out in the worst. The datastore is postgresql on an instance with 2 cores, 15GB ram and high performance NVMe storage (aws i3.large). The schema is deeply nested in our case and I know that this limits performance, but I'm looking for a way to improve it somehow. 2. I found out that creating a dispatch cluster should help on my situation, the only problem is that we don't use k8s. Is there any other way to do service discovery? Currently we are using AWS ECS for our services and the service discovery that comes with it (SRV records).

I'm trying to make sense of the

ExpandPermissionTree

endpoint. I'd expect it to return all subjects who have the given permission on the given resource, but that doesn't seem to be the case: it returns a tree of set operations where the leaves are the subjects. That means that if I want to know which subject actually has the permission, I'd need to apply the operations myself? For example:

$ zed permission expand caregivers_csv_upload agency:63ed361f-a0b7-41fc-9c4b-143e0fe792ad
agency:63ed361f-a0b7-41fc-9c4b-143e0fe792ad->caregivers_csv_upload
 └── exclusion
      ├── agency:63ed361f-a0b7-41fc-9c4b-143e0fe792ad->account_manager
      │    ├── user:f71c18fc-fd2f-4a96-ab65-020cb00670c5
      │    ├── user:f9ed57f2-c881-4c3c-9fd5-f67043de3118
      │    ├── user:fdf84719-e48f-4637-b5c4-2efa32948602
      └── agency:63ed361f-a0b7-41fc-9c4b-143e0fe792ad->flag_rostering_integration
           └── user:*

There's an exclusion operation with

user:*

so I'd expect SpiceDB to tell me that 0 subjects have this permission. But nothing in the ExpandPermissionTree response seems to contain this information. Am I missing something?

There's a github issue for this: https://github.com/authzed/spicedb/issues/261 The ExpandPermissionTree api returns only the tree. I'm currently using some client-side code to compute the subject set from this tree. It's not performant, but it's still a lot faster than running CheckPermission requests for every subject.

Thank you @crafterix! Is there a fundamental problem with computing the subject set from this tree within SpiceDB, to return it to the client? 🤔