As the ChatSDK begins to take shape, its worth talking about a macro level framework for building a communication SDK.
Divide and Conquer
Splitting the chat protocol into small, reusable communication patterns has numerous benefits and helps avoid the common pitfalls of previous decentralized messaging protocols:
- Difficult upgrade paths for developers
- Large, complex and interconnected specifications which are hard to understand.
- High complexity which increases difficulty for new contributors.
By building the ChatSDK around a framework that encourages feature decomposition, we gain reusable templates for contributors, built-in upgrade paths, and clear separation of concerns.
Conversations as Micro-Protocols
In many communication protocols conversations are defined as the instance of the chat protocol with a defined set of participants. This doesn’t fully describe the communication channel, and leads to a coupling of conversations and SDK version.
Instead the ChatSDK consist of a set of a micro protocols, which are self-describing - That is a Conversation consists of it’s participants and the ConversationType.
A ConversationType is a Specification and fully describes everything required to pass messages between a set of participants:
- Initiations - What is needed to create a new conversation
- Membership - Who, how many and what is the associated rules pertaining to participants.
- Protocol Types - What information and payloads are needed facilitate communication.
- Payload Generation - How are messages encrypted, what fanout policy is used, etc.
- Payload Discovery - How are content topics used, where to clients find messages?
- Security + Privacy - What security properties does this communication pathway have.
The “ChatProtocol” is then defined as suite of Conversation micro-protocols each defining a method to create streams of messages between a group of participants. E.g PrivateChats, GroupChats, Communities, Broadcasts, etc.
A client is free to have different conversations each with a completely different rulesets or behaviours.
Tone setting
The first impact here is that every pathway must be defined by a specification. This may be seen a “given” or expected - however the ambiguity is removed. The conversationType is a specification and the logic for parsing messages lives there. There must always be a canonical reference for how to handle a conversation of a given type.
Upgrade Proofing
Protocol revisions have been difficult in decentralized messaging, due to coordinating state between clients/installations - especially when considering interoperation of clients from different developers. This approach takes an opinionated stance - Breaking/non compatible changes are considered a new protocol/conversation type.
Allowing different conversation types makes upgrades easier as participants can upgrade individual conversations rather than upgrading at the client level. This extra granularity embraces a more decentralized approach and prepares for the inevitable protocol upgrades and breaking changes. The ChatSDK has responsibility to make the process of updating participants to a new conversation type as easy as possible for developers, rather than pushing these problems to the future. By planning for change now, the ChatSDK can minimize pain and friction later.
Smaller is Better
As each conversation is treated as its own pathway, the specifications can be smaller and more focused. A root specification will define common infrastructure such Account Registration and where clients will listen for conversation invites. By separating account infrastructure from the conversation definition creating new conversationTypes will be easier and more streamlined, enabling the community to extend the ChatSDK to meet their needs, without having to understand impacts to the larger system.
Moving Forward
The change compared to existing protocols is not radical. However this approach lays-out a common framework for future work. More importantly a conversation based approach optimizes for the focuses of the project.
- It scales well for fast development.
- Provides a template for how contributors can extend and add features
- Tackles “versioning” and upgrades headon, rather than punting until later
- and Establishes the importance of a Specification driven development cycle.