yeah, our APIs call that parameter

OptionalSubjectRelation

but in reality it could also be a permission, we were designing the API to be most helpful in the 90% case

TIL you can use permissions in relations! 🤯

I swear I tried that out and the editor went red

the one place you can't use them is on the left hand side of an

->

Is anyone aware of any php client that is maintained for authzed? I can't find any in the official repository listing

Is there a VS code plugin for syntax highlighting on

.zed

files?

@User no there is no php client, but we would be happy to host, review, and publish one if you want to take it on the development

a new client is usually just gRPC code generation + a constructor to handle wiring up TLS and auth tokens

for a brand new client you would also eschew any of the v0 and v1alpha1 api work

and no, there is no VS code plugin for syntax highlighting on .zed files, but it sounds like a fun project we might take on over the holidays

Hello. I am running spicedb within docker-compose using image: quay.io/authzed/spicedb:v1.1.0 and exposing grpc port -- "50051:50051". Everything works fine with async python client connecting to localhost:50051. But I'm getting errors when the same code is executed inside the container (trying to connect to spicedb service as spicedb:50051). The error is "".

inside the container you would probably want to use

localhost

for the hostname?

I have two containers - one is where speicedb instance is running, another with my app where the client communicates with spicedb. In order to connect from one container to another, I use the service name as a hostname (it is "spicedb" in my case). With "localhost "I am getting <AioRpcError of RPC that terminated with:\n\tstatus = StatusCode.UNAVAILABLE\n\tdetails = \"DNS resolution failed for service: localhsot:50051

with proper hostname the client gets connect

having GRPC_TRACE and GPRC_VERBOSITY at debug level the logs contain

handshake_manager 0x7f5d14000d00: error="OK" shutdown=0 index=1, args={endpoint=0x564abeecece0, args=0x7f5d14002360 {size=7: grpc.primary_user_agent=grpc-python-asyncio/1.42.0, grpc.client_channel_factory=0x564abe80b370, grpc.internal.channel_credentials=0x564abeea7340, grpc.server_uri=dns:///spicedb:50051, grpc.internal.subchannel_pool=0x564abedd1840, grpc.default_authority=spicedb:50051, grpc.internal.security_connector=0x564abeeb4b40}, read_buffer=0x7f5d140025d0 (length=0), exit_early=0}

and then

security_handshaker.cc:181] Security handshake failed: {"created":"@1637763101.409845000","description":"Endpoint is neither UDS or TCP loopback address.","file":"src/core/lib/security/security_connector/local/local_security_connector.cc","file_line":111}

I run "server" with --grpc-no-tls

oh ok I think I know what's happening

the python client only allows credentials to be sent over insecure connections when the hostname is

localhost

do you have any kind of TLS infrastructure you could lean on to set up a cert with the hostname

spicedb

?

I will give it a try. Thank you, Jake.

PHP Client

Happy thanksgiving! Leaving a Q before I forget - non necessary to answer today! Have y'all thought about "inverse relations"? We've found ourselves needing to implement the inverse of a relation (prime example: orgs have repos, repos are owned by orgs). I think persisting those relationships isn't a good idea because it's denormalized information. Have y'all stumbled upon something like this? Do you believe it's a "smell" of a problem somewhere else in the schema? Have you considered how to support this at the code level in a way we don't have to persist that duplicated relationship?

We've briefly discussed creating them automatically for all relationships, but we really wanted to collect more use cases before committing to something that deeply implemented. Because WriteRelationships is atomic, it would be fine to just make sure you write both in the same requests always. In your org example, are you trying to write permissions in your schema that would depend on those reverse relationships being present? We've also discussed "left pointing arrows" which is the arrow operator usage for "all of the objects that point to me", but the ergonomics are quite tricky.

Yes, while I'm aware we could write those 2 relationships, from a COGS perspective it is "quite a lot of tuples to add to the database" at our scale. That's right, we are creating permissions that would depend on that reverse permission, and actually quite a niche one that does further make it difficult to justify duplicating millions of tuples. The left pointing arrow seems interesting. At least for us, it would be necessary that the semantics are "all objects of a given type that point to me via a specific relation in that type".

on a different note, thanks for publishing the blog post on the consistent hash load balancing implementation. Very useful in order to inform our datacenter topology ♥️

Yep, you're understanding the left pointing arrow correctly -- I failed to mention the relation in my description, but that would be the intent.

Is there an issue filed for the "left arrow / inverse relation" topic? Otherwise I can open one