Hi folks, is the watch api a work in progress? getting an Unimplemented error, latest version of spicedb. Not sure its expected or I'm missing something

Are you trying to connect to the service or a load balancer endpoint?

What datastore engine are you using?

i am trying to hit the service

cockroach with postgres backend

Service is likely self signed cert; probably best to try to hit a load balancer endpoint

Hi, I am looking at Architecture, wanted to understand more about internal/ graph section of the diagram, is it at each SpiceDB Node? So each node creates its own graph? As per my analysis in playground, graph changes based on relationship as well but it is impossible to store relation level details in node memory. Please help me to understand that.

@Joey hmm not sure where to get that endpoint, i have applied the manifest in our openshift cluster on aws, looking at the deployment it probably creates a load balencer, might have to check the aws account

The graph exists as a list of edges (relationships) in the shared datastore. Interpretation of that graph to make permissions decisions is done by each individual SpiceDB node, and any node can resolve any graph traversal problem or sub-problem.

also documented here: https://docs.authzed.com/reference/caveats#parameter-types

if you're using CRDB as the datastore, you need to enable changefeeds on the CRDB service for Watch API to be enabled: https://www.cockroachlabs.com/docs/stable/create-and-configure-changefeeds.html#enable-rangefeeds

ah no, using postgres. Only supported in CRDB ?

for Postgres, you need to make sure commit timestamps are turned on;

SHOW track_commit_timestamp

will indicate whether they are enabled

we'll add docs for it

Cool! Thanks will check

Thanks Jake, this clarifies, which table stores graph edges , can we query that table ?

Re: migrating to 1.14 with Postgres I'm finding that this query from the migration is pretty slow (~500ms):

sql
SELECT namespace, object_id, relation, userset_namespace, userset_object_id, userset_relation, created_transaction, deleted_transaction
FROM relation_tuple
WHERE created_xid IS NULL
LIMIT 1000 FOR UPDATE;

Query plan (EXPLAIN ANALYZE):

sql
Limit  (cost=0.00..68.34 rows=1000 width=150) (actual time=468.112..472.134 rows=1000 loops=1)
  ->  LockRows  (cost=0.00..479050.71 rows=7009496 width=150) (actual time=468.111..472.023 rows=1000 loops=1)
        ->  Seq Scan on relation_tuple  (cost=0.00..408955.75 rows=7009496 width=150) (actual time=468.097..468.493 rows=1000 loops=1)
              Filter: (created_xid IS NULL)
              Rows Removed by Filter: 2947393
Planning Time: 0.105 ms
Execution Time: 472.248 ms

The index on

created_xid IS NULL

isn't used 🤔 Even after an

ANALYZE

. No idea why.

Is there any list of examples to refer the caveats ?

If I am using namespaces, How do I use below caveats text

caveat has_valid_ip(user_ip ipaddress, allowed_range string) { user_ip.in_cidr(allowed_range) }

do we need to prefix this with namespace as well ?

Yes

But be aware caveats are not currently supported on authzed.com

thanks, I am running it in docker, v 1.14.1 , I have turned the ALTER SYSTEM SET track_commit_timestamp = on; Running, docker exec -it bcb84b1ed9d2 spicedb serve --experiment-enable-caveats=true … it gives me following error

5:25PM DBG configured combined dispatcher upstream= 5:25PM WRN watch api disabled; underlying datastore does not support it reason= 5:25PM WRN experimental caveats support enabled 5:25PM ERR terminated with errors error="failed to create gRPC server: failed to listen on addr for gRPC server: listen tcp :50051: bind: address already in use"

Do i need to run this command with fresh setup ?

you need to shut down the other SpiceDB running on the machine first

you need to shut down the other SpiceDB

Is there a way to get all of the resources that a subject has a permission for? I.e. for a schema like this:

definition account {
    relation account_admin: user

    permission read = account_admin
}

Can I get the all of the accounts that a user has read permission for. I've tried this:

const response = await client.lookupResources(
  LookupResourcesRequest.create({
    resourceObjectType: 'account',
    permission: 'read',
    subject: SubjectReference.create({
      object: user,
    }),
  }),
);

But the permissionship comes back as 0. I believe that means that I can't reliably say that the user has read permission for the the accounts that are returned.