Closed oskarth closed 4 years ago
adambabik
commented
5 years ago It's a great idea! As long as I tried to collect as many things as possible, I agree that we need a methodological approach to move the current protocol spec from a draft to accepted state and it looks like a great plan!
adambabik
commented
5 years ago A few comments/suggestions after spending more time with this issue:
oskarth
commented
5 years ago I think we need more specific acceptance criteria in each topic; currently acceptance criteria are copied from this issue.
I think a lot of these have similar acceptance criteria tbh, but we can always drill down into specific properties it should cover. I made an example of this here https://github.com/status-im/specs/issues/12
Ack on the protocol overview one, changed to your suggested acceptance criteria.
"Initial Trust Establishment Specification" -- I am not sure if this should be a separate document. I don't see much content being in there and most of the things will be discussed in the the Protocol Overview.
Disagree, and this reflects our lack of thinking about this. See issue for a plethora of aspects it should cover that we aren't right now. It also extends beyond human messaging per se. That said, I agree it might not be the first priority to flesh out in detail, given current prios.
It's a bit unclear what kind of topics should be described in each "subspec". This should be clarified before submitting PRs.
Happy to talk about this in detail, but a guiding principle to a first approximation is to ensure each own spec covers the properties listed in https://discuss.status.im/t/hello-protocol-progress-since-prague/736 - especially security/privacy ones.
A separate documen how we handle historic messages should be created. This is one of the most problematic parts so far when implementing a client.
Hmm, maybe. I think this will be addressed in the coming data sync spec. I'd be fine if this was a "special" section in protocol overview, but maybe it makes sense to abstract it out. While vital, involving a lot of work and causing a lot of headache, it isn't clear to me that this provides any specific meaningful guarantees, especially without data sync semantics. I can see the argument for having a separate mailserver spec in general, but is it worth the effort to polish? (EDIT: I realize some of these aspect would fit better under conversational security, it's a bit tightly coupled right now).
"Initial Conversational Security Specification" -- I understand that we will mostly talk about PFS here or about Whisper as well? When PFS is disabled, encryption is on Whisper. It seems like some topics will expand between this one and "Initial Transport Privacy through Whisper Specification".
PFS is one of several properties you'd want at conversational security layer. Others are things like: Confidentiality, Integrity, Authentication, Backward Secrecy, Anonymity Preserving, Out-of-Order Resilient, Dropped Message Resilient, Asynchronicity, Multi-Device Support, Group chat.
Encryption is on Whisper as well, which is Whisper acting as dual-purpose (probably a bad thing?). This is a caveat we can mention in both of these. I guess it's looking at Whisper from two different angles, with different jobs/properties in mind.
In the acceptance criteria, we have a note that layers should be orthogonal but I don't see that being reflected in these "subspecs". Is that ok? Do we want each layer to have its own document or we aim for describing layers orthogonally but not necessarily keep this "1 layer = 1 doc" rule.
To the extent they aren't orthogonal, it probably shows our poor protocol design in the past. It is also worth noting that the contents of these specs right now is largely a sloppy copy paste to get things going, it doesn't at all reflect the desired final structure. Each layer should have its own document, so they can be reasoned about in isolation and be swapped out in the future. Caveats etc still apply and can be documented.
adambabik
commented
5 years ago Disagree, and this reflects our lack of thinking about this. See issue for a plethora of aspects it should cover that we aren't right now. It also extends beyond human messaging per se.
Right but we are documenting the current protocol now and many aspects that we didn't cover are part of the design of the next protocol. Or you would like to mention these uncovered aspects here just to point out they are missing?
Hmm, maybe. I think this will be addressed in the coming data sync spec. I'd be fine if this was a "special" section in protocol overview, but maybe it makes sense to abstract it out. While vital, involving a lot of work and causing a lot of headache, it isn't clear to me that this provides any specific meaningful guarantees, especially without data sync semantics.
That's right but my understanding was that we want to describe what we currently have and in the mean time work on the design of the future protocol as a separate document.
Generally, with these comments and questions, my goal was to narrow the scope and put very specific requirements for each subtasks so that we can close the phase of documenting the current protocol ASAP and move to collecting requirements and designing the new version of the protocol. I got an impression that in these related issues we want to cover many topics that we weren't aware in the past but we are now. In my opinion, these should be separate efforts. (side note: we have many people who know the current protocol and can contribute but if the requirements will be to cover that plus many other topics few people understand for the time being, that might be discouraging).
oskarth
commented
5 years ago @adambabik what's your thinking re us finishing up this one? I realize we expanded scope a bit and that was my fault, perhaps we can ensure a more narrow scope and get these specifications into a somewhat done state? WDYT?
oskarth
commented
5 years ago @adambabik In light of recent work and reducing scope, what do you think we should do with this and associated issues?
oskarth
commented
4 years ago Largely done; closing as no longer relevant. If we want to do further QA of specs, I suggest we do this through more specific issues.
Umbrella issue to capture documenting current protocol specification effort. Should pass the following litmus tests:
Additionally, we should have a process in place that's:
In terms of who will judge, it'll be 2-3 main groups initially:
Getting validation and evaluation outside of Status is desirable, but out of scope of this issue.
I cut up the amazing work @adambabik did into a few pieces as an example of how I think we should look at it. This is also how other protocols and papers roughly structure things, as far as I can tell. Each of the items above applies to each of these.
Finishing these pieces amounts to getting the first set of SIPs into an accepted state.