TLDR: wanna sit down during hackathon and decide on a plan for how to give the chat a solid, open protocol base to stand on, and a culture to go with that.
It has repeatedly been happening that our protocol for chat comes under fire from different angles:
- not flexible enough to add features in without breaking compatibility
- not documented and transparent enough to be re-implemented externally
- not important enough culturally to care about
At the same time, we have goals and principles of status being:
- an open system that others can participate in
- a platform that others feel comfortable implementing their stuff in
- a pioneer in secure messaging and chat/ethereum integration
As such, I’d like to propose that we form a Protocol Engineering Swarm that focuses on the protocol as a separate entity from our code, for several reasons:
- culturally, it will focus responsibility and accountability for keeping the protocol stable, and give recognition for the value that this brings
- developing an open protocol carries different trade-offs than writing code
- you cannot refactor at will
- you don’t control the release process / lead times are bigger
- the cost of of introducing incompatible changes is high - downstream projects are affected
- others depend on the stability of your work, much like standardized API
- keeping the protocol in the code makes it difficult to work with
- it’s hidden in a mess of other responsibilities
- it gets approach with the same local mindset that code is generally approached with
- anyone else that wants implement it will have a hard time finding it
A lot of great brainstorming has already been going on: in the #status-protocol channel, in principles marathon discussions, while implementing PFS and group chat and in this hackmd that @igor just shared with me - we concluded that we should also bring it up here to here to ensure visibility - join these discussions and return to discuss with any long-form opinions or add to the brainstorming docs being written!
As far as concrete plans go, I would suggest that we get together in Prague, for example on Saturday or Sunday and hack together a swarm idea that will set the bar for what we want to achieve with this group. I’ll be around for sure to help with the typing.
Before meeting up there, I would also encourage people to study other beautiful protocols in our vicinity, such as Briar, Tox, SSB and a recent additions such as Dispersy, Origin and Riot - they’re all part of the Secure Messaging Study Compendium. One thing of note is how these protocols often layer responsibilities and features, so that each can be developed and analyzed in isolation (akin to the TCP stack!). This is the kind of depth that I feel is needed to help us solve many of the thorny reliability and security issues in a principled way - it will also help us separate display and UX features which benefit from fast iteration from the underlying fundamental layers.
Other than that, I’ll also be working with @j12b et al to ensure that skilled distributed systems / protocol engineers make their way into our future CC talent pool!
