There are a number of indicators that suggest iroh may be a better inter-kernel network communications package for our purposes than libp2p which we're using now. Although libp2p mostly works, its complexity (designed to handle every imaginable use case, including some we really don't care about), wide-spread wheel reinvention (rather than building more directly on familiar standards), poor documentation, and overall flakiness (Dimitris' characterization that "it's made of bugs" has now become a permanent part of my lexicon) have been an ongoing source of maintenance headaches (see, e.g., #931), testing challenges, debugging struggles, and general inconvenience & frustration. iroh is much newer on the scene, but we have reports from the Endo team, who have been playing around with it, that make it sound promising for our specific use case (in particular, while being substantially smaller and simpler, it still addresses two of our biggest comms challenges, NAT hole punching and the inability to do what by rights ought to be a straightforward socket.listen() operation from inside a browser).
We should investigate whether iroh is, in fact, suitable for our use and whether it is likely to be superior to what we are doing now. If the investigation results are positive, we should further look into whether we want to simply swap out libp2p and replace it with iroh wholesale or whether we might be better off creating a clean network comms layer that can be configured to use either (or possibly create a clean network comms layer, implement it using iroh and discard libp2p anyway).
There are a number of indicators that suggest
irohmay be a better inter-kernel network communications package for our purposes thanlibp2pwhich we're using now. Althoughlibp2pmostly works, its complexity (designed to handle every imaginable use case, including some we really don't care about), wide-spread wheel reinvention (rather than building more directly on familiar standards), poor documentation, and overall flakiness (Dimitris' characterization that "it's made of bugs" has now become a permanent part of my lexicon) have been an ongoing source of maintenance headaches (see, e.g., #931), testing challenges, debugging struggles, and general inconvenience & frustration.irohis much newer on the scene, but we have reports from the Endo team, who have been playing around with it, that make it sound promising for our specific use case (in particular, while being substantially smaller and simpler, it still addresses two of our biggest comms challenges, NAT hole punching and the inability to do what by rights ought to be a straightforwardsocket.listen()operation from inside a browser).We should investigate whether
irohis, in fact, suitable for our use and whether it is likely to be superior to what we are doing now. If the investigation results are positive, we should further look into whether we want to simply swap outlibp2pand replace it withirohwholesale or whether we might be better off creating a clean network comms layer that can be configured to use either (or possibly create a clean network comms layer, implement it usingirohand discardlibp2panyway).