# 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  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.
){kind=link}
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.