Conversation
informational/chatdefs.md
Outdated
|
|
||
| ### 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.
informational/chatdefs.md
Outdated
|
|
||
| **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".
informational/chatdefs.md
Outdated
|
|
||
| **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.
|
|
||
| ## Definitions | ||
|
|
||
| ### Accounts + Identity |
There was a problem hiding this comment.
Accounts and Identity have yet to be defined for chat Protocols.
The empty heading was a warning that this work has not been completed. Happy to remove
There was a problem hiding this comment.
I guess we can add it back later 👍
|
|
||
| **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.
| **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 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. |
| **Content**: The data that is intended for end-users or applications - this includes text, images and other user valued data. These messages originate from the application, and are ultimately delivered to other applications. | ||
|
|
||
| **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.
I think it would be nice to describe how Content/Frame/Payload relate to each other
|
|
||
| **Content**: The data that is intended for end-users or applications - this includes text, images and other user valued data. These messages originate from the application, and are ultimately delivered to other applications. | ||
|
|
||
| **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. |
There was a problem hiding this comment.
What's the difference between Frame and Payload? Is it encryption? Or just the context is the difference, like when we talk about Chat protocol - it's Frames, when we talk about delivery service, it's Payload?
There was a problem hiding this comment.
Chat protocol - it's Frames, when we talk about delivery service, it's Payload?
Correct. Terms like messages and payloads are difficult to use as theres always so much ambiguity over what it means or what layer that data corresponds to.
This division identifies which data Protocols have access too, and what is treated as a binary blob.
Content: Data readable by Applications, Treated as a blob by chat
Frames: Data readable by Chat Protocols
Payloads: The rest of the data, Treated as a blob by chat.
| **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. | |
| **Frame**: Frames are message types defined by chat protocols to provide functionality - they are how clients exchange information with each other and coordinate state. Once encoded into their binary representation for transport, frames become Payloads as the data is no longer usable |
| - **Roles**: Defined entity types that determine how a participant behaves within a communication protocol. | ||
| - **Message Types**: Classifications and categories of protocol messages | ||
| - **Transports**: Abstract methods of transmitting payloads | ||
|
|
There was a problem hiding this comment.
| -**Software Entities**: Distinct software-defined actors or components that participate in the operation of ChatProtocols | |
|
|
||
| **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?
|
|
||
| Other specific message types include: | ||
|
|
||
| **Content Type**: The structured format of content. These data structures represent specific encodings of Text, Image, Audio data. |
There was a problem hiding this comment.
Content Type: The structured format of content.
That reads a bit oddly to me. I usually think of Content Type as a label or classification, not the data structure itself.
| **Content Type**: The structured format of content. These data structures represent specific encodings of Text, Image, Audio data. | |
| **Content Type**: A classification that identifies the kind of Content being transmitted (e.g., Text, Image, Audio). Content Types determine how the associated data is structured and interpreted by applications. |
Then I am not sure whether it fits under "Other specific message types include".
There was a problem hiding this comment.
Very open to changing the term. Suggestions welcome.
I'm specifically looking for a way to refer to the set of data-structures which store Content and associated metadata.
E.g HostedImage{url: ... , image_format: ... , alt_text: .... , blurhash: ...} this data is not required for transportation, however clients need to agree on these datatypes to support interop.
|
|
||
| **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. |
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.