If i'm were to have dozens/hundreds of clients, what is the recommendation? Create a proxy in front of spicedb that does some other authentication method, or initialize spicedb with dozens/hundreds of preshared keys and dole them out to different clients?

You probably want to avoid adding a proxy in front of SpiceDB -- even a TLS handshake from establishing a new connection is often enough to blow your performance SLAs. It's quite tricky to layer on your own logic and still maintain the 99th percentile performance requirements. I'd try to see if you can get by with using provisioning many preshared keys if possible. Maybe it makes sense to reuse them depending on the domain.

And if you’re open to talking about a commercial arrangement, we’re working on fine grained authorization for our fine grained authorization service.

That was one of my next questions -- how to segment the ability to write various tuples between API clients

say you wanted to delete a relationship and recreate the relationship with an id that could be the same as the id that you are deleting in the same WriteRelationship call how do you prevent this error:

rpc error: code = InvalidArgument desc = found duplicate update operation for relationship

? I was told you could use Precondition but I'm not sure how. How could I let spicedb know, if the relationship exists, to either go ahead with the delete and recreate the relationship or to disregard both the delete and touch and leave the relationship as is?

I'm not clear on what the Precondition operators mean for the purposes of preventing that error

why would you want to recreate it?

I'm deleting relationsjips and updating them with new ones which may already exist in one write call. I dont want to first check if the relationships in the new update already exist. It would be preferable if they rrelationship was not rercreated but the delete and touch operations cancel each other out

just put the updated relationships as

TOUCH

if they exist, it no-ops

no need to delete them

if your code is generating both DELETE and TOUCH for the same relationship within the same transaction, you'll need to filter that out yourself before calling

basically: - if you intend to delete,

DELETE

- otherwise, if you intend to create or leave as-is, use

TOUCH

if your code is generating both DELETE and TOUCH for the same transaction, you'll need to filter that out yourself before calling

ah, so a precondition or anything else wouldn't help here

thanks

yeah

preconditions are useful if you want to set conditions on the entire transaction occurring

for example, you might want to only CREATE relationship A if relationship B doesn't already exist

or somesuch

within the updates of a transaction, you can't both TOUCH and DELETE a relationship because what would be the expected outcome of that transaction applying? (since there is no defined "order" to the updates)

got it

the next version of SpiceDB will have a more descriptive error for that case

that would be great

since I am only a few days on it I am probably missing something. I saw the announcement of 1.14 yesterday and I run:

kubectl apply --server-side -k github.com/authzed/spicedb-operator/config

to update, but nothing happens According to

zed version

I am still on 1.10. Any tips?

Hi all 👋 I just found out about SpiceDB/Authzed and I'm flabbergasted by the features it seems to offer. We're in the middle of building our own multi-region RBAC and SpiceDB almost sounds too good to be true.

can you provide more context? Did you have the operator already applied and you are updating it, or you just applied to your cluster? Do you have a

SpiceDBCluster

CR applied? What does it look like?

it's great isn't it? 😄

Chances are it's due to the fact the new versions haven't been added to https://github.com/authzed/spicedb-operator/blob/main/default-operator-config.yaml. I'm not entirely sure if we can just add them because we have some multi-phase migrations for our recent Postgres work, and we had to adapt the operator to understand multiphase migrations. Not sure where it is at the moment tbh. @jzelinskie may be able to help

I'm trying to get started using the operator and noticed that it still installs v1.11 and not v1.14.1. So right after installing

zed

(using

go install ...@latest

) it complains about the version not being up to date. Also, the

check

seems to fail due to an error about port 50053 which isn't responding. I've created this issue (https://github.com/authzed/spicedb-operator/issues/109) and we already learned that probably dispatch isn't running. But being a newby I have no idea why...

I have the operator applied and I have a spicedb cluster. The docs mention that I just need to re-apply the operator manifests. But you have a good point wrt to the config. I'll watch the file until I see a 1.11.4 in there 🙂