Libp2p – A modular network stack
libp2p.io
Libp2p – A modular network stack
1–10 of 34 posts
Re: Libp2p – A modular network stack
#2I went to look at their Go implementation but the libraries are each split into separate Github repos (super annoying) and some of those appear to be non-public/404. Very strange.
Re: Libp2p – A modular network stack
#3I went to look at their Go implementation but the libraries are each split into separate Github repos (super annoying) and some of those appear to be non-public/404. Very strange.
> (super annoying)
Why would anyone store different laguage implementations in the same Git repo?
Re: Libp2p – A modular network stack
#4I went to look at their Go implementation but the libraries are each split into separate Github repos (super annoying) and some of those appear to be non-public/404. Very strange.
> (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.
Re: Libp2p – A modular network stack
#5Earlier 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.
Most of the time, I have a repo be an individual unit of testing. I.e. if the python client is broken, does that mean that the go client is broken as well? A large part of this is because its much easier to support testing multi-repos than mono-repos. Multi repos are generally easier to test because you run the entire suite of tests on every pull request whereas in a mono-repo you have to figure out which tests need to be run. All this isnt to say that its impossible (or not beneficial), but that its easier to have multiple repos with the current testing infrastructure (specifically looking at Jenkins). Another difficulty with mono-repos is merging code when something is broken, how do you know whether you should merge or wait for the bug to be fixed?
Re: Libp2p – A modular network stack
#6Any idea why this is upvoted to make the front page this time?
Re: Libp2p – A modular network stack
#7Just heads up, people should know libp2p (unless something has changed?) still has flooding problems.
There are other P2P transport alternatives, check out SSB's (it is really good!) or ours (gun.eco/docs/DAM) which prevents flooding. WebRTC and websocket implementations exist.
Re: Libp2p – A modular network stack
#8no C or C++? Looks promising but would love a C++ version
Re: Libp2p – A modular network stack
#9no 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.
Re: Libp2p – A modular network stack
#10Earlier 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.
I can't think of any library for which this is the case, could you give some examples?