[noise] expected length of messages during handshake

[David Wong]

> So we have more work to do, but as protocol designers I think we
> should be focusing on extension documents and uses of Noise, rather
> than thinking we can make the core spec and protocol serve all use
> cases in itself.
>

I understand your point, thanks for spending the time to answer :)

So, I have implemented a library to do some Noise_** patterns
transparently for the application. I had to add a 2-byte length field
to make it work, as well as some signature code to make X/I pattern
work. The changes were extremely minimal, but it works. Developers
should be able to choose what pattern they want to use (good
documentation should provide guidance) and have the thing run on both
their clients and servers. At the moment, there is only one such
implementation though, and in Golang. It makes it really hard for
developers to have a plug-and-play protocol they can use. Most
libraries out there seem to implement the foundation for something
like this to work, but without a framing layer it won't be compatible.
Of course the changes could be done, but this is extra (and
dangerous?) work for developers who are just in need of something that
works.
What is the way to go from there? Should that warrant an extension?
Even though the changes were extremely minimal?

So I'll ask two questions here:

* if NoiseSocket is the way to have plug-and-play and compatible
libraries, do we really need negotiation? do we really need fallbacks?
etc... in a lot of use cases, the simplicity of Noise should suffice.
* if NoiseSocket is the way to go, should we make a push for
implementers not to implement the core of the Noise protocol
framework, but rather the NoiseSocket extension? I see a lot of "Noise
library" that in reality just implement the framework, whereas the
more useful work is where something can be actually used in real life
scenarios.

David