[🏆 Golden path scenario] Browser-authored content retrievable by another machine through the ipfs.io gateway directly

## Done Criteria

A user can author content in their browser via Helia and have it retrievable by another machine through the [ipfs.io](http://ipfs.io/) gateway without relying on pinning services or preload nodes.

## Why Important

This is a common usecase that users hit. Failure here feeds the narrative that "IPFS doesn't just work".

## Notes

1. This builds on https://github.com/ipfs/helia/issues/256, which used pinning services. We’re assuming it was completed first before taking this on.
2. Even though this usecase request has come in (e.g., HackFS 2023), it’s a lower priority because it has the fundamental flaw of relying on a browser tab to stay open/active. This may make sense for a demo, but has serious usability flaws. In practice, we expect most browser apps will want to be more resilient, and for that, they need a way to get data off the browser (e.g., use a pinning service which https://github.com/ipfs/helia/issues/256 satisfies).
3. "retrievability from the [ipfs.io](http://ipfs.io/) gateway" is used as a popular "stand in" for other nodes on the network.
4. We need to enable discoverability of the content created in the browser so that the [ipfs.io](http://ipfs.io/) gateway can discover it. This requires one or more of:
- Direct reliable libp2p publishing to the "IPFS public DHT" from the browser
- Direct HTTP writing to an IPNI like cid.contact ([/ingest/announce](https://docs.cid.contact/ingestion/overview#http))
- [Delegated HTTP /routing/v1 PUT support](https://github.com/ipfs/specs/pull/378) and endpoints that can use like [routing.delegate.ipfs.tbd](https://github.com/protocol/bifrost-infra/issues/2142), cid.contact, etc. (This is the path we're prioritizing per the tasks below.)
5. DCUtR in js-libp2p is needed so the Kubo gateway can run the protocol with the browser node via the relay and instruct the browser to dial one of its public multiaddrs supported from the browser (e.g., WSS, WebTransport). This will have been handled in https://github.com/ipfs/helia/issues/256.
6. The next step here is to allow a private Kubo node (e.g., Kubo running in one's Brave browser) to fetch the content authored in a browser on a separate host. We ultimately need Kubo to support WebRTC since WebRTC is required for browser/private-node connectivity per [here](https://github.com/libp2p/specs/blob/d2106f43e878ae4c3a1c6465a7c329835290fe22/connections/hole-punching.md#vision). (Kubo tracking issue: https://github.com/ipfs/kubo/issues/9724 ). This should have been completed though by https://github.com/ipfs/helia/issues/256.
7. Per above, this isn't a pure Helia issue. Tracking the usecase needs to go somewhere though, so I'm putting it Helia for now so we can link against it.

```[tasklist]
### Tasks
- [ ] IPIP/spec for HTTP /routing/v1 PUT support (at least writing delegated content records to the DHT):
- [ ] Boxo having /routing/v1 PUT support (IPIP-378)
- [ ] Exposing /routing/v1 PUT support in Kubo
- [ ] routing.delegate.ipfs.tbd having /routing/v1 PUT support
- [ ] JS updates to use IPIP-378 (write side of delegated content routing)
- [ ] js-libp2p: Reconnect with relays so that previously published multiaddrs with relays have a higher chance of still working - https://github.com/libp2p/js-libp2p/issues/1955
```