_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML Let the little guys in: A context sharing runtime for the personalised web
neilv wrote 18 hours 9 min ago:
> 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?
leventov wrote 18 hours 54 min ago:
> 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: [1] 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 ( [2] ) as LLM gateway and Agentgateway ( [3] ) 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 [4] ), 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.
HTML [1]: https://engineeringideas.substack.com/p/tasklet-is-the-o1-mome...
HTML [2]: https://github.com/maximhq/bifrost
HTML [3]: https://github.com/agentgateway/agentgateway
HTML [4]: https://community.fly.io/t/new-feature-network-policies/19173
jchw wrote 19 hours 17 min ago:
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?
arccy wrote 16 hours 18 min ago:
Because there's nowhere to extract fees compared to the buyer/seller
relationship?
dboreham wrote 17 hours 46 min ago:
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.
jchw wrote 12 hours 22 min ago:
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...
merelysounds wrote 20 hours 37 min ago:
> 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 20 hours 20 min ago:
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.
cxr wrote 22 hours 0 min ago:
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.
jauntywundrkind wrote 19 hours 21 min ago:
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!) [1] [2]
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). [3] [4]
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.
HTML [1]: https://www.wired.com/2008/05/opera-targets-widget-developer...
HTML [2]: https://www.w3.org/TR/widgets-apis/
HTML [3]: http://blog.jclark.com/2010/02/tour-of-open-standards-used-b...
HTML [4]: https://news.ycombinator.com/item?id=1140893
HTML [5]: https://en.wikipedia.org/wiki/OpenSocial
munificent wrote 19 hours 40 min ago:
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]
HTML [1]: https://en.wikipedia.org/wiki/OpenDoc
_young_grug_ wrote 19 hours 29 min ago:
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.
_young_grug_ wrote 20 hours 31 min ago:
A browser like that would be so great! I wonder if a chromium base
(as is trending) would enable it...
DIR <- back to front page