Hacker News new | ask | show | jobs
Libp2p – p2p network stack (github.com)
123 points by erggo 3673 days ago
4 comments

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.

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. :)

- Go: https://github.com/ipfs/go-libp2p

- js: https://github.com/diasdavid/js-libp2p

- specs: https://github.com/ipfs/specs/tree/master/libp2p

brb, 8hr flight.

This is great, looking forward to a comparison between this and https://github.com/tendermint/go-p2p, maybe we'll manage to merge them or choose one or the other.
Once the interfaces are relatively stable can one expect C bindings?
Probably worth mentioning in the title that this is part of the IPFS project, not just another library.
The fact that libp2p is so compatible with current transport protocols gives me lots of hope for ipfs one day replacing http.
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.

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.

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.

[1]: http://nowak.ece.wisc.edu/infocom09.pdf

[2]: https://www.cs.montana.edu/~utkarsh.goel/docs/MickaPcpICCCN1...

BTW, we have MaxMind's GeoIP Lite database (we asked first) stored directly on IPFS, indexed with a b-tree. see https://github.com/ipfs/ipfs-geoip :) -- it's what powers our webui globe.
we do not yet measure latency, we really need to and have been wanting to for some time. could you help us with this?

IP address signals are good, but we must maintain real measurements of all our connections to be able to adjust over time. also, with things like cjdns and tor, IP addresses wont help much.

I'd love to get network quality estimation at various levels -- as close to the wire as we can for proper measurements, but also across layers of the stack to quantify overheads and so on.

Would love to see how transports like QUIC improve things like parallel fetching of blocks.