2. Diagrams, Graphs and advanced Tables are a b*tch when it comes to displaying them properly on mobile. Creators already hate it when they don't have the guarantee of proper display on the same platform, just imagine this across XXXX different apps.quoting naddr1qv…pwwk# Hypernote
A hypernote is a html-based frame that can be used as **Stories** or **Widgets**.
Hypernotes offer creators an interactive micro-website with Nostr-functionality that is guaranteed to display in the intended way in any app that implements hypernotes.
## Limitations that make it work
### Standard Dimensions
![Dimensions]()
Hypernotes 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.
### 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.
3. If you're going for universality through a common library anyway, you might as well just go for Nostr flavored MarkDown:
4. I'm making things like app and music album descriptions be wikis behind the hood, so that original publishers are filling in our great encyclopedia as a byproduct 💪 . Asciidoc complicates that.quoting naddr1qv…f0u3
Markdown + X, Y, Z is a problem, but Markdown + N can fix that.
Where N = any type of Nostr event.Whatever Markup language you choose, people will be referencing other Nostr events in it all the time. Since apps have to find ways to display those events (or the links to them) anyway, we mights as well use that as an opportunity.
Why can’t Tables, for example, be embedded Nostr events?
Switching from Markdown to Asciidocs (because it has tables and some more technical stuff) still doesn’t make Tables a great experience. On mobile, Tables are notoriously hard to display in a useful way. It depends on the use case, size of the table, etc….
Creators need guarantees on these things being displayed the way they intended.
There’s a reason why most authors just embed pictures of tables instead. It has little to do with Markdown not really supporting tables and more with them ensuring readability and appropriate styling.So what if you enhance Markdown not only with embedded Nostr Events but also with something like Hypernotes Widgets that serve as a preview/display for those Nostr Events?
That way:
- you are still using the most simple and popular markup language
- devs “only” have to implement one extra thing (Hypernotes) that handles all the complexity and extensibility from there
- authors can create articles and wiki entries with interactive elements in them, can have the guarantee that they display properly, can use any styling that suits them, etc…
- the worst case scenario of reading it in a random crappy app still displays the link to the event (including it’s explanatory metadata)
Imagine custom interactive graphs, polls, media players, products, … embedded in articles BUT limited to the Nostr-verse for all interaction and data fetching.
(this article will be updated with UI prototypes and further thoughts)
5. There are a lot of WIki- and Nostr-specific things to standardize to make them usable, so you'll be flavoring all over AsciiDoc instead. Examples: a "quick facts" section for wikis, Nostr event embeds, zettels, ...