chore(deps)!: bump @libp2p deps

[D4nte]

Bump enough @libp2p deps to fix master.

[codecov-commenter]

Codecov Report

Merging #289 (2a055c8) into master (475c861) will decrease coverage by 0.02%.
The diff coverage is 77.77%.

@@            Coverage Diff             @@
##           master     #289      +/-   ##
==========================================
- Coverage   80.46%   80.44%   -0.03%     
==========================================
  Files          42       42              
  Lines        9102     9111       +9     
  Branches      826      828       +2     
==========================================
+ Hits         7324     7329       +5     
- Misses       1778     1782       +4     

Impacted Files	Coverage Δ
src/index.ts	69.37% <77.77%> (-0.05%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 475c861...2a055c8. Read the comment docs.

[achingbrain]

When a stream is created by the muxer, it has no protocol, it's just a simple data channel. The stream is returned to the upgrader, which runs the protocol negotiation algorithm (currently multistream-select but there will be others in future), after which the protocol will be set. It's then handed back to the user.

This is all internal to libp2p so maybe it needs an interim type for the muxer to return which has no protocol, then the upgrader can convert it to the type with a protocol so the types will be nicer to use.

Effectively though, there will be a protocol set on the stream that is returned from connection.newStream since if protocol negotiation fails an error will be thrown.

the protocol was moved from the Connection to the Stream

Not exactly - Connection instances don't have protocols - the connection has a muxer, which has lots of muxed streams, each of which have a protocol.

If you have a connection instance without a multiplexer, I guess you could could negotiate a protocol over it manually, but this is of little practical use because muxing is cheap and connections are expensive.

Anyway previously we had the negotiated protocol being returned alongside the stream which made it finicky to track, now it's a property of the stream itself.

[D4nte]

Thanks for the detailed explanation! Very much appreciated.

This is all internal to libp2p so maybe it needs an interim type for the muxer to return which has no protocol, then the upgrader can convert it to the type with a protocol so the types will be nicer to use.

Noted.

Effectively though, there will be a protocol set on the stream that is returned from connection.newStream since if protocol negotiation fails an error will be thrown.

I had a hunch this is what would happen. Does it mean the current logic is acceptable? Do we want to add a log if protocol is not set? (which should not happen).

[achingbrain]

I think the current logic is fine, but if you're null-guarding on .protocol then adding a log line for the case where it's not set is probably good from a debugging point of view, even if it's unlikely to get hit in practice.

[wemeetagain]

@D4nte sorry just saw this PR. I just merged #291 which does the same.