I have a question about the design of spicedb.. I think this is somewhat critical of the current way. Isn't it a reality though that spicedb will always be slower than if someone were implementing spicedb-like authorization directly in their application code? To fix this I think spicedb should probably be embeddable into the application and be able to query the same inmemory cache that the application is already using. The application is already querying data from my database, if spicedb does that again on its own then that is extra load for nothing. Even the grpc call itself is technically extra load for no reason. Making the spicedb core embeddable is pretty much the only way I can see where spicedb isn't inherently always going to be slower than your own custom authorization implementation. In this view, the spicedb core would use an interface for the inmemory application cache that I already use in the application to retrieve data. Data that could then be used during a caveat computation. Because this is another problem with an external service like spicedb: In my regular application coding if I want to do an authorization check on one of the many properties or fields that my user has, I'll just do a quick if-else check in my code on data that I already have because I needed it for the application ui. Likewise currently I'm effectively required to code logic in a special spicedb DSL as well as to provide the data constantly over the wire. The spicedb caveat logic itself could instead be a native function that spicedb invokes and I provide. Maybe an analogy would be like a postgres function coded in C or an sqlserver extension in c# instead of having to use SQL (in this case, the spicedb DSL). That way spicedb would be able to operate on inprocess data with inprocess function logic. The fastest way.