Feels like actual magic.
- A plain english request lands with a AI bot who responds with a specification for a chunk of interface **as a nostr note (Kind 6666)**
- The client knows how to render and handle actions in said nostr notes such that they become live applications
- Save these components to nostr lists to be reloaded later (or better yet, composed together with other components... the user's listed components are sent to the bot in subsequent requests so it may reference them in composed interfaces)
https://v.nostr.build/2j8XX38Joisbe2u2.mp4
#hypermedia
Login to reply
Replies (6)
To be clear, the AI is NOT returning html/css/js, the way shakespeare does. the AI is responding with a nostr event, and the client is reading that event.
bro I can't even comprehend this right now. What have you done π
note content is a sort of DSL-y spec for a ui, structured as json. the "client" is html and javascript that builds interfaces off that spec (and dangerously evals and whatnot). there's a claude api bot (with nostr mcp connections) that has a reasonable idea of how to turn requests into aforementioned "ui spec" json notes.
and it more or less works, somehow? completely unsafe and unscalable, but wild to experience - especially when you get it to successfully combine two previous components you have in your lists...
My intuition tells me this is cool, but I donβt understand
Whatβs the end goal you hope this can achieve?
Few will understandl exactly what is happening here but it is game changing.
nostr:nevent1qqsfsv35glfxhpg7vpzddylmzpl20mvkd6s9h5sz5z63gwyq0n5zu4gprdmhxue69uhkvet9v3ejumn0wd68ytnzv9hxgtmzv4h8xq3q9ma2w9dmk3kat0nt0k5dwuqzvmg3va9ezwup0zkakhpwv0vcwvcsxpqqqqqqzmxff4z
That about sums up my current state as well. following my intuition in these kinds of things has only ever led me to better states, however.
unclear exactly what the end goal is from here, but I think it has something to do with composability and marketplaces for software components (and will naturally involve WoT at some point, for all things must).
open source software is pretty far along the spectrum of "ownable" by the end-user, but there's a high technical barrier for simple stuff like "I want to change my client UI just a little". say you're a non-technical nostr user and you - for some inexplicable reason - want to add a "clock widget" to the upper-right corner your favorite client. you basically cannot do that without spending a month learning how to fork a repo, work with ai tools, learn how deploying code works, maybe figure out some devops, etc... In that sense, you don't "own" that UI.
consider the "ownership level" the user has over this UI:
https://npub19ma2w9dmk3kat0nt0k5dwuqzvmg3va9ezwup0zkakhpwv0vcwvcsg8axkl.blossom.band/b3cfe5e0f8ae24e11bc4650bba22c390e89a524c4a9ce7be47a84ad3bbc6793c.mp4
(_the user is already aware of a "note composer" element. asks for a new combined component with this and a clock_. this is now available to him in the future - or to anyone else, potentially)
Yes, they're still dependent upon a lot of systems outside of their control, but a picture is beginning to emerge. early days