<p>So I made this: <a href="https://github.com/Animus-Network/p2p/">https://github.com/Animus-Network/p2p/</a> </p>
<p>I could definitely use feedback. It's pretty bad IMHO. My end goal is to implement a completely easy to plug (modularized) cryptocurrency purely in GoLang under an MIT license and I have everything else pretty well under hand, but I've been stuck on p2p networking. </p>
<p>Currently I have this API built out to be pluggable with registered functions, much like the HTTP package. However I'm not sure it can handle consensus well. </p>
<p>If anyone else has some experience and can dump some knowledge on me, that would help a boatload.</p>
<hr/>**评论：**<br/><br/>tcrypt: <pre><p>Checkout <a href="https://github.com/libp2p/go-libp2p" rel="nofollow">libp2p</a>. It's pretty easy to use and robust. We're using it and it's working much better than our previous attempts.</p></pre>igknighted: <pre><p>Been checking it out. The "robust" part of it is actually neck breaking almost. The documentation seems lacking, or I'm possibly just missing some info somewhere.</p></pre>tcrypt: <pre><p>I'm not sure what you mean about the robustness being "neck breaking".</p>
<p>Sure, it could be better. I think the documentation in the repo is pretty good, the <a href="https://github.com/libp2p/go-libp2p/blob/master/examples/echo/main.go" rel="nofollow">examples</a> are pretty thorough, and there's a good community on the <a href="https://discuss.ipfs.io/" rel="nofollow">Discourse</a> chat and in the #ipfs channel on freenode.</p>
<p>libp2p has been completely reliable for us; we're yet to experience an issue with it.</p></pre>igknighted: <pre><p>Hey, thanks for the reply mate. Bear with me, I've got a decent knowledge set for most things, but my p2p implementation knowledge is really limited. This ended up being a longer than planned post. </p>
<p>It just seems way over complicated for an API. When I think "library" + go, I guess I imagine an API that simplifies everything. I actually couldn't even get that example working, and that is truly due to a lack of trying honestly. </p>
<p>I get that it was modularized out of ipfs (great system :D) however I don't see why a metric boat load of imports should exist in the most basic example. That's probably the neck breaking part for me. I can't justify it because I can't find a clear overview that explains each part. That and the fact a simple 'go get' and 'go run' against the example failed. When I say there is a lack of documentation I kind of expect some docs for each package and a doc explaining how and why they tie together. (maybe I missed a page somewhere?) </p>
<p>Don't get me wrong, not saying it's bad or good, I literally can't say. I'm aiming for something simplified that can just do some tasks and abstracts the net portion away without a while new way of writing an app. </p>
<p>I'm writing a p2p system that does the work while making usage as easy as the http package. I just hope I'm not coding this from scratch and find out what I made already exists, ya know? </p>
<p>I do plan to revisit libp2p periodically. Right now it seems that some of what I think is missing doc-wise might be due to how new it really is. </p>
<p>Anyway, going to plus your comment because you're providing good deets. I might just need to spend more time learning libp2p and help with it. </p></pre>igknighted: <pre><p>Also, just wanted to kinda follow up and show what I am talking about with getting the package as a whole: </p>
<pre><code>[igknighted@server dir]$ go get github.com/libp2p/go-libp2p-conn
# github.com/libp2p/go-libp2p-conn
../../github.com/libp2p/go-libp2p-conn/conn.go:90:17: c.maconn.SetDeadline undefined (type transport.Conn has no field or method SetDeadline)
../../github.com/libp2p/go-libp2p-conn/conn.go:93:17: c.maconn.SetReadDeadline undefined (type transport.Conn has no field or method SetReadDeadline)
../../github.com/libp2p/go-libp2p-conn/conn.go:97:17: c.maconn.SetWriteDeadline undefined (type transport.Conn has no field or method SetWriteDeadline)
../../github.com/libp2p/go-libp2p-conn/conn.go:126:2: not enough arguments to return
../../github.com/libp2p/go-libp2p-conn/conn.go:126:17: c.maconn.Read undefined (type transport.Conn has no field or method Read)
../../github.com/libp2p/go-libp2p-conn/conn.go:131:2: not enough arguments to return
../../github.com/libp2p/go-libp2p-conn/conn.go:131:17: c.maconn.Write undefined (type transport.Conn has no field or method Write)
../../github.com/libp2p/go-libp2p-conn/dial.go:121:9: maconn.SetReadDeadline undefined (type transport.Conn has no field or method SetReadDeadline)
../../github.com/libp2p/go-libp2p-conn/dial.go:123:32: cannot use maconn (type transport.Conn) as type io.ReadWriteCloser in argument to multistream.SelectProtoOrFail:
transport.Conn does not implement io.ReadWriteCloser (missing Read method)
../../github.com/libp2p/go-libp2p-conn/dial.go:129:9: maconn.SetReadDeadline undefined (type transport.Conn has no field or method SetReadDeadline)
../../github.com/libp2p/go-libp2p-conn/dial.go:129:9: too many errors
</code></pre></pre>GentooMonk: <pre><p>update your go, it seems like you're using an old version of Go.</p></pre>igknighted: <pre><p>Not trying to be flamey and I'm coming from a sincere place here. I'm kinda frustrated after figuring out what's up (way too much wasted time). I'm not frustrated at you <a href="/u/GentooMonk">/u/GentooMonk</a>, nor anyone else really. I'm just frustrated in the current state of the go-libp2p repo and wont be using it. </p>
<p>So I actually figured out the problem. I'm on the latest and greatest, 1.9, that has nothing to do with the compile issues. The problem with libp2p is actually multiple issues that just build into a fluster cluck of <code>bad management</code>. After careful review and scrutiny, they are heavily relying on <code>gx</code>, which is a heaping pile of hot garbage and the guys managing the go-libp2p repo (+related repos) are currently managing this wrong with no consideration to how developers are actually using Go. </p>
<p><code>gx</code> - This is a package manager or dependency handler if you will. It's nothing new in the Go world. We already have <code>glide</code> and various other solutions to handle version management. However the guys that made it literally made it to avoid conventions that are in place to standardize the language. </p>
<ol>
<li><p>Lack of knowing how to <code>git</code> - If you check out how the repos for libp2p are being managed, there are no tags. The only indication of versioning is in the commit messages. This is a poor convention that is being completely overlooked, probably because of the reliance of <code>gx</code>. For a library using <code>semver</code>, it is failing to follow that standard that they are using in their internal systems. I can't even take this project seriously. I burst out laughing when I saw this heaping pile of a bad joke. </p></li>
<li><p>The potential of <code>go-libp2p</code> is being hindered from being a usable solution in many existing projects. It's faster to write a new implementation for some projects than the time it would take to redo the dependency management systems a developer may already be using. I'm not a fan of <code>glide</code> either, but <code>glide</code> doesn't sit there dumping things into an arbitrary directory in your GOPATH's source directory and it doesn't edit your code. It is much easier to implement that <code>gx</code> is in an existing monolithic project. It also can handle versioning of various different types. </p></li>
<li><p>Converting go-libp2p into a thing that actually does follow conventions would be an effort of epic proportions. I seriously sat there reviewing the amount of work it would take. <code>gx</code> is not what I would call production ready. It also wont easily tell you where it is getting packages from. I did end up getting go-libp2p completely through manual tasking. To automate it is just too much of a hassle. </p></li>
</ol>
<p>Anyway, that's just a brief breakdown of actual problems I see with go-libp2p. It seems that I'm actually making headway on what I'm building and I guess it's good-enough. I can't find any p2p libraries in go that just make gossip protocol implementation easy. With some TLC I can probably make it a good solution, despite it being horrid to look at right now.</p></pre>GentooMonk: <pre><p>oh wow i didn't realize that, that's horrible.</p></pre>
