forked from linuxposting/MEOW-Spec
Compare commits
2 commits
main
...
clientspec
| Author | SHA1 | Date | |
|---|---|---|---|
|
fe057c4b05 | ||
|
|
72eac36477 |
2 changed files with 40 additions and 211 deletions
40
Client-Text-Formatting.md
Normal file
40
Client-Text-Formatting.md
Normal file
|
|
@ -0,0 +1,40 @@
|
|||
# Client Message Formatting Spec
|
||||
|
||||
## BBCode transport layer
|
||||
|
||||
A message may contain formatting to allow fun text shenanegans. The text will follow a BBCode format, using tags in square brackets. When a message is sent or recieved, it must either be in BBCode format or plain text format.
|
||||
|
||||
If a message begins with `[bb]` and ends with `[/bb]`, those tags should be removed from the ends, and the remaining message should be given to a BBCode parser. The BBCode Parser should support all normal tags (italic, bold, colors, etc.), as well as some custom ones defined below.
|
||||
|
||||
If a message does not begin with `[bb]` and end with `[/bb]`, the message is assumed to be plaintext, and is desplayed in its raw form.
|
||||
|
||||
|
||||
### Custom Tags
|
||||
|
||||
- The `LaTeX` tag formats its contents using a TeX or LaTeX parser.
|
||||
Parameters: The one parameter this tag accepts is the mode of the LaTeX.
|
||||
This can be inline or block. You may shorten these to `i` and `b` if you'd like.
|
||||
If neither is specified, the client will choose one, assuming that LaTeX means block and all aliases mean inline.
|
||||
Examples:
|
||||
- `[LaTeX=i]e^{i\pi}[/LaTeX]` -> The contents formatted as inline LaTeX
|
||||
- `[LaTeX]\frac{\biggr B^{lo}}{ck}[/LaTeX]` -> The contents formatted as a block of LaTeX
|
||||
|
||||
Aliases: `TeX`, `math`
|
||||
- The `sp` tag makes text spoilered (hidden till interacted with).
|
||||
Example: `[sp]hidden[/sp]` -> a box you can interact with --(interaction)--> "hidden"
|
||||
Aliases: `sp`, `h`, `hidden`, `spoiler`
|
||||
- The `icode` tag is equivalent to the `code` tag, except for being displayed inline. Essentially, this is the equivalent of Markdown's single and double backtick formatters.
|
||||
Parameters: The one parameter this tag accepts is optionally the language the code is in.
|
||||
Example: `[code=ruby]puts "Hello, world!"[/code]`
|
||||
|
||||
### Other BBCode implementation notes
|
||||
|
||||
- All `img` and other file-related tags should point to server files, and instead of specifying a filename, should instead specify the file to fetch from the server (i.e. `[img]server.example.com:TXlJbWFnZUlELnBuZwo[/img]`)
|
||||
- Please be sure to escape any square brackets (`[` and `]`) that are not tags. The most important places to do so are within the `LaTeX` tag and the `code`/`icode` tags.
|
||||
|
||||
## Client message writing
|
||||
|
||||
When a user writes a message within the client, the client may be configured to accept whichever markup or formatting language it chooses from the user (i.e. plaintext, HTML, (La)TeX, markdown, etc.). Whatever is chosen, however, must be translated into either plaintext or BBCode within the client's codebase before being sent as a message. Clients that send messages in other formats will be marked as noncomplient.
|
||||
|
||||
It is reccomended to allow the user to write messages in both markdown and bbcode, though neither are required.
|
||||
|
||||
211
RFCs/rfc-0002.ms
211
RFCs/rfc-0002.ms
|
|
@ -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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue