From c9d0bf09509d1e742b27cbc3a8659522ee5a9ea4 Mon Sep 17 00:00:00 2001 From: Jazz Turner-Baggs <473256+jazzz@users.noreply.github.com> Date: Mon, 22 Sep 2025 16:34:33 -0700 Subject: [PATCH 1/3] Added Chat --- standards/application/chat.md | 133 ++++++++++++++++++++++++++++++++++ 1 file changed, 133 insertions(+) create mode 100644 standards/application/chat.md diff --git a/standards/application/chat.md b/standards/application/chat.md new file mode 100644 index 0000000..2c6f216 --- /dev/null +++ b/standards/application/chat.md @@ -0,0 +1,133 @@ +--- +title: CHAT +name: A modular framework for defining chat protocols +category: Information +status: raw +tags: chat +editor: Jazz Alyxzander +contributors: +--- +# Abstract + +This specification defines a modular communication protocol framework for describing chat protocols. It introduces abstraction boundaries, and a component model for describing chat protocol functionality. + + +# Background / Rationale / Motivation + +Chat protocols specifications can be long and dense documents. To fully describe a chat protocol there are many layers and operations which are required to be documented. This includes payloads, message transport, encryption as well as user level features such as account registration, typing indicators, content formatting. + +With the vast amount of information required to maintain compatibility between applications - protocol documentation is either comprehensive which leads to large monolithic specifications or lacking the required details for interop between implementors. + +# Theory / Semantics + +This specification defines a abstract framework for building a chat protocol. Its purpose is to name the components, and define modular boundaries between components to promote reuse. The end result is that a chat protocol implementation can be described by listing its approach to 5 problem areas. + + +The chat protocol is be decomposed into 3 distinct phases. + +- **Discovery:** How does a Sender learn of other clients. +- **Initialization:** How does a Recipient learn a client wants to communicate with them. +- **Operation:** How do participants exchange content. + +and transport details are divided into: + +- **Delivery Service:** How are payloads are routed and delivered to a client. +- **Framing Strategy:** How are payloads encoded. + +Defining these 5 parameters allows for chat protocol implementations to be fully defined, which allows clients from different applications to exchange messages. + +## Abstract Transport + +### Delivery service + +The service or method that distributes payloads to clients is called abstractly called a `Delivery Service` or `DS`. + +- a DS MUST have a method for clients to subscribe to messages. +- a DS MAY NOT guarantee delivery of messages. +- a DS MAY NOT guarantee order of messages. + +How protocols are mapped to DS level concepts is to be defined by implementors. + +### Framing Strategy + +In this protocol framework, payloads from multiple protocols are potentially multiplexed over the same channel. This requires that clients are able to associate a given payload to a given instance of a protocol. + +A framing strategy should define a common payload type as well as a method to determine which state machine a receiving client must used to decode it. + + +## Protocol Components + +In order to exchange content clients must be able to learn of each others existence, gather the pre-requisite information/parameters and, remain synchronized over time. + +The lifecycle of a protocol instance is divided into three phases, which are described by a corresponding protocol. + +- **Discovery Phase:** Discovery Protocol +- **Initialization Phase:** Initialization Protocol +- **Operation Phase:** Conversation Protocol + +```mermaid +sequenceDiagram + participant D as ??? + participant S as Saro + participant R as Raya + + + Note over D,S: Discovery + D -->> S: + + Note over R,S: Initialization + S ->> R: Invite + + Note over R,S: Operation + + loop + par + R->> S: Send Message + and + S->> R: Send Message + end + end +``` + + + +### Discovery Protocol + +A discovery protocol defines how clients gather the prerequisite information to contact another client. + +The input requirements of the discovery protocol are not defined here, and largely determined by the desired user experience. + +The output requirements of the discovery protocol are very implementation specific, and will depend on the initialization protocol requirements and DS chosen by the implementation. The data provided by the discovery protocol and required by the initialization protocol is called the `IntroductionBundle`. + +- The discovery protocol MUST provide all data required for the initialization protocol. + +Note: There is no requirement that the Discovery protocol be a complicated nor interactive process. Hypothetically If all required values to construct a IntroductionBundle could be statically defined, that would be sufficient for this definition. + +### Initialization Protocol + +A initialization protocol specifies how two clients can initiate communication. The input to this process is the `IntroductionBundle` and the output is an established instance of a `Conversation` between the participants. + +The core of an initialization protocol is a defined location and procedure for receiving initial messages. + +Many chat protocols choose to define the initialization protocol within the conversation protocol. This tight coupling produces two negative artifacts. +- New conversation protocols must define and deploy there own initialization channels. Increasing overhead and adding complexity. +- New protocol upgrades then create partitions in the communication network, as older clients have no means of communicating with new clients. + +Separating channel initialization from conversation flow allows multiple conversations to reuse the same initialization channel. This reduces effort for new conversation protocols, and is especially valuable when upgrading existing ones. Being independent the initialization pathway can persist across conversation versions. Even if an older client cannot parse new message types, it can still recognize their presence, adding observability. + +### Conversation Protocol + +A conversation protocol defines how messages flow between participants, and subsequently determines the properties of that channel. + +- A Conversation protocol MUST define the payloads it uses and how to handle them. +- A Conversation protocol SHOULD outline the cryptographic properties provided +- A Conversation protocol SHOULD describe bidirectional communication. +- A Conversation protocol ... + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). + +## References + +A list of references. From e2d9b15eb190685689f5589ab1784a1199b3e60a Mon Sep 17 00:00:00 2001 From: Jazz Turner-Baggs <473256+jazzz@users.noreply.github.com> Date: Thu, 25 Sep 2025 09:39:14 -0700 Subject: [PATCH 2/3] rename to CHAT-FRAMEWORK --- standards/application/{chat.md => chat-framework.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename standards/application/{chat.md => chat-framework.md} (99%) diff --git a/standards/application/chat.md b/standards/application/chat-framework.md similarity index 99% rename from standards/application/chat.md rename to standards/application/chat-framework.md index 2c6f216..85420b2 100644 --- a/standards/application/chat.md +++ b/standards/application/chat-framework.md @@ -1,5 +1,5 @@ --- -title: CHAT +title: CHAT-FRAMEWORK name: A modular framework for defining chat protocols category: Information status: raw From 0775ad6e084dc260a2a096dda3f30e4018ccb36b Mon Sep 17 00:00:00 2001 From: Jazz Turner-Baggs <473256+jazzz@users.noreply.github.com> Date: Thu, 25 Sep 2025 12:53:10 -0700 Subject: [PATCH 3/3] add delivery address --- standards/application/chat-framework.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/standards/application/chat-framework.md b/standards/application/chat-framework.md index 85420b2..d8fda70 100644 --- a/standards/application/chat-framework.md +++ b/standards/application/chat-framework.md @@ -40,13 +40,15 @@ Defining these 5 parameters allows for chat protocol implementations to be fully ### Delivery service -The service or method that distributes payloads to clients is called abstractly called a `Delivery Service` or `DS`. +A Delivery Service (DS) is the service or method that distributes payloads to clients. A DS accepts payloads with a delivery_address and delivers them to all subscribers of that delivery_address. Protocols use delivery_addresses to establish delivery contracts between senders and recipients. The mapping of delivery_addresses to DS-level concepts is implementation-specific. -- a DS MUST have a method for clients to subscribe to messages. -- a DS MAY NOT guarantee delivery of messages. -- a DS MAY NOT guarantee order of messages. +#### Requirements + +- -A DS MUST provide a method for clients to subscribe to messages from a delivery_address +- Payloads sent to a delivery_address are delivered by a DS to all subscribers of that delivery_address +- A DS MAY NOT guarantee message delivery +- A DS MAY NOT guarantee message ordering -How protocols are mapped to DS level concepts is to be defined by implementors. ### Framing Strategy