Add definition for plain text

10.md

@@ -53,6 +53,34 @@ When replying to a text event E the reply event's "p" tags should contain all of
 Example:  Given a text event authored by `a1` with "p" tags [`p1`, `p2`, `p3`] then the "p" tags of the reply should be [`a1`, `p1`, `p2`, `p3`]
 in no particular order.
 
+## Plain text
+
+"Plain text" content is distinguished from content that requires parsing in order to be human-readable. Plain text MAY have some light formatting (as defined below), as long as it can be naturally read by humans as written. Client MAY parse and display notes to improve the aesthetic of displayed content.
+
+The litmus test for formatting _implemented by clients_ is whether such syntax would naturally be used by non-technical users with no expectation of parsing or rendering. Users themselves MAY include any formatting they choose, but formatting implemented by clients MUST be limited to the following:
+
+- A `>` at the beginning of a line MAY be used to indicate quotations
+- A `#` at the beginning of a word MAY be used to indicate a topic and SHOULD have a corresponding `t` tag
+- A `$` at the beginning of a word MAY be used to indicate a stock ticker
+- Matched `*` characters within a single line MAY be used to indicate emphasis
+- Matched `:` characters around a single word MAY be used to indicate emojis (see [NIP 30](./30.md))
+- Single-backticks with no language tag MAY be used for inline code blocks
+- Triple-backticks with no language tag MAY be used for multi-line code blocks
+- Unordered lists MUST be one level deep, and SHOULD use the `-` character
+- Ordered lists MUST be one level deep, and MUST be sequentially numbered
+
+Note that code blocks are only admissible because they are useful for opting-out of any default parsing clients may do.
+
+The biggest departure of this spec from markdown is the omission of special syntax for links. The reason for this is that markdown's link syntax is not idiomatic - in other words, humans do not generally use markdown's link syntax to denote a link. However, links are an essential part of internet content, and so for the purposes of this spec, URLs less than 300 characters may be considered "human-readable". Note that this specifically excludes embedded base64 image data and `nembed`s.
+
+Examples of links:
+
+- [NIP 73](./73.md) identifiers
+- Nostr entities with or without a `nostr:` prefix
+- Lightning invoices (`lnbc`), wallet uris (`lnurl1`), offers (`lno1`), cashu tokens, etc.
+
+Clients MAY render urls as cards, images, audio players, etc, but SHOULD render domain names without schema or path (e.g. `nytimes.com`) as text.
+
 ## Deprecated Positional "e" tags
 
 This scheme is not in common use anymore and is here just to keep backward compatibility with older events on the network. 
@@ -81,4 +109,4 @@ Where:
 
  * Many "e" tags: `["e", <root-id>]` `["e", <mention-id>]`, ..., `["e", <reply-id>]`<br>
 There may be any number of `<mention-ids>`.  These are the ids of events which may, or may not be in the reply chain.
-They are citing from this event.  `root-id` and `reply-id` are as above.
+They are citing from this event.  `root-id` and `reply-id` are as above.

22.md

@@ -8,7 +8,7 @@ Comment
 
 A comment is a threading note always scoped to a root event or an [`I`-tag](73.md).
 
-It uses `kind:1111` with plaintext `.content` (no HTML, Markdown, or other formatting).
+It uses `kind:1111` with [plaintext](./10.md#plain-text) `.content` (no HTML, Markdown, or other formatting).
 
 Comments MUST point to the root scope using uppercase tag names (e.g. `K`, `E`, `A` or `I`)
 and MUST point to the parent item with lowercase ones (e.g. `k`, `e`, `a` or `i`).