I think it’s in the spirit of libp2p’s philosophy (“runs anywhere and everywhere”) to acknowledge that browsers are weird. They are always changing, they can be in a phone, in a car, in your VR goggles, wherever. It’s just not realistic to think that a single p2p library will work the same way in a node server, as in these other kinds of environments.
Make a new library “browser-libp2p” that covers the chrome runtime as well as establishing the roadmap for other browsers and devices going forward. Then split out all the browser intricacies and exceptions from the js-libp2p code and documentation, take out all those browser-only test files!
Searching the word “browser” in the js codebase returns 463 results across 123 files. This just shows how many gotchas, exceptions, separate paths, random notes there are in the docs and tests, etc. Why should it matter if two libp2p nodes are running browser-browser / browser-server / server-server, etc? This division and categorization goes against the spirit of “runs anywhere” and decentralization, IMO.
With separate libs for node and browser you could have API surfaces that actually represent what is possible and leverage the unique strengths in each environment. In node you can listen on websockets and enjoy looser network device support, in browsers you can leverage Service Workers and LocalStorage, etc. Imagine if PeerStore utilized Local Storage natively, then a browser page could refresh and not need to re-announce and re-discover and all of that. A built-in Service Worker could theoretically make unsupported transports “just work”.
NAT-traversal is a unique challenge only present in the browser, so let’s put away the luxuries of the node environment into its own stable lib, and tackle the unexplored future territory (and challenge of evolving browser differences) in a new browser-focused lib.
Just being realistic, NAT-traversal is going to be an ongoing task that will never “finish”. The OS environments and updates are just too unpredictable that it will be a cat-and-mouse game because the OS is always trying to protect users from themselves. NAT traversal has a great potential for abuse and exploitation if there’s a vulnerability, but a browser-only lib will be more nimble and can make this work easier and more focused going forward.
Obviously the browser and nodejs will share a lot of code in common, since it’s all JS. But the bulk of this comes from individual libraries anyway, since everything is conveniently already so modular.