diff --git a/RFCs/rfc-0002.ms b/RFCs/rfc-0002.ms
deleted file mode 100644
index c7d9f24..0000000
--- a/RFCs/rfc-0002.ms
+++ /dev/null
@@ -1,211 +0,0 @@
-\# 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 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
-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 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
-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 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
-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.