Roadmap for Circuit Relay v2 File Transfer?

Ecosystem
, ,
1

I’ve got a question, but I’m also looking for clarification that I’m understanding the landscape correctly.

Please correct me if any of these statements are incorrect:

  • File passing between IPFS nodes uses bitswap.
  • Circuit Relay v2 does not allow bitswap (file passing).

I just ran an experiment with three nodes using go-ipfs v13:

  • One node has a public IP and was configured as a Circuit Relay.
  • The other two nodes were behind a firewall.
  • The firewalled nodes could connect to one another through the Circuit Relay, but they could not pass files to one another.

Is there a roadmap, GitHub Issue, or some other place that I can view to monitor the progress of file passing through Circuit Relay v2?

Is there some way to enable it, even if it involves advanced hacking?

Is there any plan or roadmap to get to a point where files can be passed through Circuit Relay v2?

1 Like
2

As far as I know, it’s not planned. The reason being, v2 is only there as a means for nodes to connect directly to each other using hole punching (which is a way for nodes behind separate NAT routers to establish a direct connection). Make sure hole punching is enabled:

ipfs config --json Swarm.RelayClient.Enabled true
ipfs config --json Swarm.EnableHolePunching true
3 Likes
3

It is not that the relays do not support relaying anything. It is that in Kubo, specifically, the relay-server part is utilized to enable NAT hole punching now and only that, and as such it is limited to relaying small pieces of data.

If you want a general purpose relay, rather than using a Kubo node with Relay enabled in server mode as you did before, you can use GitHub - libp2p/go-libp2p-relay-daemon: A standalone libp2p circuit relay daemon providing relay service for versions v1 and v2 of the protocol..

2 Likes
4

Thank you so much for that link, @hector! It was exactly what I needed.

I read through the thread How to setup V1 Relay in the new config, and I was using a very similar network configuration as @susarlanikhilesh: The two nodes I wanted to connect were behind an unknown level of firewalls with no visibility into their network configuration. I needed a way to tunnel through any firewalls and pass files between the nodes. I followed the instructions carefully, but in my tests, hole punching was not successful and I was not able to get the two nodes to connect to one another directly. Reverting to a v1 Relay was my only option.

I was able to setup libp2p-relay-daemon as a V1 relay using this config:

{
  "RelayV2": {
    "Enabled": false
  },
  "RelayV1": {
    "Enabled": true
  },
  "Network": {
    "ListenAddrs": [
        "/ip4/0.0.0.0/udp/4002/quic",
        "/ip6/::/udp/4002/quic",
        "/ip4/0.0.0.0/tcp/4002",
        "/ip6/::/tcp/4002",
        "/ip4/0.0.0.0/tcp/4003/ws",
        "/ip6/::/tcp/4003/ws"
    ]
  },
  "Daemon": {
    "PprofPort": 6061
  }
}

Also a note for people who try this: You need to install Go v1.17.12. The project will not install with the current version of Go (v1.18.4).

5

I packaged go-libp2p-relay-daemon into a Docker container and created a Docker Compose file, for those who like to manage their servers with Docker.

6

Hi @christroutner, can you please tell me how did you get it to work with v1 relay? Kubo nodes have a different config (which I guess only supports v2 relays) from legacy go-ipfs v1 relay configs.

7

You identified the situation correctly. A couple months after creating that V1 relay Docker package, I realized it was useless.

I’ve moved away from Kubo (go-ipfs) to Helia (js-ipfs), and it’s the same thing: those nodes will simply not use the v1 relay anymore. They only support v2 relays, despite their shortcomings.

I’ve given up on using v1 relays, even though I really like the simplicity of the solution.

1 Like
8

Thank you so much for the reply :blush:, so were you able to solve the problem using v2 relays? or did you use any other methods to resolve this issue?

9

My experience so far has been that v2 Circuit Relays are flaky, and the ability to use webRTC breaks continuously and is also flaky. Sometimes it works, sometimes it doesn’t, and I never really understand why it worked or didn’t work. I’m trying to learn more about the tech and the underlying code so that I can one day fix this issue, as it’s badly needed in the software I’m developing.

The only thing that has allowed me to continue using libp2p and IPFS is to set up my own network of nodes on cloud VPS with a static IP address and open ports. I use pubsub channels as the primary form of communication, so as long as my edge nodes can make a direct connection to one of these VPS nodes, they get the information from the pubsub channel.

I hope that I can get better network connectivity through webRTC and V2 Circuit Relays some day, but right now that part of the tech just isn’t reliable. If it wasn’t for the more reliable ip4 direct connections and pubsub channels, I wouldn’t be able to use libp2p/IPFS in my project at all.

1 Like
10

Thanks, I guess the only other option is to revert to v1 relays. I guess I will do that.

11

My understanding is that v1 relays are only accessible by older versions of go-ipfs. If you have a plan for using v1 relays, I’d like to hear more about it. I’d love to revert my network back to v1 relays if possible.