Nostr Markup Language

[cxplay]

This issue is inspired from: https://github.com/nostr-protocol/nips/pull/904#issuecomment-1837962803

To improve overall user experience, it would be advantageous for Nostr to introduce a universal markup language that accommodates the content creator's preferences and permits viewers to accurately interpret the notes. Additionally, this would address the current issue with how clients handle URLs.

The markup language should be consistent and precise in all areas to ensure uniformity.

• The language needs to be lightweight, specifically designed for the layout requirements of mixed multimedia content.
• Source code readability is crucial, even when not rendered.

While Markdown fulfills these requirements, it has become incredibly flexible and has given rise to multiple "standards" due to numerous application-level variances. Nostr should consider devising its own Markdown style, similar to GitHub Flavored Markdown (GFM), to maintain consistency. In the current client, Amethyst utilizes Markdown by default for note content, providing an effortless means of implementation: Make Markdown more than just NIP-23.. Since Markdown's source code is readable enough, it is one of the solutions to this need.

---

This is an idea that came to me a long time ago, from problems I've had with Nostr, and I'm posting it here for all to discuss. I'll add some use cases later. (My English is not very good, sorry.)

[cxplay]

Issue with quote repost using nostr uri scheme

Quote Reposts are defined in NIP-18, URI scheme is defined in NIP-21.

Publishing by referencing an existing note is a very common behavior, and it is now possible in Nostr to reference an existing note with a link of the form nostr:neventxxx. NIP-94 also uses the same uri scheme for embedding images in notes.

But once a link of this form is used, it means that the way the quoted part of the event is rendered is entirely up to the client. In the case of a short note that references an article that is tens of thousands of words long, most people would prefer that it just be a reference to the article, rather than the client displaying the full length of the article. There may be clients that have considered this scenario, and are trying to toggle the note or the reference in the note after a certain content length has been reached.

But what the creator really wants is to share the article as a normal HTTP link, hoping that readers will find it through that link. Currently the only way to do this is to attach a link to the njump instance of the article or an HTTP link to some other long text content gateway to the note, which obviously introduces the uncertainty of DNS into Nostr.

This begs the question: How do creators declare how the uri scheme will be displayed in their notes?

In the form of a simple clickable link? In the form of an inline display contents? In the form of a link preview[^1]?

Unfortunately, most current clients only support the second way of displaying such links. Even for a short note, the events in a uri scheme can contain many, many nested events, so sometimes creators don't want the client to present them directly to the reader, who can then click on the link to see them for themselves if they want to.

[^1]: As far as I know Long-form Content (NIP-23) already supports article descriptions, titles and OG images.

[cxplay]

Uncontrollable URL handling

I have a URL in my notes that points to an image resource, how do I let the client know it's an image? Is file extension? Or MIME Type?

But obviously the note creator can't do that, unless he uses NIP-23 to embed the image URL in Markdown. Or he uses NIP-94. Both of these approaches declare the URL's handling in advance, so the client knows "they're images". But at this stage, using NIP-94 as a way of posting images is too cumbersome, because I host my own media files and use my own domain name, and just using NIP-94 to declare to the client that "they're just images" adds to the complexity.

Relying solely on file extensions (no, just extensions in URLs) to recognize whether or not there is an image behind a URL is outdated. File extensions have long since become irrelevant in dynamic network file systems.

For sample: https://avatars.githubusercontent.com/u/62034099 (My avatar.)

---

I have an attachment URL to an image resource in my notes, how do I get the client to show it as a clickable link only?

I'm a big fan of sharing things with direct file resource links, including images. But it doesn't work on Nostr, because I don't want it to show up as a media resource within the note, but all clients are doing it. The content creator has no control over the fact that an image link cannot be displayed as an image by the client, and that's the problem that can't be solved right now. One might say "the client can cancel link previews." Well, what I'm asking is, why can't the content creator state up front that the link "should not be shown as a preview in the note", when it's clear that asking the reader to disable the link preview on the client side doesn't solve the problem at all.

Borrowing from the most common method used in the Twitter era, do I have to break the integrity of the URL? It's like this: ht😅tps://gleasonator.😅com/pikachu😅.png

