multistream-select-v2: Initial draft #701
Conversation
|
Looks good to me |
connections/multistream-select-v2.md
Outdated
| protocol strings (tombstoned protocol strings). | ||
|
|
||
| The client's abbreviation tree will differ from the server's abbreviation tree | ||
| only in that protocol strings will only exist at leaf nodes. This is because |
There was a problem hiding this comment.
Leaf nodes of the client's abbreviation tree, right?
There was a problem hiding this comment.
I'm not sure I follow. Can you expand please?
There was a problem hiding this comment.
I mean the client's abbreviation tree will never have non-leaf protocol strings, right?
There was a problem hiding this comment.
yes. I've reworded it. Is it clearer now?
|
Do we need the hash function at all? The hash function acts as a mapping from a protocol string to a byte string with high likelihood of distinct short prefixes. But we could also imagine just using the index of the protocol string from the server's list instead. If a server returned protocols |
marten-seemann
left a comment
marten-seemann
left a comment
There was a problem hiding this comment.
Is it really necessary to support removing strings?
|
Whether to remove support for a protocol is an application concern. At this level, MSSv1 does support it, so it makes sense that the next version also supports. That said, If supporting removing strings makes the solution much more complicated, that's a tradeoff we should discuss. It would be good to understand the complexity of supporting it first. |
closes #700
An initial pass at specifying the abbreviation tree. There's still more to define like the wire format, how these protocol strings can be exchanged, and how to know if your peer supports multistream select v2.