This is a Q&D fix to get kubo building again, this is completely equivalent to what we used to have.
I'll submit a patch that DI the verifcid.Allowlist interface with fx later but this is needed to unblock something else.
Mplex does not implement backpressure, our implementation will randomly reset streams if buffers overflow instead of risking deadlocks.
In the past we had a bug where kubo nodes would prefer mplex over yamux. Turning off mplex make our connections to thoses nodes negociate yamux.
Closes#9958
* fix: mark ipns pubsub router DoNotWaitForSearchValue
That means if the DHT has finished searching and no one responded over pubsub *yet*, we will not spend 1 minute searching for no reason.
This also include other error handling bug fixes inside `go-libp2p-routing-helpers`.
Fixes: #9927
* routing: bring back the old IPNS behaviour
Stop making this configurable let everything race like it used to do.
Streams used to be blocked on ping IO because we didn't handled the DHT ping check asynchronously.
Include fixes from libp2p/go-libp2p-kad-dht#851
Fixes#9957
This adds the ability to enable "optimistic provide" to the default
DHT client, which enables faster provides and reprovides.
For more information about optimistic provide, see:
https://protocollabs.notion.site/Optimistic-Provide-2c79745820fa45649d48de038516b814
Note that this feature only works when using non-custom router
types. This does not include the ability to enable optimistic provide
on custom routers for now, to minimize the footprint of this
experimental feature. We intend on continuing to test this and improve
the UX, which may or may not involve adding configuration for it to
custom routers. We also plan on refactoring/redesigning custom routers
more broadly so I don't want this to add more effort for maintainers
and confusion for users.
* fix: remove timeout on default DHT operations
This removes the timeout by default for DHT operations. In particular
this causes issues with ProvideMany requests which can take an
indeterminate amount of time, but really these should just respect
context timeouts by default. Users can still specify timeouts here if
they want, but by default they will be set to "0" which means "no
timeout".
This is unlikely to break existing users of custom routing, because
there was previously no utility in configuring a router with timeout=0
because that would cause the router to immediately fail, so it is
unlikely (and incorrect) if anybody was using timeout=0.
* fix: remove 5m timeout on ProvideManyRouter
For context see
5fda291b66
---------
Co-authored-by: Marcin Rataj <lidel@lidel.org>
