This post contains some interesting ideas and poses (or at least suggestively alludes to) a few thought-provoking questions but is weakened by spending too much of its word (and the author's thinking) budget on tangents about LLMs.

Side note: mashups and widget engines occupied a substantial part of technophiles' focus (incl. power users and programmers) 15–20 years ago. The W3C chartered a working group to investigate harmonizing different implementations. That interest eventually evaporated, and they all went away. It's almost eerie how rare it is to find any modern reference to something that consumed so much attention at the time. It'd be reasonable to wager that the majority of programmers under 25 have never even heard of Konfabulator or are aware of the hype that existed around other vendors' similar offerings.

I'm waiting for when a new browser maker comes along and gains market share by shaking up the conventional browser UI by offering stuff like a widget engine built into the browser and basic missing functionality like better UX around site logins (including its own native UI for ordinary (i.e. non-Cookie-based) HTTP auth), native support for dealing with tabular data (like sorting tables) and CSV, and of course direct authoring of Web resources—instead of offloading that to e.g. Google Docs and startups like Notion whose browser-based apps don't clearly separate the editor/tooling from the content, which in turns means it never really feels like first-class media that's really "of" the Web.

For the payment thing in particular, what I'd really like is if internet payments moved towards open standards. If my bank or credit provider was the one actually providing the "payment" part of the checkout flow, they could easily display my account information without adding a whole ton of complexity or additional privacy concerns.

Relatedly, it is frustrating that we have OAuth2 for authorization and OIDC for authentication, but we don't have similar open standards for making payments and subscribing to subscription products, even though PayPal has had proprietary implementations of the basic idea for ages. We don't have it for traditional currency, and we don't have it for custodial cryptocurrency wallets. What's the deal with that? I can totally understand why existing payment companies don't necessarily want interoperability everywhere, but the lack of attempts from even cryptocurrency exchanges seems bizarre to me. It's all just more proprietary stuff. Everyone wants to be Stripe, nobody wants to be PayPal. Why not both?

> We prefer a handful of companies - because the fewer apps that have our data, the less exposed we feel.

Is this sentiment significant in the US?

> You are not allowed to transmit or store my sensitive information anywhere (unless I give my consent).

The “unless I give my consent” part could be tricky; for a sufficiently big company it is relatively easy to guide, force or trick users into giving away their privacy.

Then again, perhaps this could be addressed on a technical level; e.g. somehow making it impossible for the app to distinguish between consent given and not.

> It seems like a web version of claude code + skills + marketplace, but with an encrypted database, and permissions that let you feel safe using yolo mode. I’m going to try it.

I'm building infra for exactly this thing :) Here I posted about it today: https://engineeringideas.substack.com/p/tasklet-is-the-o1-mo...

Architecture TLDR: In Fly.io, org-per user, manage keys in Fly secrets. A Postgres db with transparent data encryption (TDE), the master key is stored on user's computer in the keychain or in the password manager. Thus the nobody can read the data at rest. All containers are distroless so nobody can ssh onto them. Postgres is backed up via pgBackRest to Wasabi object storage with customer-provided encryption keys that are injected into the containers via Fly secrets.

Apart from the database for record-like things (chats, emails, tables), vectors for larger things (such as web pages) are stored in serverless LanceDB on Wasabi, too.

Also Bifrost (https://github.com/maximhq/bifrost) as LLM gateway and Agentgateway (https://github.com/agentgateway/agentgateway) as MCP and OpenAPI/REST API gateway.

Agents/apps themselves (Open WebUI, Zero Mail, etc.) are separate Fly apps, and have their separate schemas and users in Postgres. They also cannot go to public internet directly (prohibited via https://community.fly.io/t/new-feature-network-policies/1917...), only to Postgres, Bifrost, and Agentgateway.

Postgres, pgBackRest, pgBouncer and another Go sidecar for pg (a la Pocketbase, but with Postgres backend), live in a single container managed by Horust. Bifrost and Agentgateway live in separate containers, but the same Fly machine. This machine might be 1.5gb, 4 vCPUs. LanceDB is on a separate machine because it needs burstable memory and may be infrequently used.

All machines (core, lance, and all individual app/agent machines) are suspendable, so they almost don't cost anything when not in use.