|
(Hi there! Surprised author here---I hadn't realized this made its way to the front page) I love your questions because they get to the heart of how to make this stuff easier for more people, and in transparency, I only have some of the answers! :) > What's the permissions/ACL model, and how do you keep that from getting too confusing for the average person?
(You asked a lot more here, but I think this is the root of this question)
The admittedly naive permissions/ACL model I'm envisioning/speccing now is at the database level, similar to GitHub at the repository level. If you create a database, you can add read/write and read-only collaborators, one of which is `public`/`world`, which would make the database accessible to unauthenticated users. Your questions around table slices/views are excellent, and in the model I'm proposing, ayb won't be able to help. The model I'm proposing will be good enough for "here's my dataset, and you can build on it" or "I spun up a project and have a private DB that my webapp is gating" but not "I want user X to have access to row Y." Row-based auth would thus be pushed into the application layer, which seems to come with the territory with SQLite as best I can tell. To contrast, something like Supabase is able to provide both a database and row-based auth because Postgres provides better support natively, and Supabase then made it easy to add common auth providers. > what makes your CLI wrapper that accepts SQL (or your HTTP API that accepts SQL) any easier for average users to consume than just installing SQLite themselves and running the exact same SQL
If the goal is to write/learn SQL, I agree that ayb offers nothing on top of SQLite. As SQLite is the database and ayb is the database management system, the things ayb makes simpler are on the "management system" side --- without ayb, it's hard to create a new one, it's hard to control access, and it's hard to access one from a web application. You're right that by that definition, it's more developer-friendly than power user-friendly, and I hope we can do better with future iterations. |
I think it's cool that you're trying to tackle adding simplicity to managing a multi-user (if not actually multi-tenant, given the lack of row-level permissions management) SQL DB. My suggestion then would be to refine your pitch so that it matches your project a bit better -- that way you avoid the problem of people disappointed to find it doesn't do something they expected (but which it was never trying to do).