Will provide content but not fetch content

[alanshaw]

1. If our node wants to provide content, we get the delegate to "provide" it by calling /api/v0/refs, which will slurp the content up from our node (assuming it is connected) and hence the delegate will start providing the content (until next GC).

As part of the provide call, we tell the delegate to connect to a set of bootstrap nodes. Why is that? It's not doing what the comment says: "call swarm.connect on the delegated node to us, to ensure we are connected".

2. If our node wants to fetch some content, then we can use the delegate to find peers that have it, but the delegate will not actually fetch the content for us.

That's ok, but it's not symmetric with providing (is that intended?), and is not much use in the browser because we're unlikely to be able to connect to those providers.

I appreciate this module is meant for routing and not relay. I just wanted to get some clarification on these details and maybe suggest that they are documented on the README along with the API endpoints that are required to be open an available on the delegate.

@jacobheun @daviddias

[daviddias]

As part of the provide call, we tell the delegate to connect to a set of bootstrap nodes. Why is that?

Good questions. Can you point to the code that is doing that? Is this on go, js or both?

That's ok, but it's not symmetric with providing (is that intended?), and is not much use in the browser because we're unlikely to be able to connect to those providers.

It was intended as the hypothesis was that we would use Relay to connect to that final destination node. Now that the relays are shutdown, the story is different.

What I'm realizing is that JS IPFS does need to have its own dedicated infrastructure:

• preload nodes
• rendezvous node for It's (beyond) time to sunset the *-star protocols 🌅 js-libp2p#385
• relay node for It's (beyond) time to sunset the *-star protocols 🌅 js-libp2p#385
• relay node for this issue (can be the same as the above one, but might be useful to be different)
• websocket bootstrappers
• more?

All of these pieces should be no more than an ipfs/libp2p node with some config set

[alanshaw]

As part of the provide call, we tell the delegate to connect to a set of bootstrap nodes. Why is that?

Good questions. Can you point to the code that is doing that? Is this on go, js or both?

js-libp2p-delegated-content-routing/src/index.js

Lines 86 to 92 in 69f1f94

	const addrs = this.bootstrappers.map((addr) => {
	return addr.encapsulate(`/p2p-circuit/ipfs/${this.peerId.toB58String()}`)
	})
	const results = await Promise.all(
	addrs.map((addr) => {
	return this.swarm.connect(addr.toString()).catch(() => {})

That's ok, but it's not symmetric with providing (is that intended?), and is not much use in the browser because we're unlikely to be able to connect to those providers.

It was intended as the hypothesis was that we would use Relay to connect to that final destination node. Now that the relays are shutdown, the story is different.

Gotcha.

What I'm realizing is that JS IPFS does need to have its own dedicated infrastructure:

• preload nodes

Got.

• rendezvous node for libp2p/js-libp2p#385
• relay node for libp2p/js-libp2p#385

Need, need.

• relay node for this issue (can be the same as the above one, but might be useful to be different)

We'd not be able to force people using these modules to use a particular relay would we? I am +1 on "another relay for JS IPFS" though 😂

• websocket bootstrappers

Got. Right?

All of these pieces should be no more than an ipfs/libp2p node with some config set

👍

[daviddias]

@alanshaw now that I see the code, what I suspect is that the believe (I say believe because I couldn't find it documented anywhere) is that the Bootstrappers would also be the relays, which is not the case.

On the JS IPFS Infrastructure. As you say, we have multiple of those pieces, but currently it is a black box for users. We should document that in addition to what js-ipfs is capable, we also have deployed all of those for very specific reasons.

[alanshaw]

refs ipfs/js-ipfs#2231

[jacobheun]

and is not much use in the browser because we're unlikely to be able to connect to those providers.

This is the case now, but if we have more nodes leveraging public delegates the problem should go away, because we should find the delegate nodes in the provider lookup instead of the origin nodes.

The lack of symmetry is really a hack on not using a provide api. A clearer api might be to actually tell the delegate node to provide, and then it would fetch the content from us before it announced, rather than us just telling it to pull from us and then assume it's registering as a provider of that.

[achingbrain]

This module had fetch methods added several years ago, please re-open if you're still having problems.