Let the little guys in: A context sharing runtime for the personalised web | Hacker News Reader

Let the little guys in: A context sharing runtime for the personalised web

arjun.md

74 pointslouisbarclay13 comments

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.

A browser like that would be so great! I wonder if a chromium base (as is trending) would enable it...

OpenDoc [1] was another attempt in this space.

I think the fundamental problem was that no one ever figured out a business model around components. You can get people to buy an application and the application could edit its own files. But it's not clear how a document or app that contains a mash-up of pieces of code written by different companies is paid for.

Would users be willing to pay for a component that let them add charts to their word processing docs? Would that mean no one else could open the doc unless they had the same component? It didn't seem at the time like there was a business model that held together.

(The somewhat related counter-example is modern digital audio workstations. Third-party plug-ins ["VSTs"] are a remarkably success model there for both users and businesses. And users do seem to understand and accept that, yes, if your project uses some audio plug-ins then anyone else you collaborate with needs to have those same plug-ins.)

[1]: https://en.wikipedia.org/wiki/OpenDoc

I reckon components either have to be free, or the "platform" pays top creators. The latter is hard...but one could execute it better thank tiktok, who did it very inequitably - but it was still incentive enough.

Mashup engines were so gloriously hopeful.

It feels like Opera browser was super early (as usual), with widgets (2008). Eventually we had a widget spec (2013). Overall PWAs cover a lot of this terrain today as a packagable standalone webapp, but also there was a lot more excitement in the world about small UI programs that overlayed and/or worked with your desktop at large, that we don't see today (but omgosh I wish Project Fugu had browbeaten Android into having a capable web home screen widget option!) https://www.wired.com/2008/05/opera-targets-widget-developer... https://www.w3.org/TR/widgets-apis/

But more than widgets, there were such interesting attempts ongoing to stitch together an inter-site inter-networked web. Google Buzz's protocols & especially the Digital Salmon protocol (2010) was a fore-runner to Mastadon, a way for discrete digital identities to push Atom/RSS like entries (such as a "like" or comment) at each other. Trying to work under the Open Web Foundation (OWF). http://blog.jclark.com/2010/02/tour-of-open-standards-used-b... https://news.ycombinator.com/item?id=1140893

Even before this, the OpenSocial folks were working on very ambitious cross-site data and widget systems. I really think some deep-diving technical retrospectives into OpenSocial would be incredible, could maybe help us shake loose some of the rut we're in with uncomposeable consumeristic computing being the only thing we can even think to do. https://en.wikipedia.org/wiki/OpenSocial

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?

There have been various cryptocurrency-based efforts (including some of my own) in this space so we must presume that their lack of adoption is the issue rather than lack of available technical solutions.

Why the lack of adoption? I'm not sure but some combination of incentives, inertia and regulatory capture seems likely. Consider for example that the payment mechanism most people use (credit cards) took decades to become ubiquitous and is itself based on an older system (cheques and banks) that is much older. It's still not possible to freely and cheaply send money digitally in the US, but it is in the UK but only because the government made it a rule that banks had to provide such a service.

If there really are attempts at standards that sound like roughly what I am describing, I am definitely interested in hearing about them, FWIW. All I am aware of is the W3C Payment Request API, which is definitely very interesting and in a similar vein, but I really want something that works between parties on the web rather than between web entities and platforms/browsers...

Because there's nowhere to extract fees compared to the buyer/seller relationship?

> 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.

Yeah one thing is for sure, permission granted by terms of use and the like, are not realistically parsable by most users. Its sad how leaned-upon they are given that.

It seems like a well constructed runtime could encourage permissions that are right-sized, action-aligned, and even linked to specific UX components - like it could be possible to have a special runtime-compatible "Pay" button that can be included in an app, which automatically serves as proof of consent to release a credit card number.

> 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?

> 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.

Reply on news.ycombinator.com