diff --git a/Client-Text-Formatting.md b/Client-Text-Formatting.md new file mode 100644 index 0000000..b6c9305 --- /dev/null +++ b/Client-Text-Formatting.md @@ -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. + diff --git a/RFCs/MEOW_RFC_0001.md b/RFCs/MEOW_RFC_0001.md deleted file mode 100644 index e872b45..0000000 --- a/RFCs/MEOW_RFC_0001.md +++ /dev/null @@ -1,73 +0,0 @@ -# MEOW protocol RFC 0001 - -Last updated 2026-02-25 - -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119. - -## Status - -RFC 0001 has not been adopted and SHOULD NOT be considered final, binding, or even that good of an idea. We gotta start somewhere though. - -## Abstract - -RFC 0001 describes a method of storing and sending messages, so that accounts (used for authentication and encryption) and alters / user infos (used for information like display names, profile pictures, pronouns, descriptions, etc) are decoupled, and stored separately on the homeserver. - -## Description - -For the purposes of this document, let "account" refer to the data structure used for authentication by the server, and let "alter" refer to a data structure, the details of which are beyond the scope of this RFC, containing cosmetic user data, such as display name, profile picture, pronouns, bio, accent color, or similar. - -RFC 0001 proposes that messages SHALL contain, as part of their data, both an account UUID and an alter UUID. Thus, a message object would look something similar to the following: - -``` -{ - "sender-account": "ACCOUNT-UUID-HERE", - "alter": "ALTER-UUID-HERE", - "message": {message payload data structure, beyond the scope of this RFC} -} -``` - -This entire message object MUST then be end-to-end encrypted, rendering it only readable to those to whom it is sent. In addition, since the alter UUID is encrypted alongside the message, the alter is only visible to those to whom the message is sent. - -Alters MUST be stored on the same homeserver as the accounts they belong to. In addition, homeservers MUST NOT expose an API allowing for fetching all alters from an account, except by the account that owns them; all requests for alters by accounts other than those the alter belongs to MUST be by UUID. Thus, the users file on the homeserver might look something like this, though with specifics not yet finalized: - -``` -{ - "users": [ - { - "publickey": "JUNE-PUBLICKEY-HERE", - "uuid": "JUNE-UUID-HERE", - "rooms": [ - "groupchat-summer", - "groupchat-winter" - ] - "alters" : [ - { - "uuid": "ALTER-A-UUID-HERE", - "name": "june", - "pronouns": "she/her" - }, - { - "uuid": "ALTER-B-UUID-HERE", - "name": "july", - "pronouns": "it/its" - }, - { - "uuid": "ALTER-C-UUID-HERE", - "name": "november", - "pronouns": "they/them" - } - ] - } - " -} -``` - -To see what this would entail, we consider what various parties can see in a hypothetical scenario: assume the JUNE account (the example above) is in 2 rooms: groupchat-summer and groupchat-winter. Furthermore, assume both groupchats are hosted on separate homeservers, and the JUNE account is on a third. JUNE sends a message to groupchat-summer as "july", and a second as "june". JUNE then sends a message to groupchat-winter as "november". - -All of JUNE's messages to groupchat-summer and groupchat-winter MUST be end-to-end encrypted, so neither the message content nor the alter used are exposed to either of those homeservers. The other members of groupchat-summer can decrypt JUNE's messages, which provides them with the UUIDs for the alters "june" and "july", allowing them to fetch the corresponding details from JUNE's homeserver (and, assuming a competently-designed client, cache those details for future messages). However, as long as JUNE does not send a message as "november" to groupchat-summer, the members will not be able to get the UUID of, or even discern the existence of, the "november" alter. Similarly, the members of groupchat-winter will be able to decrypt JUNE's messages and subsequently fetch the "november" alter, but will not be able to fetch "july" or "june" since they will not have the necessary UUID. - -Note that, while secure from outsiders, a member of groupchat-summer could share the UUID of "june" or "july" with a member of groupchat-winter, allowing them to discern its existence. The author of this document deems such a possibility a non-issue; it exposes the same information as a screenshot of groupchat-summer, albeit with the possibility of confirmation via a request to JUNE's homeserver. - ---- - -by june@linuxpost.ing