Protocols might need to be rewritten so that we could keep up with libp2p updates

[acud]

We are apparently using too many streams which are open for too long in our usage of libp2p.

It would be good to consult with them (over their discourse) about our use-case and see whether it would be more realistic to use a simple up-down stream pattern per-peer per-protocol.

[agazso]

Currenly updating Go version is blocked because libp2p v0.16 cannot be compiled with Go 1.18.

In order to upgrade Go version we would also need to update the libp2p version to 0.19.1 at least.

[agazso]

The current idea is to do a research about this topic, so that there can be a good estimate and break-down at a task level what needs to be done.

[mrekucci]

I'd suggest switching to go1.19.1. There are things in subsequent versions of go-libp2p that may affect us (in terms of functionality and stability of the whole network), so they need to be thoroughly investigated:

v0.18

• Resource Manager: https://github.com/libp2p/go-libp2p/releases/tag/v0.18.0 v0.19
• AutoRelay discovery method: https://github.com/libp2p/go-libp2p/releases/tag/v0.19.0 v0.21
• Configuration constraints for auto-scaling resource management: https://github.com/libp2p/go-libp2p/releases/tag/v0.21.0 v0.22
• Automatic private key generation (Ed25519 key instead of RSA key)
• AutoRelay actively polling candidates, instead of expecting the application to continuously deliver new candidates
• Monorepo migration complete": https://github.com/libp2p/go-libp2p/releases/tag/v0.22.0

[nikipapadatou]

It seems not to be relevant anymore.