Ideally we would support everything just through the standard ones

there is also the test server mode: https://docs.authzed.com/guides/validation-and-testing#testing-code-against-spicedb, which is preferred for running tests against

how is

SPICEDB_OTEL_ENDPOINT

treated differently than

OTEL_EXPORTER_OLTP_ENDPOINT

? are they merged? would one override the other?

specifying both did it for some reason 🤔

@jzelinskie ^

I think as long as you configure the provider with the spicedb flag, everything else can be provided by the OTEL env vars

It might be a better UX for us to just drop the flags entirely and document support for OTEL only

I don't think there's a GitHub issue for that, if you'd like to create one

noob question here. is there a tool to automate updating/creating schemas? example - create a schema from a protobuf definition

what would the protobuf definitions look like, exactly?

we do have internal protos used to represent definitions and tooling for converting to/from schema for them

but that's mostly for an efficient store of internal representation

that's the question. I'm trying to figure a way to keep the schema updated without manually touching it.

Fun idea maybe for https://play.authzed.com: Build a WASM binary from the

spicedb

Go src code, then run it in a Web Worker and send/receive (unary) gRPC reqs from it. You could have the playground work offline 🤓

We have a PR open on the playground repo that does just that! it's making its way through review

and I plan to write a blog post about it too

so you'd want to specify it in data or in your code or...?

data as in a yaml/json file? I'm ok with either...

why not just specify it as a schema then? are you constructing the schema from something else?

why not just specify it as a schema then

Looking forward to it! I recently did something similar (Go WASM binary, Monaco, Svelte) and it worked out pretty nicely. 10 MB binary to download was a bit of con, but for my use case not an issue). Would be pretty cool to run a full fledged LSP server via WASM as well, and interact with it through Monaco. Didn't get around to that for my project.

yeah, its something we're looking into as well. the WASM support was step #1

if you get the foundations of an

just created it

thanks @yetitwo !

Hi folks, I have been playing with spicedb for sometime and really like the product and the team behind it. I have a few questions at this point. Regarding multi-tenancy, I see two options before us: - Maintain the same schema definition for all our tenants. This is possible because the system being modeled is really the same for all our tenants. We can achieve multi-tenancy by adding a prefix per tenant to each object instance. - Maintain a separate schema definition per tenant by prefixing the object definitions and the instances with a per tenant prefix. This might give us more control during schema changes. Would like to hear your thoughts on the two approaches. As per my understanding both these options are available to us in the current release of spicedb. However, I did come across a request to add multi-tenancy support to spicedb. Was wondering what will this feature bring over and above what can be achieved today.

@nalin if you anticipate the schema being the same for all your tenants, then the recommendation is to use a single schema without any prefixes, and have them be "isolated" via the relationships you write

if, on the other hand, you anticipate the schemas diverging over time, then yes, you can use a prefix for each's objects

a third option, if you want true isolation, would be to run a SpiceDB cluster per tenant

Authzed Dedicated makes the third option super easy