I just wanted to share a solution we just came up with where we can't guarantee unique ids for entities outside a namespace. you just use uuidv5 with the namespace as ... the namespace and your entity id (i.e. from an organization or document) as the

name

(or user input, however you call it). looks sound to us. our first approach/the one also suggested by @EvanCorkrean was to include the hierarchy in the id, which would cause db lookups we don't want. like "org.1.doc.1" as the document id. I should add that the namespace is known from the context and the entity id is always given via the request/persistence layer response.

what do you mean with "entities outside a namespace"? Are you referring to "namespace" in SpiceDB terms (namespace = schema definition) or a logical namespace defined by your client application? Also what do you mean with "db lookups we don't want?" is that specific to your application?

a namespace is an app instance (we call it workspace) and is just a backend. we create a backend per tenant. so it's a logical namespace defined by us. yeah it's also app-specific. I'd have to hit the db to get the org for a document to include it in

namespace.1.unit.2.document.3

.

understood, that wasn't obvious from the context, maybe I missed some earlier conversation. Can you given an example on what a tuple following this naming pattern would look like? I don't think I visualize what you mean here

that conversation was on zoom haha. imagine like: document:namespace.1.org.1.document.1#viewer@user:alice

so where is the UUIDv5 there?

ah, namespace.1.org.1.document.1 would be replaced by a uuidv5. as we can give namespaces to uuidv5's we have our "uniqueness" per namespace 🙂 even if the

name

of the uuidv5 is the same