Only peers found from DHT seem to be getting used as relays, so can't use HTTP routers

Help Kubo
1

There also doesn’t seem to be any way/API to add peers to the relay list, and for our use case we only use HTTP routers, so we have no way for any of our discovered peers to ever be used as relays.

2

what type of HTTP router? Relays are peers that run a libp2p service used specifically to coordinate NAT hole punching and nothing beyond that.

3

our app is https://seedit.app it’s a reddit alternative but fully P2P using IPFS, IPNS over pubsub and gossipsub.

we bundle kubo with our electron application to distribute it, and when DHT was enabled, our users would often complain that it would kill their router (this still happens even recently). We also run gateways for the web version and DHT would often cause the VPS to become unresponsive, I guess because something on the network crashes because of DHT and it had to be manually restarted from the VPS dashboard. So we decided to create “IPFS trackers” (like bittorrent trackers). We have a few volunteers that run a key value store server and store peers, and it tries to implement the delegated routing API, and the kubo PUT API, and hopefully eventually the delegated routing POST API will be released officially and we can use it. this is an example of our kubo config:

"Routing": {
		"Methods": {
			"find-peers": {
				"RouterName": "HttpRouterNotSupported"
			},
			"find-providers": {
				"RouterName": "HttpRoutersParallel"
			},
			"get-ipns": {
				"RouterName": "HttpRouterNotSupported"
			},
			"provide": {
				"RouterName": "HttpRoutersParallel"
			},
			"put-ipns": {
				"RouterName": "HttpRouterNotSupported"
			}
		},
		"Routers": {
			"HttpRouter1": {
				"Parameters": {
					"Endpoint": "https://routing.lol"
				},
				"Type": "http"
			},
			"HttpRouter2": {
				"Parameters": {
					"Endpoint": "https://peers.pleb.bot"
				},
				"Type": "http"
			},
			"HttpRouter3": {
				"Parameters": {
					"Endpoint": "https://peers.plebpubsub.xyz"
				},
				"Type": "http"
			},
			"HttpRouter4": {
				"Parameters": {
					"Endpoint": "https://peers.forumindex.com"
				},
				"Type": "http"
			},
			"HttpRouterNotSupported": {
				"Parameters": {
					"Endpoint": "http://kubonotsupported"
				},
				"Type": "http"
			},
			"HttpRoutersParallel": {
				"Parameters": {
					"Routers": [
						{
							"IgnoreErrors": true,
							"RouterName": "HttpRouter1",
							"Timeout": "10s"
						},
						{
							"IgnoreErrors": true,
							"RouterName": "HttpRouter2",
							"Timeout": "10s"
						},
						{
							"IgnoreErrors": true,
							"RouterName": "HttpRouter3",
							"Timeout": "10s"
						},
						{
							"IgnoreErrors": true,
							"RouterName": "HttpRouter4",
							"Timeout": "10s"
						}
					]
				},
				"Type": "parallel"
			}
		},
		"Type": "custom"
	},

Note that because the kubo HTTP routing has a bug and doesn’t announce the correct addresses, we usually use a localhost reverse proxy that rewrites the addresses to be what ipfs id outputs.

So as you can see, we don’t use the DHT at all, but our users do discover many peers and connect to many peers, but none of these peers can be added as relays, because there’s no API for it, and because the relay system seems to only consider peers discovered from the DHT.

A scenario where a user might want to use a relay:

  • they are behind a NAT
  • they want to publish some content
  • they can announce to the trackers, but they don’t have any listen address that are reachable
  • so ideally they would pick one of the peer they know about (and maybe are even already connected to), and if they support relaying, they would use them as a /p2p-circuit listen address to do hole punching
  • this will become an even bigger issue once kubo supports webrtc using relays as signaling servers, as we won’t be able to use it at all