undefined | Better HN

0 pointsUptrenda1y ago0 comments

It ain't, trust me. No one who promotes Libp2p ever knows how it works much like users of all of Protocol Labs products. The average "engineer" today rarely looks deeper than the title of the tech they use. They are just glorified plumbers plumbing together pipes filled with [redacted.]

You'll waste your time on Libp2p because it already works almost exactly like your own project. It uses a network of relays as a fallback. It does add in hole punching but no one at Protocol Labs understands how a NAT works. So it only works for a subset of NATs (full cone; restrict; specifically with source port preserving delta behaviours.)

Protocol Labs is filled with big egos and midwits. In 2025, I have zero time for bullshitters and I'm going to call them out for it.

0 comments

1 comments · 1 top-level

r3trohack3r1y ago

I’m not sure what you’re going on about.

The rust-libp2p project has worked really well for me and I’m in the guts of it constantly.

Everything has been pluggable in the right ways so far. Adding new behaviors is straightforward. I can plug and play behaviors, or feature flag them, to pump out purpose built binaries.

It seems like a solid foundation for p2p research and productionizing that research. When I want to experiment with a new protocol, I can plug it in as a behavior without having to solve the rest of the stack.

I have a suspicion that in 2025 imma have to rip open the guts of swarm again to tweak connection management (we are aggressive with connections) but that isn’t daunting.

The only gripe I have with rust-libp2p right now is the learning curve (this was my first rust project - which is probably most of it).

j / k navigate · click thread line to collapse