it can't be called directly yet, but it should be fairly easy to expose

I'll see if we can get it added to the beta API

sounds great! thank you so much! this is an awesome project, can’t wait to see it grow! 🙂

should be fixed in HEAD now

Oh nevermind I see that you can use

Unless I'm mistaken, it looks like setting SPICEDB_READONLY=true doesn't stop the garbage collection process? I'm getting regular errors because my store is actually readonly (a read-replica)

Hi all! I am running spicedb in WSL with the command

spicedb serve --grpc-preshared-key "my_key"

and when I run

zed context set blog localhost:50051 my_key

I get the following question

Enter passphrase to unlock /home/guillermo/.zed/keyring.jwt:

I am following the protect your first app tutorial and I don't know what I am doing wrong

is there anyone that can help?

@guillermotimon the secrets for

zed

are stored in your operating systems's secure keyring

it looks like it's falling back to using a file on your combination of OS and environment

is there already a file at that path? if not, you can probably just pick your own new passphrase

yes, there is a file there

~/.zed/keyring.jwt » cat zed\ secrets

but I haven't set any passphrase when installing zed

I am a bit lost why this actually occur

we are using this library to store the contexts as secrets in the keyring: https://github.com/99designs/keyring

can you try just deleting that file, and on the next run set a passphrase?

I was going to ask if I could do that, 😉

I did that and I honestly don't know if it worked, I left it empty for now and just move forward in the tutorial and I have this issue now

you forgot to set

--insecure

on the context

if you're talking to a local install

okay, now seems to work. thanks @Joey and @Jake for your help. I think I was a bit confused the first time the passphrase was asked.

I don't think you're the first person to report that, we could probably use some better UX in that scenario.

I would suggest a note in the tutorial 🙂

Hi everyone, I was wondering if someone could explain the prefix use case to me? I tried searching around and I saw a comment where it says prefixes are an organizational tool which was my understanding, however zed does not seem too happy when I try to write schemas with more than one prefix. Not sure if this is intended behavior. I feel this logic might not be intended https://github.com/authzed/zed/blob/29be8aca9160180965f52b2830b9190f21b643e1/cmd/zed/schema.go#L315-L367 My reasoning is zed has no issue on the first schema write, but then on any subsequent write it is broken regardless of what schema is passed in because it is using the existing schema and trying to derive the prefix from it.

zed does that because right now Authzed.com is limited to a single prefix which is unique per permissions system

Ah so the path forward then would be to not use a prefix at all or keep a constant prefix then I would assume? What is the roadmap for prefixes? Is there any desire to support more than one prefix? I think it would be interesting if prefixes were "scoped" where a schema could be written for one prefix then separately written for another prefix and they would be joined as one. Example:

// Write 1
definition core/user {}

// Write 2
definition myservice/thing {}

// Results in 
definition core/user {}
definition myservice/thing {}

// Write 3 
definition myservice/thing {
  relation owner: core/user
}
definition myservice/specificthing {
  relation thing: myservice/thing
}

// Results in 
definition core/user {}
definition myservice/thing {
  relation owner: core/user
}
definition myservice/specificthing {
  relation thing: myservice/thing
}

So the writes are scoped to a prefix and won't wipe out other prefixes.

yeah, its something we're considering

Right on, I think that would be pretty slick.