Simon Willison

One enormous advantage I have is that after #1150 I will have a database table full of databases and tables that I can execute queries against. This means I could...

What would Datasette's permission hooks look like if they all dealt with sets of items rather than individual items? So plugins could return a set of items that the user...

Perhaps this can be solved by keeping the existing plugin hooks and adding new, optional ones for bulk lookups. If your plugin doesn't implement the bulk lookup hooks Datasette will...

I want to keep the existing `metadata.json` "allow" blocks mechanism working. Note that if you have 1,000 tables and a permissions policy you won't be using "allow" blocks, you'll be...

Could I solve this using a configured canned query against the `_internal` tables with the actor's properties as inputs?

Redefining all Datasette permissions in terms of SQL queries that return the set of databases and tables that the user is allowed to interact with does feel VERY Datasette-y.

It's also a really good fit for the new mechanism that's coming together in #1150.

Another permissions thought: what if ALL Datasette permissions were default-deny, and plugins could only grant permission to things, not block permission? Right now a plugin can reply `False` to block,...

#1150 is landed now, which means there's a new, hidden `_internal` SQLite in-memory database containing all of the tables and databases.

I think the way to do this is to have a new plugin hook that returns two SQL where clauses: one returning a list of resources that the user should...