From 05e73ad3c0f4de3561467dc02ebae8934df8e655 Mon Sep 17 00:00:00 2001 From: afiw Date: Sat, 28 Feb 2026 22:15:15 +0100 Subject: [PATCH 1/2] Submit RFC 0002 --- RFCs/rfc-0002.ms | 200 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 200 insertions(+) create mode 100644 RFCs/rfc-0002.ms diff --git a/RFCs/rfc-0002.ms b/RFCs/rfc-0002.ms new file mode 100644 index 0000000..30819e8 --- /dev/null +++ b/RFCs/rfc-0002.ms @@ -0,0 +1,200 @@ +\# This is a groff_ms(7) document. Render it with nroff -ms rfc-0002.ms | less. +.TL +MEOW RFC 0002: Text Formatting +.AU +afiw +.AI +MEOW Working Group +.DA last edited on \*[DY] +.nr PS 10 +.nr GROWPS 3 +.nr PSINCR 1.5p +.AB +This document describes a draft version of the text formatting language used by the MEOW messaging protocol. +.AE +.SH 1 +Status of this memo +.PP +This document is a draft and has not been adopted as part of the final MEOW specification. If adopted, it would +obsolete the +.CW Client-Text-Formatting.md +proposal. +.NH +Introduction +.PP +Instant messaging protocols often provide a simple language for text formatting. The most common format +used is a variant of Markdown. There are several problems with Markdown; it is underspecified and complex, +and its origin makes it more suited to outputting HTML documents as compared to messages, which are usually +short and unstructured. This document attempts to specify a simpler alternative to be used by MEOW clients. +.NH +Conventions used in this document +.PP +The term \*[Q]IETF RFC\*[U] followed by a number is to be interpreted as a reference to a RFC published by the +Internet Engineering Task Force, as opposed to a MEOW Working Group RFC. +.PP +The key words \*[Q]MUST\*[U], \*[Q]MUST NOT\*[U], \*[Q]REQUIRED\*[U], \*[Q]SHALL\*[U], \*[Q]SHALL NOT\*[U], +\*[Q]SHOULD\*[U], \*[Q]SHOULD NOT\*[U], \*[Q]RECOMMENDED\*[U], \*[Q]MAY\*[U], and \*[Q]OPTIONAL\*[U] in this +document are to be interpreted as described in IETF RFC 2119. +.NH +Encoding +.PP +MEOW clients and servers MUST transmit all message data in the Network UNICODE format as described by IETF RFC +5198. In addition, problematic UNICODE characters as defined by IETF RFC 9839 SHALL NOT be used. +.NH +Compatibility +.PP +MEOW clients SHOULD implement the following formatting directives, unless unable to do so due to limitations of +the platform (e.g. for command-line clients). If a client does not implement a formatting directive, it SHOULD +display the character sequences that would introduce or terminate it as ordinary characters. +.PP +MEOW clients SHOULD NOT implement any additional formatting directives not specified by this document, in order +to prevent ecosystem fragmentation and display incompatibilities between clients. +.NH +Basic text styles +.NH 2 +Italic text +.PP +A U+002A ASTERISK character, followed by a sequence of characters terminated with another asterisk SHOULD be +interpreted by rendering the characters between the delimiters with an italic typeface, if applicable. +.PP +Clients running in a terminal emulator SHOULD use the +.CW sitm +terminfo capability string to determine the correct escape sequence. +.NH 2 +Bold text +.PP +A U+0021 EXCLAMATION MARK character, followed by a sequence of characters terminated with another exclamation +mark SHOULD be interpreted by rendering the characters between the delimiters with a bold typeface, if +applicable. +.PP +Clients running in a terminal emulator SHOULD use the +.CW bold +terminfo capability string to determine the correct escape sequence. +.NH 3 +Rationale +.PP +Using two asterisks for bold text is more common in other markdown languages, but as asterisks are already used +for italic text, this would substantially complicate parsing. +.NH 2 +Underlined text +.PP +A U+005F LOW LINE character, followed by a sequence of characters terminated with another low line SHOULD +be interpreted by rendering the characters between the delimiters underlined, if applicable. +.PP +Clients running in a terminal emulator SHOULD use the +.CW smul +terminfo capability string to determine the correct escape sequence. +.NH 2 +Monospace text +.PP +A U+0060 GRAVE ACCENT character, followed by a sequence of characters terminated with another grave accent +SHOULD be interpreted by rendering the characters between the delimiters with a monospace typeface, if +applicable. Other formatting directives in the sequence SHOULD NOT be interpreted in any way. +.PP +Clients running in a terminal emulator MAY instead display the text with a changed background colour, or +without any special markup. +.NH +Advanced text styles +.NH 2 +LaTeX +.PP +A U+0024 DOLLAR SIGN character, followed by a sequence of characters terminated with another dollar sign MAY be +interpreted as LaTeX markup and rendered as such by the client. +.NH 2 +Colour +.PP +A U+0025 PERCENT SIGN character, followed by a three- or six-digit hexadecimal colour code, or an +implementation-defined symbolic colour name SHOULD be interpreted by changing the foreground colour of the +following text to the closest possible shade, until the closing sequence consisting of two closing percent signs +is encountered. Six-digit hexadecimal colour codes SHOULD be treated as sRGB web colours according to the W3C +HTML and CSS specifications, and three-digit ones SHOULD be treated as shorthands for equivalent six-digit +codes with every digit doubled. +.PP +The same holds for sequences beginning with the U+0026 AMPERSAND character and ending with two ampersands, +except that the background colour should be changed instead. +.PP +Implementations SHOULD support the following symbolic colour names if they support displaying coloured text at +all: black, red, green, yellow, blue, magenta, cyan, and white. +.NH +Links and references +.NH 2 +User mentions +.PP +Clients SHOULD interpret a U+0040 COMMERCIAL AT character, followed by a sequence of characters forming a +legal MEOW account name or identity name (to be defined in a future RFC) by notifying the user in some manner +if the mention corresponds to their account name or one of their identity names. Clients MAY display the +mention with an altered background or foreground colour, or apply other formatting changes. +.NH 2 +Channel references +.PP +Clients SHOULD interpret a U+0023 NUMBER SIGN character, followed by a sequence of characters forming a legal +MEOW channel name (to be defined in a future RFC) by navigating to the specified channel upon click or +interaction. Clients MAY display the reference with an altered background or foreground colour, or apply other +formatting changes. +.NH 2 +URI links +.PP +Clients MAY interpret a sequence constituting a valid URI as specified by IETF RFC 3986 by opening or +navigating to the specified resource upon click or interaction. Clients MAY display the reference with an +altered background or foreground colour, or apply other formatting changes. +.PP +URIs with the +.CW https:// +scheme SHOULD be supported, and SHOULD be visually distinguished. +.NH +Block formatting +.NH 2 +Block quotes +.PP +A U+003E GREATER-THAN SIGN as the first character of a line SHOULD be interpreted by formatting the content +of the line as an indented block quote, if applicable. Any UNICODE whitespace characters directly following it +SHOULD be interpreted, and multiple consecutive lines beginning with the character SHOULD be treated as a single +block. +.NH 2 +Unordered lists +.PP +A U+002B PLUS SIGN as the first character of a line SHOULD be displayed as a bullet point (possibly as U+2022 +BULLET), if applicable. Any UNICODE whitespace characters directly following it SHOULD be intrepreted, and +multiple consecutive lines beginning with the character MAY be visually grouped as a list. +.NH 2 +Ordered lists +.PP +A sequence of lines beginning with strictly increasing numbers followed by a U+002E FULL STOP character MAY be +visually grouped as a list by clients. The numbers themselves SHOULD NOT be changed. +.NH 3 +Rationale +.PP +Using asterisks for bullet points/unordered lists is more common in other markdown languages, but as asterisks +are already used for italic text, this would substantially complicate parsing. +.NH 2 +Code blocks +.PP +Three or more U+0060 GRAVE ACCENT characters at the beginning of a line should be interpreted as starting a +code block. A code block is terminated by an equal amount of grave accents on a line by itself, and should be +rendered with a monospace typeface, if applicable. Other formatting directives in the block SHOULD NOT be +interpreted in any way. +.PP +As per section +.B 5.4 , +clients running in a terminal emulator MAY instead display the text with a changed background colour, or +without any special markup. +.PP +The characters following the opening graves on the same line MAY be interpreted as a tag describing the +programming language of the code block. Clients MAY higlight syntax elements within the code block according to +the programming language tag. +.NH +The escape character +.PP +The U+005C REVERSE SOLIDUS character should be interpreted in the following way: +.IP \[bu] +When followed by a formatting character, that is a character that would have cause special formatting to be +applied, the function of the formatting character SHOULD BE suppressed and the character SHOULD BE displayed +normally, without the preceding reverse solidus; +.IP \[bu] +When followed by another reverse solidus character, a single reverse solidus SHOULD BE displayed as an ordinary +character; +.IP \[bu] +When followed by an ordinary character, that is a character that this document does not specify a special +formatting for, or a character indicating a formatting directive from this document that is unimplemented by +the client due to platform limitations, both the reverse solidus and the character SHOULD both be displayed +normally. From e5ab08cc6dc85b2a49c8817777154ec5f9f72393 Mon Sep 17 00:00:00 2001 From: afiw Date: Sun, 1 Mar 2026 00:24:39 +0100 Subject: [PATCH 2/2] Add and fix some stuff cause im a big dumy --- RFCs/rfc-0002.ms | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/RFCs/rfc-0002.ms b/RFCs/rfc-0002.ms index 30819e8..c7d9f24 100644 --- a/RFCs/rfc-0002.ms +++ b/RFCs/rfc-0002.ms @@ -93,6 +93,11 @@ applicable. Other formatting directives in the sequence SHOULD NOT be interprete .PP Clients running in a terminal emulator MAY instead display the text with a changed background colour, or without any special markup. +.NH 2 +Overstruck text +.PP +A U+007E TILDE character, followed by a sequence of characters terminated with another tilde SHOULD be +interpreted by rendering the characters between the delimiters overstruck, if applicable. .NH Advanced text styles .NH 2 @@ -115,6 +120,12 @@ except that the background colour should be changed instead. .PP Implementations SHOULD support the following symbolic colour names if they support displaying coloured text at all: black, red, green, yellow, blue, magenta, cyan, and white. +.NH 2 +Spoilers +.PP +A U+007C VERTICAL LINE character, followed by a sequence of characters terminated with another vertical line +SHOULD be interpreted by rendering the characters initially hidden, only revealing them when the user explicitly +interacts with the text area by e.g. clicking it or using a client command. .NH Links and references .NH 2 @@ -156,17 +167,17 @@ Unordered lists A U+002B PLUS SIGN as the first character of a line SHOULD be displayed as a bullet point (possibly as U+2022 BULLET), if applicable. Any UNICODE whitespace characters directly following it SHOULD be intrepreted, and multiple consecutive lines beginning with the character MAY be visually grouped as a list. -.NH 2 -Ordered lists -.PP -A sequence of lines beginning with strictly increasing numbers followed by a U+002E FULL STOP character MAY be -visually grouped as a list by clients. The numbers themselves SHOULD NOT be changed. .NH 3 Rationale .PP Using asterisks for bullet points/unordered lists is more common in other markdown languages, but as asterisks are already used for italic text, this would substantially complicate parsing. .NH 2 +Ordered lists +.PP +A sequence of lines beginning with strictly increasing numbers followed by a U+002E FULL STOP character MAY be +visually grouped as a list by clients. The numbers themselves SHOULD NOT be changed. +.NH 2 Code blocks .PP Three or more U+0060 GRAVE ACCENT characters at the beginning of a line should be interpreted as starting a