Skip to content

Conversation

@marten-seemann
Copy link
Contributor

A typical protobuf sent here weighs ~75 bytes, whereas this encoding results in ~20 bytes more being sent.

Given that WebRTC (#412) will also use Noise's Early Data feature, it would be nice if the data structure sent in the early data was self-describing, to avoid confusing WebTransport's and WebRTC's early data in implementations that use a single instance of a Noise Transport (the Go implementation won't, but it's not completely crazy to imagine other implementations choosing this route). Having WebTransport use a CBOR struct with "webtransport-hashes" as a field name makes sure we don't accidentally define the same Protobuf (on the wire) and mix up things.

@mxinden
Copy link
Member

mxinden commented Jul 18, 2022

I am not sure I understand the proposition. Am I paraphrasing this correctly?

Protobuf is not self-describing. This particular CBOR is self-describing. Being self-describing makes sure the message is not accidentally used for a different purpose (e.g. WebRTC instead of WebTransport).

Reponse below applies to what I understand above.

(the Go implementation won't, but it's not completely crazy to imagine other implementations choosing this route).

I don't think the Rust implementation would either.

to avoid confusing WebTransport's and WebRTC's early data in implementations that use a single instance of a Noise Transport

I would not consider this a large issue. In other words, I think we have bigger foot guns.

A typical protobuf sent here weighs ~75 bytes, whereas this encoding results in ~20 bytes more being sent.

As far as I know we don't use CBOR anywhere. I very much value the consistency, i.e. libp2p using mostly ProtoBuf.

Say we want to go the route of ensuring a message to not be mistaken as a different one, would a Protobuf Dictionary not do the job as well?

@melekes
Copy link

melekes commented Jul 19, 2022

to avoid confusing WebTransport's and WebRTC's early data in implementations that use a single instance of a Noise Transport (the Go implementation won't, but it's not completely crazy to imagine other implementations choosing this route)

The problem seems a little far-fetched to me. Rust implementation also uses a separate instance of Noise. What would be the benefits of using the same instance between two transports?

@marten-seemann
Copy link
Contributor Author

We now have the Noise extension registry, which is the more libp2p-idiomatic solution for this problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants