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)