Application developers use chat protocols to send payloads between clients. However not all payloads sent over a protocol are intended to be read by the end users. In normal operation a chat protocol needs to notify the chat clients of event changes in order to keep all clients synchronized. With a finite set of message types, its possible to explicitly label each type as "content" or "meta-message" and route the payload appropriately. In an evolving decentralized chat protocol, this is not alway possible. When a client receives a payload it does not understand, there exists an ambiguity of whether this message contains a payload intended for the application, or a protocol message type which it does not understand. This ambiguity makes versioning between clients difficult.
Furthermore as applications communicating with each other cannot be guaranteed to be compatible, its possible that applications can also receive messages and be uncertain as how to parse incoming messages.
Having a mechanism that removes the ambiguity of how to handle payloads intended for end users is beneficial for both clients and applications.
The presence of a ContentFrame removes ambiguity of who the handler of a given payload is, and its fields describe how to parse the attached payload. This decouples of the encoded data from the software that created it increasing protocol resilience.
A domain defines the authority which governs a set of content types. It cannot be assumed that all specifications covering content types reside in the same location or are governed by the same entity. By including the `domain` receiving application developers can determine where the definition of the type resides, regardless of where it originated.
- a domain MUST be a valid url.
- a domain SHOULD provide specifications for all of its defined types.
To reduce payload size, Domains are mapped to an integer `domain_id`. The mappings can be found [here](#appendix-a-domains)
A tag uniquely defines a type within a domain. After parsing the Domain and the tag application developers have all the data required to process the payload. Each domain is responsible for managing its tags and providing documentation to developers on how the corresponding types are used.
**domain_id:** This field contains an integer which identifies the domain of this type.
**tag:** This field contains an integer which identifies which type `bytes` contains
**bytes:** This field contains the encoded payload
## Implementation Suggestions (optional)
### Tags -> Specifications
If possible the integer tag values should be the same as the specification which defines the type used. While not necessary, using the specification id directly removes the requirement to maintain a separate mapping of tag -> specification.
### Fragmentation
This protocol allows for multiple competing definitions of similar content types. Having multiple definitions of a `TextMessage` or `Image` will increase fragmentation between applications. Where possible reusing existing types will reduce burden on app developers, and increase interoperability between apps.
Domains should focus on providing types unique to their service or usecase.
