then to cancel an investment you just do:

investment:123#canceled@investment:123

I was here last week

If there is a sponsor on more than one investment and one of the investments is canceled, the sponsor should still be active

oh wait, it's tied to sponsor

yeah, what you described would be the problem with canceling sponsors at the platform level

that's why I moved it down to the investment level

yep, that makes sense now

Hi folks, does Authzed support auth token scoped to certain resources or relationship?

no we don't have that capability

can you elaborate on your use case?

we have multiple api team that use the same authorization system (schema). Some relationship is less sensitive and at large scale that it has to be done via API, like adding relationship when user sign up in one of the apps. Granting apps access to certain API is much less frequent and is more sensitive. We want token that can only write user relationship and not app relationship

interesting

would it be sufficient if the token could be limited just to specific namespaces?

i guess that mean multiple namespace (permission system) with nothing shared between them?

oh sorry, I used the old terminology

I should have said: object type

so sort of a half-way between permission-system wide token permissions and relationship specific tokens (a la row level security)

yeah, obj type is what i want

is this more of a feel good type requirement, where you would feel better if one service couldn't write to the object types ostensibly managed by another service, or is this a hard requirement?

like could you launch without it if we put it on the roadmap, and then adopt it when it's ready?

we could launch without if it's on a roadmap

ok, we're having a discussion about the feasibility right now

I think the hardest part is probably the UX

currently token can only be managed using the UI, right?

correct

Yep, tokens are a part of the Authzed.com tenancy layer and are built on top of the SpiceDB, rather than in it.

There is an issue discussing open source tenancy for SpiceDB itself, though.

ooh, does that mean running spicedb ourself will not have token?

there is only a pre-shared key that protects the whole API

it's a required flag you pass to SpiceDB for what value callers must provide as a bearer token