Some feedback and thoughts on integration

[raulk]

Apologies for the slow turnaround! This has been sitting in my queue for quite some time.

• A standard for protocol nomenclature and metadata advertisement would be a valuable addition to multiformats/libp2p. Thanks for starting this!
• I like that you have specifically steered away from semver. In my experience, it's a poor fit for network protocols.
• Unless I missed it, it's unclear from the spec what the lengths/binary forms of the namespace, protocol, version are.
  • Do namespace and protocol follow the multicodec spec? https://github.com/multiformats/multicodec
  • Is version a uvarint?
• Would you envision adding multiprotocols as a field in Signed Peer Records? RFC: Signed Address Records libp2p/specs#217 That way peers can exchange authenticated records that express the protocols and capabilities they support, potentially with a flag indicating whether the enumeration is complete or partial.
• multiaddr integration is cool and really appreciated. In practice, it could be rather cumbersome to advertise multiple protocols under the same endpoint.
  • multiaddr does not support variadic forms yet, so you’d end up denormalising, and that has a cost.
  • The above is already a limitation we need to solve for when we start advertising secure channels on the multiaddr. If a node has 4 endpoints and 3 secure channels, we don’t want to announce 4x3 multiaddrs, rather 4 multiaddrs with a variadic component.
  • One possible solution is to add a multicodec that signals a variadic anchor.
  • That would allow you efficiently multiaddrs that compose an endpoint + many protocols/capabilities tuples.
• For integration with multiaddr, we could have a multicodec that stands for "multiprotocol". That way you're not blindly tacking on a multiprotocol and hoping the other party would interpret the correct way, but you're being self-descriptive and deterministic about what follows.
• In my view, a multiprotocol should not mandate a TSV format; instead, the metadata should be opaque.
• And it needn't be limited to capabilities. I see this as a general mechanism to communicate out-of-band protocol-scoped information.
  • For example, Bluetooth endpoints may want to communicate SDP/capabilities in a native format.
  • Or a chat protocol may want to embed a b64 avatar along with its advertisement.
  • It's true that with the current construction you could embed this data on a top-level element, but that adds more overhead than it needs to.
• I'd also like to mandate that implementations should offer a way to index iterate/into metadata elements.
  • Rationale: I may want to populate a bloom filter of protocols/capabilities supported by an endpoint by adding each tuple as an item in the bloom filter, rather than the whole multiprotocol string as a whole.
  • The latter would not allow me to test whether a given peer supports a given capability.

[decanus]

Hey @raulk, thanks for the reply. Lots of our thoughts are in sync.

Unless I missed it, it's unclear from the spec what the lengths/binary forms of the namespace, protocol, version are.

All those fields are currently uvarints, lengths are not defined but we could look into this if necessary.

Would you envision adding multiprotocols as a field in Signed Peer Records? libp2p/specs#217 That way peers can exchange authenticated records that express the protocols and capabilities they support, potentially with a flag indicating whether the enumeration is complete or partial.

Yes that would be optimal, multiprotocol was inspired by ethereums ENR which is essentially a signed record too.

multiaddr integration is cool and really appreciated. In practice, it could be rather cumbersome to advertise multiple protocols under the same endpoint.

Yeah, this is a point I have been stuck on and thinking about for a while, I think the easiest way would be to add a multicodec that signals a variadic anchor as you mention.

For integration with multiaddr, we could have a multicodec that stands for "multiprotocol". That way you're not blindly tacking on a multiprotocol and hoping the other party would interpret the correct way, but you're being self-descriptive and deterministic about what follows.

Yes exactly, throw the multiprotocol into a key value and call it a day.

In my view, a multiprotocol should not mandate a TSV format; instead, the metadata should be opaque.

Yeah, completely agree. I think that section is more of an artefact that can be removed.

And it needn't be limited to capabilities. I see this as a general mechanism to communicate out-of-band protocol-scoped information.

Yeah I completely agree

I'd also like to mandate that implementations should offer a way to index iterate/into metadata elements.

That sounds like a smart idea. How about you PR it in?

Again thanks for the review, I'll make some of the changes would love if you could PR the index iteration. Also, how should we move forward on this? I'd love to make it part of the multiformat family