The fetch protocol uses this protobuf:
message FetchRequest {
string identifier = 1;
}
One use case for fetch is resolving IPNS records directly from other nodes (ref).
The identifier for this operation is "/ipns/" + public-key-multihash-bytes.
Treating identifier as a string means we need to stringify the value before serializing it to pb bytes, and we'll also interpret any received value as a string.
golang treats public-key-multihash-bytes as a char array so this works as expected.
JavaScript strings are all UTF-16, all the time so it's possible to have a series of bytes that we can't round trip to a string if some pairs of byte values happen to be interpretable as a multi-byte character.
Since the on-the-wire format of string and bytes in protobuf is identical, JS could just unilaterally treat identifier as bytes to make the problem go away, or we can change the type in the spec definition so it's clear for implementers?
cc @aschmahmann
The
fetchprotocol uses this protobuf:One use case for fetch is resolving IPNS records directly from other nodes (ref).
The identifier for this operation is
"/ipns/" + public-key-multihash-bytes.Treating
identifieras astringmeans we need to stringify the value before serializing it to pb bytes, and we'll also interpret any received value as a string.golang treats
public-key-multihash-bytesas a char array so this works as expected.JavaScript strings are all
UTF-16, all the time so it's possible to have a series of bytes that we can't round trip to a string if some pairs of byte values happen to be interpretable as a multi-byte character.Since the on-the-wire format of
stringandbytesin protobuf is identical, JS could just unilaterally treatidentifierasbytesto make the problem go away, or we can change the type in the spec definition so it's clear for implementers?cc @aschmahmann