nostr-protocol
NIP-XX: Smart Widgets - Interactive Components for Nostr
This NIP introduces Smart Widgets (Improved version from #1454), interactive graphical components encapsulated as Nostr events (kind 30033), designed for seamless integration into Nostr clients. Smart Widgets enable rich, dynamic content that enhances user interaction through embedded applications, interactive forms, and mini-apps within the Nostr ecosystem. Various mini-apps smart widgets are available under https://yakihonne.com/smart-widgets to check from.
Compare https://www.hypernote.club/
Is there any human-readable examples such as these, we can look into it ?
Please do note these are mini web apps deployed by real users.
hey @staab , the HyperNote has a very different logic than smart widgets and i'm going to sum up a few key different points here to make it clear:
| Smart Widgets | HyperNotes | |
|---|---|---|
| Definition | An event that represents a graphical component in the form of keyword sets (image, button, input, etc.) | An event that contains the full code for a small web app |
| Variation | Three types: basic, tools, and action | A single representation: HTML code |
| Purpose | - Basic widgets: in-client interactive components for simple scenarios (e.g., displaying charts, redirecting links, lightning payments, etc.) - Tools/Action: gateways to more complex apps hosted remotely and embedded in Nostr clients. These use the smart-widget-handler package to enable secure communication between the mini-app and the host app. | Lightweight apps rendered as HTML. They can be injected directly into the Nostr client’s DOM or isolated in an iframe. |
| Complexity | Smart widget events hold minimal data, making them lightweight and easy for Nostr clients to interpret | HyperNote events can grow significantly larger as the HTML code scales, giving clients more flexibility but also more overhead |
| Scalability | Developers can create complex scenarios without being constrained by technical limitations | Limited options for scenarios due to the way apps are stored and shared |
| Nostr | Represents in-client graphical components (for basic widgets). Tool/Action widgets are hosted remotely, often centralized and not fully Nostr-native. | HyperNote HTML code is fully decentralized and shared directly over Nostr |
| Security | Embeds cannot access parent browser properties such as localStorage or local databases, offering stronger isolation | Injecting raw HTML from untrusted sources poses risks (e.g., reading/writing sensitive data or malicious code execution) |
I don't think that's accurate. Hypernote has been through some iterations, see the following links for more details:
- https://njump.me/nevent1qyghwumn8ghj7vf5xqhxvdm69e5k7tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszrnhwden5te0dehhxtnvdakz7qgkwaehxw309ajkgetw9ehx7um5wghxcctwvshsz4mhwden5te0ve5kcar9wghxummnw3ezuamfdejj7mnsw43rzup5ddnns7ncw44hq7tdxd5ryvr9wfnxzvmnv9kk5vpswfknyem5x3cn2amxw4uh2vm5vuc8svm2vuekwetnwehxx7rx8qqzq6pp2c2wd6qwdv75xamn4dvxf5qxxe9vj7z383nr68qg5geytg3tt6rhze
- https://njump.me/nevent1qy88wumn8ghj7mn0wvhxcmmv9uq4wamnwvaz7tmxd9k8getj9ehx7um5wgh8w6twv5hkuur4vgchqdrtvuu857r4ddc8jmfndqerqetjvesnxumpd44rqvrjd5exwap5wy6hwen4096nxar8xpurx6n8xdnk2umkde3hse3cqyghwumn8ghj7mn0wd68ytnhd9hx2tcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qg3waehxw309ucngvpwvcmh5tnfduhsqgp59vch380dn74xqfwgxlkzh34jncjfewdtulh660jdjwg3xedfuu8akac4
You can also play around with hypernote here: https://hypernote-elements.vercel.app/
Hypernote isn't html-dependent (even though it uses some web tech idioms); Paul has built a proof of concept swift ui renderer. Based on that, most of your comparisons are invalid (other than the point on scalability, which I also don't think makes much sense).
Anyhow, I only mention it because it's a very similar thing. I think it's a superset of this PR, so in an ideal world the specs would be merged, but I think it's fine for both to co-exist.
@staab The first comment about HyperNotes was talking about an older idea, so my original point still stands there. But looking at the newer version, it feels almost identical to our first proposal SWv1. That version got a lot of pushback because it made things complicated for clients, didn’t really separate functionality from UI, and relied on pushing a lot of heavy data through relays just to allow customization. It ended up creating more inconsistency than value.
In that sense, HyperNotes is basically a rebrand of SWv1 with the same issues baked in. Smart Widgets v2, on the other hand, is designed to be lightweight, easy for clients to interpret, fully aligned with Nostr standards, and focused on functionality first. It still gives devs room to be creative, but without forcing bloated or hard-to-maintain standards.
If you haven’t already, I really suggest checking out our updated PR and the docs for the packages we released — it makes clear why Smart Widgets v2 solves the pain points that HyperNotes still struggles with.
This is neat, i think it should be done with coordination with the yakihonne folks as having multiple implementations of very similar functionality isn't great. I do like how hypernote works.
@rabble This is the version 2 of the previous Smart Widgets, we have improved the logic behind it, as well as providing multiple packages for rendering, publishing and communicating with mini-apps and widgets, and by the way, WE ARE the YakiHonne team lol