Live data from Hacker News

Libp2p – A modular network stack

libp2p.io

11–20 of 34 posts

Re: Libp2p – A modular network stack

#11
post #4
post #3

Earlier quoted context omitted.

> (super annoying) Why would anyone store different laguage implementations in the same Git repo?

Repo should be organized around project, not language/frameworks. It’s perfectly normal to have library +Python client + Go client in same repo.

In this case, the project (at least from the Go standpoint) is broken into multiple sub-projects, each within their own repo. In Go Land, you would more typically see each component library put in its own subdirectories off of the main repo. The main repo could contain libraries for multiple languages or just one, but the subcomponents would be organized as subdirectories, not separate repos.

Re: Libp2p – A modular network stack

#12
post #4

Earlier quoted context omitted.

Repo should be organized around project, not language/frameworks. It’s perfectly normal to have library +Python client + Go client in same repo.

I can't think of any library for which this is the case, could you give some examples?

https://github.com/google/flatbuffers

Re: Libp2p – A modular network stack

#13
post #9
post #8

no C or C++? Looks promising but would love a C++ version

Same here, except I prefer C since that makes it more accessible. That would also allow others to write clients for their favorite languages.

I'd also prefer a C version, but I think it's possible to call a Go function from C [0]. I don't know how well that would work though, since Go requires a runtime.

[0] https://github.com/golang/go/wiki/cgo#calling-go-functions-f...

Re: Libp2p – A modular network stack

#16

What are some concrete examples for which this would be useful? Near the end it says it's being developed by people in the IPFS community. Does anyone know for what they plan on using it?

It is what IPFS is built with, essentially they built out IPFS and made everything modular. It is being used in a lot of blockchain projects since it is so easy to develop with and write your own protocols.

Developing with the library essentially comes down to protobuf serialization logic inside a router with the path being the name of your protocol, just like you would in rails or node, everything else is handled by the library. To talk to a peer over your protocol you just need their address on the network (public key), your protocol name and to serialize your protobuf data to be written over the network, the libraries handle dialing/routing through connected peers if its not possible to directly connect to the peer.

Re: Libp2p – A modular network stack

#17

What are some concrete examples for which this would be useful? Near the end it says it's being developed by people in the IPFS community. Does anyone know for what they plan on using it?

Hi, libp2p dev here!

Yes, we use it today! libp2p is the P2P Networking Stack of IPFS that we refactored into its own project so that others could take advantage and be part of its ecosystem as well.

It is what gives IPFS and other projects the P2P connectivity, support for multiple platforms (including Browsers) and more! There are 3 implementations interoperable today at different stages of completion (Go, JS for Node.js & Browser and Rust). Full overview here https://www.youtube.com/watch?v=CRe_oDtfRLw

Also, Chris Pacia recently delivered an amazing talk at QCON about libp2p https://www.infoq.com/presentations/blockchain-libp2p, I totally recommend checking it out.

You can find more talks of examples and use cases at https://libp2p.io/media.

Give it a spin and post feedback on github.com/libp2p. We are also on #libp2p on freenode, come say hi!

Re: Libp2p – A modular network stack

#19
post #4
post #3

Earlier quoted context omitted.

> (super annoying) Why would anyone store different laguage implementations in the same Git repo?

Repo should be organized around project, not language/frameworks. It’s perfectly normal to have library +Python client + Go client in same repo.

Is it? The Google repo posted by 'orangea is maybe the first one I've seen.

I mean, let's flip it around: when I need a lib for language X, why would I want to download it also for languages V, Y, and Z (+ all language-specific cruft)? Especially in this day and age, when dependency management in project involves build systems pulling repos automatically?

Or, put another way, library is one project. Python wrapper/client is a different project. Go wrapper/client is yet another project. Etc.

Post reply on HN