marcua

Thank you! This blog post speaks a bit more to how it works: https://blog.marcua.net/2026/05/05/figmimic. Credit to Figma for capture.js. This bookmarklet just packages/surfaces the library for easy use.

Thank you for trying the bookmarklet and catching this issue. I pushed some fixes that should get around the CSP issue by storing capture.js in the bookmarklet. Let me know how it works for you now (you'll have to reinstall).

Thank you for trying the bookmarklet and catching this issue. I pushed some fixes that should get around the CSP issue by storing capture.js in the bookmarklet. Let me know how it works for you now (you'll have to reinstall).

Thank you for asking. It's a difficult concept to wrap one's head around, but I think the video attached to the blog post shows it most clearly. There's no authentication with the application in the traditional sense, and the application never asks for your identity. You ARE authenticated with the database provider (ayb's thedata.zone in the video), which passes a token to the application so that the app can prove it has been authorized to access the database on future requests.

Thank you for your questions. I'll take a stab at answering them: * The underlying databases that ayb fronts are SQLite and DuckDB. Both are relatively battle-hardened RDMBSs. That said, I don't think the approach I'm proposing has any bearing on the difficulty of a query: if a centralized DB would struggle with a query workload, the personal DB is likely to as well. One saving grace is that workloads are slightly more isolated in my approach: someone else's data that's poorly shaped for a query shouldn't affect your queries, which is not something most all-users-in-the-same-database approaches can claim. * I make no special security claims beyond what is listed in the documentation [1]. ayb specifically has been used in production by low single digit numbers of people, so you should absolutely wait to use it for any super-sensitive data, especially in a shared/multi-tenant context. That said, you should be no more confident in the random web app that stores your data for you than you are in ayb's security. * This blog post is focused on personal data: the to-do list, the streaks/goals you've set out for yourself, your database of newsletter subscribers. I think there's some interesting work to be done in the enterprise around access control. In ayb, there are coarse-grained sharing/permissions [2], but I don't think that's enough for most enterprise situations.

[1] https://github.com/marcua/ayb#isolation [2] https://github.com/marcua/ayb#permissions

The solution I'm proposing does not assume the data is local to the user's machine. In the video attached to the blog post, a web application is authorized to access a database hosted by a different service/domain. While the blog post covers collaboration/social data as current limitations, I'm curious what other classes of web apps you think don't work with the proposed approach?

Hello there! I agree users may want one or both of these features in their interaction with an application, and that their preferences likely vary depending on the type of data we're considering. The way I'm reading what you're saying, there's some sort of tension or tradeoff between the two features that I don't fully understand. Can you help me understand it a bit better? Thank you!

Thank you for pushing on this. Some clarifications that might help you see this as more practical than your initial impression: * I totally agree that databases require maintenance, HA, etc. My argument is not that someone running a database magically doesn't have to do these things, but rather that the person running the database doesn't have to be the person running the app. In the video attached to the blog post, you can see that separation in action: marcua.net hosts the Todos app, but thedata.zone hosts an ayb [1] database instance. As the owner of thedata.zone, it's my responsibility to configure the database for stuff like offsite snapshot-based backups (which I've done). * Schema migrations are an application-level concern, and are no more or less challenging in the model I'm proposing. As a convenience, in the ayb.js client I open sourced, I add some utilities for forward-only migrations to make it a little easier for application developers who build around ayb to have migrations fire at the right moment in their application's lifecycle. * Authorization is definitely not assumed to be one database to many apps. In the video, look for how the user already has a streaks.sqlite database (for storing streak data) and creates a new todos.sqlite database for storing their to-dos.

Thank you for engaging on this! I look forward to hearing your thoughts!

[1] https://github.com/marcua/ayb

The content has varied over the years, but in the past few years, I've used the blog to explore side projects outside of work. This has allowed me to separate my primary responsibility at work (manager/unblocker/collaborator/prototyper) from my personal interests in hacking.

It's so helpful to read the headline through your eyes! While I can't change this title on HN, I'll tone down/relegate the multi-tenant bits to the features section in the future. Thank you for this feedback!

Thank you for your kind words and the great question!

To your compliment: I agree ayb can help with easier prototyping today.

To your concern: I would not use ayb in a production setting today. To be explicit, while the roadmap [1] is long, I think that ayb will be useful in production once we've implemented a v1 of auth, permissions, persistence beyond the node, and isolation.

To "how to prevent that," here's a rough outline that I'm open to feedback on:

  - Implement the v1 features above

  - Host a public instance (and encourage others to, not trying to empire-build)

  - Build some fun applications on top of the public instance myself to stress test it

  - Encourage others to do the same and/or run some "learn SQL" classes to better understand where beginners get stuck and address those issues

[1] https://github.com/marcua/ayb#roadmap

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'm curious: what sort of fidelity have you seen in `grab-site`'s rewritten static asset URLs? Having to fix URLs that weren't properly rewritten ended up taking me the most time.