Thanks for the interest everyone! We think libp2p is one of the most exciting and useful parts of the IPFS project. We've refactored it out of IPFS for the benefit of the general p2p / networking community.<p>We're working on cleaning up interfaces, getting to a good level of completeness and interop between go and js, and then messaging/explanations. Stay tuned for proper a launch later on. But note both go-libp2p and js-libp2p are usable and in use now. :)<p>- Go: <a href="https://github.com/ipfs/go-libp2p" rel="nofollow">https://github.com/ipfs/go-libp2p</a><p>- js: <a href="https://github.com/diasdavid/js-libp2p" rel="nofollow">https://github.com/diasdavid/js-libp2p</a><p>- specs: <a href="https://github.com/ipfs/specs/tree/master/libp2p" rel="nofollow">https://github.com/ipfs/specs/tree/master/libp2p</a><p>brb, 8hr flight.
Does this include any latency or hop estimation schemes? For a truly performant p2p networks involving a central signalling server, it is important to reduce latency where possible with p2p latency estimation schemes involving BGP and cached internet routing graphs.<p>This would help provide developers with an alternative to blindly matching peers, which will usually result in worse than possible latency if multiple peers have the content being requested.<p>Currently you can get an approximation of this feature by building on top of MaxMind's GeoIP database, but it's non-free and possibly not as precise for this purpose as other methods[1][2], although it is much easier to use.<p>[1]: <a href="http://nowak.ece.wisc.edu/infocom09.pdf" rel="nofollow">http://nowak.ece.wisc.edu/infocom09.pdf</a><p>[2]: <a href="https://www.cs.montana.edu/~utkarsh.goel/docs/MickaPcpICCCN15.pdf" rel="nofollow">https://www.cs.montana.edu/~utkarsh.goel/docs/MickaPcpICCCN1...</a>