anytime 🙂

we use Expand to build our permissions panels in our management dashboard for Authzed

https://buf.build/authzed/api/docs/main/authzed.api.v1#ExpandPermissionTree for reference

https://buf.build/authzed/api/docs/main/authzed.api.v1#ExpandPermissionTree for reference

message has been deleted

Hi all. Is the playground open source? Or is there something similar that ships with SpiceDB. I'm not sure if

serve

and

serve-devtools

are meant to be run concurrently and if

serve-devtools

exposes a playground-like interface?

message has been deleted

message has been deleted

hi @User, the playground is not currently open source (although we're considering open sourcing portions of it).

serve-devtools

is only needed if you want to talk to the developer API, and the developer API itself is *stateless*: you don't need to run it as part of the same server (or at all)

thanks!

if you have any questions about integrating or using the developer API, feel free to ping. Its not officially supported (in the sense that we reserve the right to make breaking changes to it), but we do intend to keep its changes to a minimum, especially if people start using it outside of the playground

Hey, when will v1 arrive for the JavaScript client?

message has been deleted

@User we can prioritize it if you're blocked on integrating

can you tell us a bit about your environment? we're debating whether to be javascript-first with TS annotations or TS first with a javascript option

Has there been any discussion on exposing a flattened graph of relation/permission changes through the Watch API? For example, let's say that a user has view access to a resource if they are a member of a particular group. If a user is added to the group, two new watch responses would be emitted to clients watching for changes: 1 for the direct group membership change and 1 for the indirect view relationship/permission change as a result of the group membership addition. As another example, if a parent resource has 10 children and view access is revoked from the parent for a particular user, then the watch api would serve 11 responses: 1 for the direct view relationship change on the parent and 10 for the indirect changes to it's children. I recognize that serving a flattened relation change stream could produce a huge set of changes for deeply or widely nested sets with lots of indirections, but it would give clients a simple and streamlined integration to build access-aware search indexes from. This would be in favor of the Lookup API for continuous indexing of any changes in the flattened graph. Doing this would allow external clients creating access aware indexes to not have to "rebuild" the graph of relations.

We have many use cases at Adobe that would best be served by providing a flattened stream of relation changes, because we have a lot of access aware search indexes that we use in UIs and other app specific search engines within the platform.

@User yep, we have an internal design I put together for exactly that stream of changes, and then coupling it to a cache that can be fed to something like ElasticSearch

it wouldn't return all 11 changes in your example, but rather it would (like Lookup) return changes to a specific resource kind

Is

zed permission lookup

supposed to return consistent results?

❯ zed permission lookup myns/group member myns/user:jim --insecure
parent
london
global

❯ zed permission lookup myns/group member myns/user:jim --insecure
global

❯ zed permission lookup myns/group member myns/user:jim --insecure
global
parent

I ran these in quick succession and different results were returned each time

hi folks, is it possible somehow to configure spicedb with two db endpoints, one for read operations and one for write? the use case is where if we deploy a aws postgres db with read replicas to scale the reads. can do it by having different instances of spicedb it self but just wondering if can avoid that. thanks

@User were you issuing writes at the same time?

@User not currently. the problem with read replicas would be consistency: if the reads come from the read replicas, they may have stale information

the recommendation for a fully distributed datastore would be to use the Cockroach DB store

that can be deployed across many nodes

if you deploy SpiceDB instances with different datastores configured within the same cluster, it will break certain expectations, so we don't recommend that

@User I executed the writes in a batch earlier. I was only reading at this time

@Ryan try sending in the zedtoken from the earlier write

its likely SpiceDB is using local caches and that would force it to use the most up to date information