But is it possible to do this without having to explicitly connecting the swarm via a command on the interested nodes?
Yep, it the viable browser-supported transports just haven’t fully propagated throughout the IPFS network yet, but we’re close. One particular issue you may want to keep an eye on is Enable WebRTC Transport · Issue #9724 · ipfs/kubo · GitHub
I would expect Helia to let other Peers and the DHT know which content it has pinned right?
To check if Helia is letting the DHT know that it has content, you can verify with the “Is my content on the DHT?” portion of PL Diagnose
Does this need some specialized libp2p config apart from using the normal
createHelia()command?
It shouldn’t.
The default libp2p config for a Helia node is https://github.com/ipfs/helia/blob/9139f30e857f4e247202e0d113027190a04892ba/packages/helia/src/utils/libp2p-defaults.browser.ts. It looks like it’s set to client mode by default, and you will need to change it to ‘server’ mode to do what you want… but acting as a DHT server is pretty expensive and may not be reliable in the browser. Please let us know if you run into any issues. This is incorrect, see below comment by Adin. Thanks Adin
My connected number of Peers is also Pretty low. On average maybe 15 Peers. Could that be the issue, as it is taking to long for the content to be published around the network?
This could certainly be an issue. In past testing, I needed to discover somewhere around 600 peers before I could connect reliably to a decent set of peers, and that took anywhere from 30min to 2 hours.
The main thing to take away here is that until more browser transports are enabled throughout the network (webrtc + webtransports + wss), browser nodes are best for fetching. If you’re running a service that depends on getting content from one browser node to another, you should either be using a pinning service provider, or running your own backend service.