Document how to connect browser nodes with Kubo nodes using WebTransport

[BigLep]

Done Criteria

A user can learn about to enabling connectivity between Chromium browser nodes with other implementations like Kubo with WebTransport.

Why Important

We're unlocking great functionality here, but we need to ensure users can discover it, and know how to get started so the impact can be realized.

Notes

1. There is lots of work going around WebTransport, getting it into libp2p (both JS and GO), and exposing it in IPFS. This issue captures the docs.ipfs.tech portion of it. Implementation issues:
   • Support new libp2p WebTransport transport for experimentation kubo#9289
   • Enable WebTransport by default kubo#9292
   • [Tracking Issue] Experimental WebTransport Transport libp2p/go-libp2p#1717
   • feat: Interface changes to enable WebTransport libp2p/js-libp2p-interfaces#292
2. Ideally we should be pointing out to other documentation sources as much as possible and not duplicating. We do need to cover the IPFS-specific portions. For example, Document browser connectivity story and roadmap libp2p/website#154 will be relevant to point users for them to learn more.
3. An executable ipfs-example is going to go a long way here. Please coordinate with @2color or other developer advocates on how we tell this story.

[2color]

At what stage is the JS side of the implementation?

Is there a related issue for js-libp2p or js-ipfs?

[lidel]

• JS is WIP: feat: Interface changes to enable WebTransport libp2p/js-libp2p-interfaces#292
• GO will be opt-in in Kubo 0.16, but causes issues (Enabling WebTransport in Kubo v0.16.0-rc1 breaks Status page ipfs-webui#2033) which we need to resolve before announcing WebTransport to users.

I don't think this can be worked on until we have both JS and GO shipped as opt-in in stable Kubo and JS-IPFS releases, and ipfs-webui bug is fixed.

[mishmosh]

When we're ready, a tutorial/example would fit nicely into How-Tos > IPFS in the browser: https://docs.ipfs.tech/how-to/

There isn't any other mention in docs of browser nodes being paired with longer-running nodes. This is an architecture we'd like more developers to understand and perhaps use.

[ElPaisano]

Hi @BigLep docs teams is triaging issues right now, and I saw your comment on #9724:

I expect this will land in Kubo 0.21 (not 0.20) given Kubo maintainers are busy preparing for IPFS Thing and WebRTC hasn't shipped in go-libp2p yet.

Based on this, it looks like this issue is still relevant, but docs can't / shouldn't start on this issue yet? Regarding dates, could you help me determine:

• When the docs team will have enough info to work on this (or maybe we do now)?
• When this should be published?
• SME(s) who can help me create this content

I'll set this to status\deferred for the moment.
Thank you

[BigLep]

@ElPaisano : we can document about WebTransport today. #9724 is about WebRTC which is an additional transport from the browser.

I think there is enough information about this today, but there are also demos getting created now for IPFS Thing which will help make this clear. @aschmahmann and @SgtPooki will be able to help here. Lets pick this up after IPFS Thing 2023.

[BigLep]

@TheDiscordian : I know you have done work in and around this space? Is drafting something here, something you'd be interested in starting? I think even getting an outline together that myself and others could contribute towards would help.

[lidel]

There is an explainer in https://connectivity.libp2p.io/#webtransport that could be reused here, what is missing are code examples.

Caveat: I suspect this is soft-blocked until we ship https://github.com/protocol/bifrost-infra/issues/2142 and/or ipfs/kubo#9877 (or we need to introduce TLS cert to remove need for /certhash):

• webtransport address announced by Kubo have /certhash components which change every 14 days, so we can't hardcode them in webapps like we can with peerid alone
  • means we need to lookup peer to learn new /certhash on fresh or failed connect attempt (knowing IP and port is not enough)
• Kubo does not announce own /webtransport addrs to IPNI, only DHT, and DHT lookup/walk in browser is still a bit too expensive (we need delegating routing, native walk would be used only as a fallback).