[vitorpamplona]

Makes sense. I wouldn't try to solve the entire markup language at once, but propose things that can solve your current issues.

For instance, I have a need to define an "Ask for invoice in a given amount" link in the middle of kind 1. In that way, you can post something like:

"We have 3 plans. Choose one: " "1. [100 sats](nostr:createInvoice?user=<userHex>&amount=100)" "2. [200 sats](nostr:createInvoice?user=<userHex>&amount=200)" "3. [300 sats](nostr:createInvoice?user=<userHex>&amount=300)"

When clicking on the link, the client must hit the user's ln address from it's profile, create an invoice for the specific a mount and display for payment.

[mleku]

it would be nice to at least have header levels, bold, underline and italic, and captioned images

labeled URLs (text replacing the URL text) are a bad idea in general because of phishing potential

tables are too complicated and inflexible and anything that creates layout rules should just be left out, stick to simple linear structure only

code fences and blockquote indent also belongs in it for especially technical users to present code snippets, which can optionally have syntax highlighting for code fences

oh yes, lists... again staying simple, just allow one format, number and period, with no interpretation (just show the wrong numbers if they are wrong), dash for bullet points

[cxplay]

Ref to Markup language For Misskey (MFM):

MFM, short for Markup language For Misskey, is a proprietary markup language that can be used in various locations in Misskey. Some of its syntax is compatible with Markdown and HTML. —— MFM | Misskey Hub

[mleku]

I think this makes a lot of sense. My recommendation is not to use markdown, but to use jsonschema as json2md, wetzel, markdown-to-json

so to pad it out with more bytes for no reason?

[mleku]

so to pad it out with more bytes for no reason?

"While Markdown fulfills these requirements, it has become incredibly flexible and has given rise to multiple "standards" due to numerous application-level variances. Nostr should consider devising its own Markdown style, similar to GitHub Flavored Markdown (GFM), to maintain consistency."

jsonschema is a much more well-known and popular and highly standardized format. Nostr sends and receives messages in json, why is the content not in jsonschema markup nostr?

yes but it's not human readable, that's why not

and github flavored json is almost universally known by humans

i was using github flavored json in 2016 on the steem blockchain forum, it's very stable and many implementations to turn it into rich text

[mleku]

come on,get serious you want normies who want to do italic and titles and hypertext links to learn how to write that????

[mleku]

it's just a bad pattern to force devs to use a richtext editor to type a text format that is simple for humans to learn

[xeruf]

I recommend considering orgdown - it is naturally extensible, well-standardized and more intuitive while very similar to markdown in principle: https://karl-voit.at/2017/09/23/orgmode-as-markup-only/ I would really prefer to avoid creating another proprietary Markup without proper reason.

[staab]

All of these syntaxes have too many features. Is there nothing standard that has a minimal feature set? All we really need are:

• Headings
• bold/italics
• UL/OL
• Code fencing (inline and block)

Aliased links would be nice, but there's inherently no really human-readable solution, because most links aren't human-readable, so it's probably best to leave them out. Tables aren't human-writable, so they should be excluded too.

[xeruf]

well you can just implement a subset of any suhc syntax, when it comes to such markdown and orgdown and even asciidoc are very similar

I would disagree on tables, they are mentioned in the blogpost I sent and simple tables are very much human-writable and can be quite handy

[mleku]

All of these syntaxes have too many features. Is there nothing standard that has a minimal feature set? All we really need are:

• Headings
• bold/italics
• UL/OL
• Code fencing (inline and block)

Aliased links would be nice, but there's inherently no really human-readable solution, because most links aren't human-readable, so it's probably best to leave them out. Tables aren't human-writable, so they should be excluded too.

maybe it is relevant that me, like maybe some other users here, spent a year or more using the Steem protocol forum, which by default had a minimal, github-flavored markdown in it

why do people want more complicated stuff than this?

you can add, easily, and transparently, indexes that show the outline of the headings, and honestly, tables are hell, and then people want more complicated things like text flow controls around images, embeds, and whatnot

feature creep is a real disease in computer software development, just stop it ok?