feat!: change connection encryption interface to uint8arraylist

[mpetrunic]

replacing #275

BREAKING CHANGE: connection encryption interface now accepts and yields uint8arraylist instead of uint8array

[achingbrain]

What's the change to@chainsafe/libp2p-noise that meant MultiaddrConnections had to start sourcing/sinking Uint8ArrayLists? From what I can see it's still Uint8Arrays in and out because the data goes through encryption libraries which only ever accept/return Uint8Arrays.

[mpetrunic]

What's the change to@chainsafe/libp2p-noise that meant MultiaddrConnections had to start sourcing/sinking Uint8ArrayLists? From what I can see it's still Uint8Arrays in and out because the data goes through encryption libraries which only ever accept/return Uint8Arrays.

Its not yet updated in noise and secio, will do next week

[achingbrain]

secio is long deprecated & is unsupported so there's no need to spend time on that. The other implementation that'll need updating is PlainText but noise should be done first as it doesn't depend on libp2p.

Looking at noise, there's some concatenation being done during the handshake that's now unnecessary since you can write a Uint8ArrayList directly into writeLP, but it's probably not a bottleneck because it only happens once at the start of the connection.

This pipeline is the hot code path but from what I can see because decryptStream yields values from handshake.decrypt, which calls chaCha20Poly1305Decrypt it's only ever going to yield Uint8Arrays so there's nothing to gain from using Uint8ArrayList.

What am I missing?

[github-actions]

🎉 This PR is included in version @libp2p/interface-connection-encrypter-v2.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version @libp2p/interface-connection-v3.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version @libp2p/interface-connection-encrypter-compliance-tests-v2.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version @libp2p/interface-mocks-v4.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[mpetrunic]

This pipeline is the hot code path but from what I can see because decryptStream yields values from handshake.decrypt, which calls chaCha20Poly1305Decrypt it's only ever going to yield Uint8Arrays so there's nothing to gain from using Uint8ArrayList.

What am I missing?

I think you are right. I don't think noise cares if it yields or returns Uint8Array or Uint8ArrayList. But ain't we gonna have type issues if mplex or yamux is trying to pipe Uint8ArrayList into Secured connection that accepts Uint8Arrays only?

[achingbrain]

No, because everything goes through it-length-prefixed which only emits Uint8Arrays when encoding.

[mpetrunic]

No, because everything goes through it-length-prefixed which only emits Uint8Arrays when encoding.

ugh, should we revert this change and release then?

[achingbrain]

Yes & I think the generics can be removed from MultiaddrConnection - e.g.

export interface MultiaddrConnection<T extends Uint8Array | Uint8ArrayList = Uint8Array> extends Duplex<T> {

can go back to

export interface MultiaddrConnection extends Duplex<Uint8Array> {