Any advice for modeling universally accessible data with logged out users?

use a wildcard

so you'd define a relation (or multiple) with support for a wildcard like so:

definition resource {
  relation viewer: user | user:*
}

you can then write a relationship giving access to

user:*

which means the resource is viewable to any user

if you want to support anonymous users

you can also create another type for them

or you can just "name" all anonymous users the same object ID

Ahh, ok, i like that model. I was curious what I would use for the ID of the (logged out) user, but using an anon user type does help that

ok cool cool

either use something like their IP, a random ID, or a predefined one

if you use a predefined one, it basically becomes a singleton

and then you don't need the wildcard at all

yep, that's a good way to disambiguate

then you write a relationship to

anonymoususer:staticidhere

I'm looking for information regarding system requirements for running SpiceDB. Is there any information floating around to help make projections on what I will need?

heavily depends on your scale requirements

@Joey I figured that's the case. It appears that the SpiceDB service caches results outside of the database like MySQL for instance. I'm assuming that's in memory, but I don't see any information about this in the docs. Is there a document somewhere that describes how the cache works, how much memory it will use or any information that could be helpful in planning for a deployment?

we're currently working on changes to the memory usage for the cache, but yes, the cache is stored locally in memory and it acts a modified LRU

Ok, thanks

is there a way to reset a permanent store [postgres in my case] back to the initial state - after i first ran:

spicedb migrate head

or should I just delete the database and run everything again, if i want to reset SpiceDB?

Deleting it is probably the fastest. The migrations only take a few seconds to run. Assuming this is a one time need.

do i need to reset the SpiceDB server as well?

like caches etc?

Yeah you just need to restart it.

Is this part of a dev test cycle? Or just a one time reset?

once in blue moon thing

SpiceDB looks interesting. Authorisation/permissions has been a difficult problem in a few systems I have worked on. The one thing that I'm not really convinced on is centralising complex permissions. At some level, it becomes very hard to separate what is a 'permission' and what is 'domain business logic'. In most distributed systems, encapsulation is considered one of the most important principles. If your permissions systems are complex, then your shared permission system becomes a complex monolith combining the complexity of all other systems. Perhaps I'm thinking about this the wrong way though? It seems at the very least, that relationships and permissions should be only written from a limited set of places. 'Almost a permissions for permissions'.