My "vision" for this is: I read this whole book a bunch of months ago:

Hypermedia: A Reintroduction

, haven't re-read it yet, but it wormed its way into my mind. (and these notes happened around the same time: ) I think hypermedia is a really promising way to potentially get super powerful clients with very minimal client-side code. that concept + the ability for nostr events to be arbitrarily complex has been stewing in my head as a way to get super malleable* UIs and applications. I don't know where this goes yet, or if it has any legs, but it seemed like a basic feed client was the first step. (might be wrongheaded, perhaps a much weirder, non-social client would be a better proving ground, dunno). All that to say: it's just a lot of random ideas banging together and I doubt any experiments or suggestions would overstep, since I don't yet have clear boundaries to begin with :) maybe a few guidelines would be: - keep events nostr protocol and relay compatible - adhere to hypermedia principles (I may be guilty of breaking this myself, haven't thoroughly reviewed) - try to do as little as possible on the server side aside from just massaging and re-forming stuff for hypermedia-style presentation - - ideally we minimize the footprint for distrust on the server. someone should be able to self-host it easily. and ideally we could host it simply in a secure enclave with cryptographic attestation to prove that there's no censorship or funny business happening on the server. but i'm digressing far here... - I don't know, making it up as I go along here --- * At some point I should explain what I mean by "malleable". but briefly: infinitely changeable and re-configurable by the user, no hard edges, amenable to being coaxed to inter-operate with other things at the user's direction, etc. etc. in a word: "purely ownable, in an end-user way"

Some more on malleable software here:

Malleable Software

Designing software environments where people can customize tools in the moment to meet their unique needs.

this is actually beautiful. I'll have a theming PR for you tomorrow (with some additional UI things) then I'll spend some time stewing on this the info you sent over. i love the idea of bringing the web back to a bygone era where it was more than just clickbait content and you're right, Nostr is absolutely the perfect stack to help this happen. Once i'm caught up on the reading (lol), I'll throw some ideas your way.

in the extreme case, a proper hypermedia server/client should let the ui and even functional aspects be entirely driven by notes' content. imagine what vibecoding would be like if it didn't even need to be in source code files or hosted anywhere.. entire uis and ux interactions composed soley of notes' content.

here's what the demon says about this: This makes a lot of sense and is a compelling vision. You're describing something like hypermedia as the engine of application state (HATEOAS) but taken to its logical extreme in a decentralized context—where the "server" is the relay network and the "responses" are notes that carry not just data but UI/behavior instructions. Proposal for demonstrating malleable UI/UX 1. UI-as-content notes Define a convention where certain notes (or note fields) contain UI descriptions: ``` { "kind": 30023, // or a custom kind "content": { "layout": "card", "fields": [ {"bind": "$.author", "display": "avatar"}, {"bind": "$.content", "display": "markdown"}, {"bind": "$.tags[?(@[0]=='t')]", "display": "chips"} ], "actions": [ {"label": "React", "emit": {"kind": 7, "content": "+"}}, {"label": "Reply", "emit": {"kind": 1, "tags": [["e", "$.id"]]}} ] } } ``` The client interprets this schema and renders accordingly - no hardcoded "note card" component. 2. Progressive demonstration ``` | Phase | What it shows | |-----------------|-----------------------------------------------------------------------------------| | Static | A note whose content is a JSON UI spec; client renders it literally | | Dynamic binding | UI spec references other notes via nevent/naddr; client fetches and binds data | | Actions | Buttons in the UI spec that, when clicked, publish new notes (reactions, replies) | | Self-modifying | A note that describes how to render itself (recursive/meta) | ``` 3. Minimal proof-of-concept A single HTML file that: 1. Subscribes to a specific note (or set of notes tagged #ui-spec) 2. Parses content as a UI DSL 3. Renders components dynamically (e.g., using a small interpreter or even eval for demo purposes) 4. Wires up actions to publish events back to relays This could literally be a UI that updates itself when someone publishes a new UI-spec note - no deploy, no build, no hosting. 4. Why this is powerful - Vibecoding without files: Describe your app in notes, iterate by publishing new versions - Forkable UIs: Anyone can publish an alternative UI-spec note for the same data - No servers: The "app" is just a dumb interpreter + the note content - Composability: UI specs can reference other UI specs (components as notes)

Additional reading on HATEOAS:

</> htmx ~ HATEOAS

In this essay, Carson Gross explores HATEOAS (Hypermedia as the Engine of Application State), explaining how it enables REST APIs through hypermedi...

@Geektoshi check out this branch sometime:

GitHub

nostr-hypermedia/hateoas-js-readme.md at hateoas-js · vcavallo/nostr-hypermedia

HTTP-only Nostr client aggregator with REST and hypermedia support. - vcavallo/nostr-hypermedia

UIs and actions as specs published in a note, the "client" is a single html file... This is a bit of a tangent from the master branch, but it's a pretty fun direction

imagine my surprise seeing alpine.js in the doc as i'm watching a video on htmx that mentions alpine.js lol. you have taken me down a rabbit hole, friend.

No one overstepped anything , just chip in , I have not look yet . Please bring some more ideas and implement

Do you think if you create Nostr clients using Google cloud , it means no sovereignty? I am asking cause Google keep trying to catch me to use its cloud ☁️

Just don't rely on any specific google cloud features (just use it as a raw VPS) and you'll always be able to take the code and run it elsewhere.

this has gotten scary... look what this screenshot is in reply to

😂😂😂

Thank you !