Let the Little Guys In: a Context Sharing Runtime for the Personalised Web
Posted2 months agoActive2 months ago
arjun.mdTechstory
calmmixed
Debate
60/100
PersonalizationPrivacyWeb Development
Key topics
Personalization
Privacy
Web Development
The article proposes a context-sharing runtime for a personalized web, sparking discussion on the trade-offs between personalization, privacy, and the role of big companies in data management.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
32m
Peak period
4
3-4h
Avg / period
1.9
Comment distribution13 data points
Loading chart...
Based on 13 loaded comments
Key moments
- 01Story posted
Oct 27, 2025 at 1:27 PM EDT
2 months ago
Step 01 - 02First comment
Oct 27, 2025 at 1:59 PM EDT
32m after posting
Step 02 - 03Peak activity
4 comments in 3-4h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 27, 2025 at 11:37 PM EDT
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45723828Type: storyLast synced: 11/20/2025, 12:29:33 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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.
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
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
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 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.
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?
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.
Is this sentiment significant in the US?
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.