No, it's not.

- They invent their own mark-up language

- They do not give the creator any guarantee on how it will be displayed

- They can be endless in the screen space they take up

- They cannot be used as Stories

- They cannot be used as Widgets that are in any way "Smart" because it always displays the exact same block structure. You cannot click a button and have it display something else, much less handle a Merchant Check-Out, play a game on it, etc...

- They are not a solution to handling the middle ground between different apps (displaying an app release event kind in apps that don't support this event type, for example)

- They don't let you do anything that you cannot currently do with existing event types. We already have polls, you can already make posts with links, images, videos, etc...

They're not useful and make Yakihonne look like any other engagement farming crypto platform.

= Hypernote

A hypernote is a html-based frame with [[Nostr]] functionality.

Hypernotes offer creators an interactive micro-website:

* that is guaranteed to display in the intended way in any app that implements hypernotes

* that any Nostr profile can interact with (i.e. sign events) from within other apps

* that can fetch and display Nostr events that are updated in real-time

They can be used as:

* *Stories* (360px / 640px)

* *Widgets* (360px / max 640px)

* Anything else that makes you think "Interactive PDF"

== Limitations that make it work

=== Standard Dimensions

image::[]

Hypernotes Stories and Widgets have a standard width of 360 pixels and a maximum height of 640 pixels.

That way:

* There can be a reasonable guarantee that they are properly displayed across clients and the creator doesn't have to worry about viewers not experiencing the hypernote as intended

* The html just has to work for one size and implementations don't have to make everything responsive

* Media, such as background video and images, can be scaled to that size and even low-bandwidth users can render the hypernotes reasonably fast

* It is compatible with the ratio that is used by Big Tech and with the standard ratio of images

* Builders can adapt the height to their use case, but cannot make it extend beyond the screens of mobile devices. This ensures that the Story/Widget can be displayed fully on nearly any screen, without having to scroll within the frame.

* Apps can choose to what size they scale down/up the hypernote in their interfaces depending on the use case. When opened on mobile for example, they will probably prefer scaling it to the full width of the device.

Other (standard) dimensions are welcome for anything that's not a Story or a Widget.

=== No legacy API calls

Hypernotes *cannot* communicate with the legacy web.

Hypernotes *can* communicate with the Nostr-verse:

- fetch nostr events

- fetch blossom files

- ...

Keeping the communication channels 100% Nostr-based:

* makes hypernotes more secure and easier to verify/understand

* ensures more accountability (there's an npub with a reputation behind everything)

* avoids link-rot (the whole goal of events and blossom files is that they're easily retrievable)

* incentivizes the building out of Nostr native tools and content types

* makes it very easy to remix any hypernote. Since all of the building blocks can be transparently displayed, interchanged, adapted and re-uploaded into another hypernote.

=== No scrolling

A hypernote is not scrollable by default. Since it is almost always displayed as a frame within another app, that has its own scroll and swipe actions, you run into UX conflicts when you allow hypernotes to also have native scroll functionalities.

Hypernotes creators can (and should) find other ways to let users navigate lists or content that is larger than the hypernote frame.

=== Whitespace

If used as a Story, hypernotes should have enough whitespace on the left and right side of the frame so users can easily click/tap through them.

Many apps will overlay headers and footers on these Stories so it is best practice to leave 80 pixels free of any interactive elements on the top and bottom of the hypernote.

== Use Cases

=== Stories

Creators need a way to build fun, visual content frames that:

* People can click through

* Have simple interactivity built in

* They can bundle into multi-frame Stories

Examples of things they can use Stories for:

* Instagram-like Stories (obviously 😉)

* Reels

* Their Linktree

* Their micro-website

* Interactive Data Visualizations

* Simple Games

* ...

=== Widgets

Widgets are a great match for the middle ground between various Nostr apps.

They can be used to:

* Show interactive previews of content types in apps that do not support this content type. _Think of: Music album + listen and bookmark buttons, App releases with info + download button, ..._

* Offer interactivity in Chats that goes way beyond messages. _Think of: Check Outs with Merchants, Custom polls, Date pickers, Christmass present organization, ..._