move go-libp2p-core here #1683
move go-libp2p-core here #1683
Conversation
Avoids circular module dependency.
* Use SplitLast to avoid allocating too much. * Avoid converting to/from strings when working with multiaddrs.
* SplitAddr is a simpler way to split an address into a multiaddr and an ID. * AddrInfosFromP2pAddrs converts a set of multiaddrs into a set of AddrInfos.
feat(peer): implement AddrInfosFromP2pAddrs and SplitAddr
Add OpenCensus metrics registration functionality to core
License: MIT Signed-off-by: Jakub Sztandera <kubuxu@protonmail.ch>
* add plaintext/2.0.0 (with ugly protoc hack) * gofmt * gofmt (for real this time) * add `go_package` option to proto files * Revert "add `go_package` option to proto files" 5a543a79bd89d75c9697f852638b8fe56da862f4 * less hacky protobuf imports * add doc comment for PublicKeyFromProto * clean up handshake * go fmt, lol * use network.MessageSizeMax for ggio reader
Replace bytes.Equal -> subtle.ConstantTimeCompare
Return error rather than panic in GenerateEKeyPair
License: MIT Signed-off-by: Jakub Sztandera <kubuxu@protonmail.ch>
avoid duplicate randomly generated keys/peer-ids
* bring back plaintext 2.0.0 with new constructor * fix deprecation comment * rm unused context argument * only check remote id validity if we actually have keys * bring back msgio & simultaneous read/write
1. It's an alias for peer.ID.String 2. fmt.Stringer is the idiomatic way to get a string representation in Go.
marten-seemann
force-pushed
the
merge-core
branch
from
314a871
to
35b0da1
Compare
|
As I have outlined in the issue, I disagree with moving core in the main repo. I have rather strong conviction that applications (and libraries) should not depend on go-libp2p itself except for initialization and tests; everything else only depends on the interface. This is also going to create a ton of work for upstream users, who currently only depend on the core interfaces for application logic (other than initialization and tests). |
|
The last part should be stressed out and very much considered. You are effectively creating a bifurcation point of incompatibility and forcing everyone to change threir code in tandem to accomodate your whims. You really should put more consideration to the ecosystem as a whole and the myriad of libraries and applications that depend on libp2p. |
There was a good discussion about this on #1556. I really appreciate your feedback! Unfortunately, this is a binary decision (either we consolidate, or we don't), and we have to decide one way or the other. I realize we haven't been able to convince each other of our respective opinions. I suggest keeping the discussion on that issue, and use this PR only for conversations about the specifics of the plan. |
marten-seemann
force-pushed
the
merge-core
branch
from
35b0da1
to
0c04675
Compare
marten-seemann
force-pushed
the
merge-core
branch
from
0c04675
to
4553baf
Compare
marten-seemann
force-pushed
the
merge-core
branch
from
4553baf
to
d4e64c7
Compare
There was a problem hiding this comment.
I’m really excited for this as a user and a maintainer. We can stop telling people “You need to reference the correct version of go-libp2p-core when you use go-libp2p. Which version? the one that go-libp2p uses itself…”
I won’t rehash our discussion in #1556, but we can all agree that we want go-libp2p to be easier to use and easier to maintain. I think this is a step in the right direction and in reviewing #1556 I believe the main objections have been addressed.
The last remaining part of #1556.
This PR also:
go-libp2p-testing/mocks/networktocore/network/mocksgo-libp2p-testing/nethelper function for generating peer identities. This is required because currently (until we've forwarded the type, which requires a release), the old and the newpeer.IDare not identical, which breaks the build. These functions were not super useful anyway, it's not that hard to generate a new identity.