Conversation
igor-sirotin
left a comment
igor-sirotin
left a comment
There was a problem hiding this comment.
Just dust for now, will leave actual comments next part.
Co-authored-by: Igor Sirotin <igor.sirotin.1012@gmail.com>
Co-authored-by: Igor Sirotin <igor.sirotin.1012@gmail.com>
Co-authored-by: Igor Sirotin <igor.sirotin.1012@gmail.com>
Co-authored-by: Igor Sirotin <igor.sirotin.1012@gmail.com>
Co-authored-by: Igor Sirotin <igor.sirotin.1012@gmail.com>
Co-authored-by: Igor Sirotin <igor.sirotin.1012@gmail.com>
|
|
||
| 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. | ||
|
|
||
| #### Requirements |
There was a problem hiding this comment.
The DS requirements as stated are quite minimal, that's fine for an abstract framework. However, it may be worth considering whether the following aspects should be mentioned:
- Rate-limiting
- Message size constraints
- Offline message retrieval
igor-sirotin
left a comment
igor-sirotin
left a comment
There was a problem hiding this comment.
Thanks! I'm happy with it as it is, but left some minor comments where I think it could be improved
|
|
||
| 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. |
There was a problem hiding this comment.
Either <...> or <...>. Which way are we choosing? 😄
The paragraph finishes here, but it sounds like our choice/solution is missing
There was a problem hiding this comment.
This is a great feedback point.
I was following the paradigm that "Background" describes the problem, "Theory" outlines the proposed solution. Clearly the Problem/Solution relationship is not clear.
I'll rework it in another PR
| - A Conversation protocol SHOULD describe bidirectional communication. | ||
| - A Conversation protocol ... | ||
|
|
||
| ## Copyright |
There was a problem hiding this comment.
| ## Copyright | |
| # Copyright |
There was a problem hiding this comment.
This is from the Logos-Messaging Specs template. Suggest you push a PR there if we are suggesting a change.
https://raw.githubusercontent.com/logos-messaging/specs/refs/heads/master/template.md
|
|
||
| Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). | ||
|
|
||
| ## References |
There was a problem hiding this comment.
| ## References | |
| # References |
| The chat protocol is 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 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. |
There was a problem hiding this comment.
What confuses me here is how we juggle with these terms to describe the same thing: components, phases, problem areas, parameters. I'm not sure how would I re-write this. I still get the content, it just feels a bit bumpy while reading.
There was a problem hiding this comment.
specs/standards/application/chat-framework.md
Lines 64 to 69 in 21af11f
Here we say "phases of protocol lifecycle", this makes more sense to me than "phases of protocol".
There was a problem hiding this comment.
Absolutely. Let me think it over.
3 participants
This PR introduces a specification which describes a modular framework for describing Chat protocols.
This provides context on where chat specifications fit in the larger picture, while providing a template for implementation specific specifications. The component model introduced is used to define the boundaries of the other chat protocols and describe how they integrate.