magic-wormhole
Try to reword Dilation specification
At the moment it is written more as the documentation of the Python implementation. In the end, we want it to be a standalone document that helps others implement that protocol too, without having to know any of the Python internals or Twisted.
Thanks for the review
I still see benefits in keeping layers distinct, or at least describing them that way. […] We don't have to strictly follow what's already there, but some separation of concerns is a big benefit I think.
I don't like the concept of "layer" because to me it invokes feeling of an "OSI layers" stack, which is only true for parts of it. I'd rather think of them as interdependent components, and treat them as such. But you are right, the new wording could make the separation a bit more clear again.
One thing to note is that sometimes the boundaries are a bit fuzzy: For example while Python has L5 stacked on top of L4, one could also write the code that mostly does both at once, but delegates parts of it to a "subchannel manager". (Basically the reverse from what Python does.)
Have you read the latest draft of the python specification? Also it would be good to link that in this document.
Not really no, these changes here are mostly a rebase from my work in last autumn. I think it has changes over there that I should incorporate here? (If possible, I'd like to delegate that too to a future PR)
Yes, they're like the OSI stack: a "higher layer" can depend on a lower one, but NOT vice-versa. This is a good thing.
So they're not "inter"-dependent. It's fine if you want to assign different names, I suppose, but for network protocol implementers the OSI stack is very familiar and talking about "layers" is pretty common in lots of Internet protocols.
It also lets you forget / compartmentalize complexity: I can forget about framing, encryption, ACKs, re-sends, etc etc at the higher layers and just think about the logical flow of in-order messages. It also helps with state-machine diagrams and separation.
