feat: Swarm.RelayService.InfiniteLimits #9662
Conversation
| @@ -67,7 +67,7 @@ require ( | |||
| github.com/jbenet/go-temp-err-catcher v0.1.0 | |||
| github.com/jbenet/goprocess v0.1.4 | |||
| github.com/libp2p/go-doh-resolver v0.4.0 | |||
| github.com/libp2p/go-libp2p v0.25.1 | |||
| github.com/libp2p/go-libp2p v0.25.2-0.20230222220431-c03190e1ca4f | |||
There was a problem hiding this comment.
ℹ️ switch to release after #9656 lands.
| // InfiniteLimits effectively removes all limits. Enabling this option also | ||
| // doesn't apply any filter for which protocols can be used, allowing for | ||
| // expensive things like bitswap over a relayed connection. |
There was a problem hiding this comment.
💭 need to confirm bitswap works over a static v2 relay when we run with infinite limit
|
@lidel we still want this? |
|
Unlikely, let's close this. A lot changed in ecosystem and go-libp2p. If anyone feels "unlimited relay for bitswap" is useful, they can fill an issue and we can discuss more modern approach. Digression / historical context: I think the problem I aimed to solve here was the fact that Relay v1 allowed Bitswap, and Relay v2 did not and we did not have hole punching and DCUtR at the time so people did not have 1:1 replacement + we broke example from docs. The idea was that if someone wanted to run their own static relay v2 infrastructure and cover the cost of relaying Bitswap over their servers, they should have that option. But in practice, existing users kept using Relay v1 by running https://github.com/libp2p/go-libp2p-relay-daemon and never asked for this feature to land, and now that we have DCUtR the interest is even smaller. DCUtR is not a silver bullet, and there will be cases where % of users is not able to do bitswap, but those days we don't want Kubo to support such edge case – a custom implementation built with go-libp2p or boxo should be used. |
This PR needs #9656 to land first.
Context
Allowing users to switch from additional v1 relays to built-in v2 in Kubo.
The idea here is to expose libp2p/go-libp2p#2125 as an experimental, opt-in configuration option,
for running an unlimited relay in controlled environments (when relay and clients are managed by the same entity).
We want to fix/update tutorial from ipfs/ipfs-docs#1459. If we can remove the need for asking people to run a separate libp2p-relay-daemon v1), and only run Kubo, that it is a big win and reduction in complexity and DX/UX win.
TODO
cc @2color @TheDiscordian for visibility