Question from a noob

[eldoradomap]

I've been working on a pretty simple web extension and have a few questions, feel free to correct me where I am wrong or have a misconception about something.

One of the major things I need to do here is run an ipfs node in the browser (for context)

1. In the helia-webpack example we add the content to our helia node, how do I pin that content so I can actually view it from ipfs.io/ipfs/
2. I was under the impression we needed to use webrtc in the browser to run ipfs nodes because we can't do arbitrary tcp/quic connections. So we would use a signaling server with an exposed websocket to "forward" the browser traffic to the rest of ipfs. But in the helia-webpack example none of that seems to be happening (unless helia is just managing all of that and thats why I don't see it.)

I appreciate any feedback, this project I'm making is mostly for getting my hands dirty with js and ipfs so please please correct me where you see fit.

[2color]

In the helia-webpack example we add the content to our helia node, how do I pin that content so I can actually view it from ipfs.io/ipfs/

That's a tricky one. When Helia is running in the browser, it's very constrained in terms of network transports so even though you pin it, it's unlikely to be retrievable from public gateways.

I was under the impression we needed to use webrtc in the browser to run ipfs nodes because we can't do arbitrary tcp/quic connections.

Correct

So we would use a signaling server with an exposed websocket to "forward" the browser traffic to the rest of ipfs. But in the helia-webpack example none of that seems to be happening (unless helia is just managing all of that and thats why I don't see it.)

To be honest, we need to add more warnings about the viability of this approach. The reality is that providing blocks from browsers isn't really functional today.

Signaling is a WebRTC specific concept that is mostly relevant for browser-to-browser connectivity.

So how could providing from the browser work?

But the high level idea of of how browser providing would work is:

1. Add file to Helia in browser node which merkelises it into a DAG with a CID. The blocks are in stored in Helia's blockstore.
2. Browser helia uses kad-dht to find 20 DHT servers to which it advertises the provider record. Same nodes cache browser circuit relay + webrtc multiaddrs "Peer Record" (implicitly)
3. Gateway looks up at least 1 of the 20 DHT servers
4. Gateway discovers one of the browser helia circuit relay addrs (e.g. QUIC one) and dials the browser via the relay
5. Browser node recieves incoming connection from the gateway node. Runs identify and discovers the gateway's WebSocket/Multiaddr addr
6. Browser dials back the gateway on a non-limited direct connection, i.e. WebSocket/WebRTC-direct/WebTransport (one day when browser bugs are fixed)
7. Block exchange via bitswap makes the block from browser retrievable.

There are multiple places where this can go wrong:

• The browser helia node is externally dialable as long as the tab is open and the circuit relay reservation is maintained. However this is flaky, since the browser can throttle resources to the tab if you don't interact with it.
• The circuit relay node can drops the reservation, making the browser no longer dialable on that address.
• The browser and the gateway need to reach at least one of the same DHT servers. Emergent network segmentation can undermine this as older DHT nodes don't support any browser transports. So for this to work, there needs to be overlap between the DHT server the gateway and browser node pick which depends on whether those DHT servers also support the new browser transports we are gradually improving.

So in summary, there's more work that needs to be done for browser providing to function, and my intuition is that this will never work perfectly.

Ok, so what's the alternative

Providing data is something that a long running server is much better fit to do. Ideally, you handle merkelisation (creating the DAG with a CID) in the browser, and then upload a CAR file to a pinning service or a long running IPFS node that's better capable of providing to the network.

[eldoradomap]

Copy, thanks for the reply this helps a ton.

[SgtPooki]

This writeup here is gold @2color.. thanks for capturing this here. Note that #182 is our tracking issue for the scenario that @eldoradomap brought up