Chat Definitions#80
Conversation
|
|
||
| ### Software Entities | ||
|
|
||
| **Client**: Software that implements a chat protocol. It is responsible for establishing and maintaining communication with the underlying network, performing protocol operations (e.g., encryption, key management, frame generation), and exposing an interface for higher-level software. A Client serves as the technical component that provides messaging capabilities to Applications. |
There was a problem hiding this comment.
The term client seems not clear, maybe just use chat-sdk implementation here.
There was a problem hiding this comment.
ChatSDK Implementation is a different concept. The Implementation is a library, the Client is an "Component" of an architecture. I'll reword the definition to reflect that.
|
|
||
| **Payload**: The encoded bytes as produced by a chat protocol. The term `message` is avoided due to conflicts with other layers. | ||
|
|
||
| **Frame**: A data structure which is required to implement a chat protocol. Frames are used to disambiguate the objects defined by chat protocols from transport 'messages' and application `content`. |
There was a problem hiding this comment.
Would be good to have some examples about Frame, and how it connects between content and payload, not sure if there is an easy definition of data structure for this.
There was a problem hiding this comment.
Absolutely - Examples though are provided in the conversation specifications. This definitions spec is intended to only define the terms used to provide consistent vocabulary. Frames definitions are arbitrary, and defined by their use case. The different in the 3 terms is the intent and purpose of the "Message".
|
|
||
| **Delivery Acknowledgement**: A notification from a receiving client to sender that their message was successfully received. While similar to a read-receipt delivery acknowledgements differ in that the acknowledgement originates based on the client, where read-receipts are fired when they are displayed to a user. | ||
|
|
||
| **Invite**: An protocol message from one client to another to establish a communication channel. Invites notify a client that someone wants to communicate with them, and provides the required information to do so. |
There was a problem hiding this comment.
Maybe use direct message or similar for this term, and how invite fit in this scenario and roles like inviter invitee. We can also link to the detail spec here.
Co-authored-by: kaichao <kaichaosuna@gmail.com>
Co-authored-by: kaichao <kaichaosuna@gmail.com>
igor-sirotin
left a comment
igor-sirotin
left a comment
There was a problem hiding this comment.
Nice!
Mostly dust comments, but I'd like to clarify Frame vs Payload before approving.
|
|
||
| **Frame**: The data generated by a chat protocol. Frames are messages used by protocols to provide functionality - they are how clients exchange information with each other and coordinate state. | ||
|
|
||
| **Payload**: The encoded data or data structures used by lower layer protocols. This includes the encoded bytes passed to a delivery service or subsequent layers. Payloads are usually associated with the delivery process, which is not defined by chat protocols. |
There was a problem hiding this comment.
What does "encoded data" refer to here - an encoded Frame? And what are "lower layer protocols"? Should the chat protocol know about or mention them? Isn't the delivery service the only abstraction we should care about at this level?
|
|
||
| **Content Type**: The structured format of content. These data structures represent specific encodings of Text, Image, Audio data. | ||
|
|
||
| **Delivery Acknowledgement**: A notification from a receiving client to sender that their message was successfully received. While similar to a read-receipt delivery acknowledgements differ in that the acknowledgement originates based on the client, where read-receipts are fired when they are displayed to a user. |
There was a problem hiding this comment.
Invite explicitly specifies that it is a frame. Should the delivery ack also be a frame?
| **Delivery Acknowledgement**: A notification from a receiving client to sender that their message was successfully received. While similar to a read-receipt delivery acknowledgements differ in that the acknowledgement originates based on the client, where read-receipts are fired when they are displayed to a user. | |
| **Delivery Acknowledgement**: A notification frame from a receiving client to sender that their message was successfully received. While similar to a read-receipt delivery acknowledgements differ in that the acknowledgement originates based on the client, where read-receipts are fired when they are displayed to a user. |
There was a problem hiding this comment.
An Invite requires a dedicated frame to be a sent which contains all the required information.
A delivery acknowledgement does not. It is a state change - rather than a "message" type.
Is this any better? Suggestions @osmaczko ?
| **Delivery Acknowledgement**: A notification from a receiving client to sender that their message was successfully received. While similar to a read-receipt delivery acknowledgements differ in that the acknowledgement originates based on the client, where read-receipts are fired when they are displayed to a user. | |
| **Delivery Acknowledgement**: A confirmation emitted to an application that a sent message has been successfully received. While similar to a read-receipt delivery acknowledgements differ in that the acknowledgement originates based on the client, where read-receipts are fired when they are displayed to a user. |
Co-authored-by: Igor Sirotin <igor.sirotin.1012@gmail.com>
4 participants
This PR Introduces an Informational spec that defines Chat related terms.
These terms defined here are used across the Chat context, and is referenced by chat related specs.