[HN Gopher] Let the little guys in: A context sharing runtime fo...
___________________________________________________________________
Let the little guys in: A context sharing runtime for the
personalised web
Author : louisbarclay
Score : 54 points
Date : 2025-10-27 17:27 UTC (5 hours ago)
(HTM) web link (arjun.md)
(TXT) w3m dump (arjun.md)
| cxr wrote:
| 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.
| _young_grug_ wrote:
| A browser like that would be so great! I wonder if a chromium
| base (as is trending) would enable it...
| munificent wrote:
| 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
| _young_grug_ wrote:
| 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.
| jauntywundrkind wrote:
| 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
| merelysounds wrote:
| > 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.
| _young_grug_ wrote:
| 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.
| jchw wrote:
| 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?
| dboreham wrote:
| 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.
| leventov wrote:
| > 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.
| neilv wrote:
| > _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?
___________________________________________________________________
(page generated 2025-10-27 23:01 UTC)