Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Libp2p – A modular network stack

libp2p.io

Post reply on HN
Print view View original

21–30 of 34 posts

Re: Libp2p – A modular network stack

#21

Post by whyrusleeping »

marknadal wrote: post #7

Just 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.

Hey Mark, pretty sure you're talking about floodsub, which is a naive implementation of pubsub of top of libp2p, not actually 'libp2p'. Libp2p is quite a bit more than a simple p2p pubsub library.

In any case, floodsub is just one option you can use for pubsub on top of libp2p (one with a notably high level of reliability and minimal cross network latency for infrequent messaging). We also have a tree pruning gossiping implementation called gossipsub. Take a look at the spec: https://github.com/libp2p/specs/blob/master/pubsub/gossipsub...

Re: Libp2p – A modular network stack

#23

Post by pjmlp »

codr4 wrote: post #9
mempko wrote: 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.

Simple, C++ with an additional extern "C"{} set of entry points.

C++'s improved safety over C, while providing such accessibility.

We are after all talking about network protocols, where security should be number one feature.

Re: Libp2p – A modular network stack

#24

Post by pjmlp »

TheAceOfHearts wrote: post #13
codr4 wrote: post #9

Earlier quoted context omitted.

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...

C also requires a runtime, it just happens to be a very tiny one.

Re: Libp2p – A modular network stack

#25

Post by tribler »

whyrusleeping wrote: post #21
marknadal wrote: post #7

Just 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.

Hey Mark, pretty sure you're talking about floodsub, which is a naive implementation of pubsub of top of libp2p, not actually 'libp2p'. Libp2p is quite a bit more than a simple p2p pubsub library. In any case, floodsub is just one option you can use for pubsub on top of libp2p (one with a notably high level of reliability and minimal cross network latency for infrequent messaging). We also have a tree pruning gossipi…

That is very interesting spec, but also alarming. It contains:

> The meshsub router offers a baseline construction with good amplification control properties, which we augment with gossip about message flow.

This is notoriously hard to get right. How to prevent spam, posioning or Sybils in your gossip network? Scientific work on p2p overlays and gossip is hard to publish now at venues like Usenix or NSDI. After Newscast from 2003 it seems you need strong identity to make these systems attack resilient. An unsolved problem.

Thank you for this insight! We will put a university student team on exploring this likely vulnerability in IPFS/libp2p.

Re: Libp2p – A modular network stack

#26

Post by marknadal »

whyrusleeping wrote: post #21
marknadal wrote: post #7

Just 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.

Hey Mark, pretty sure you're talking about floodsub, which is a naive implementation of pubsub of top of libp2p, not actually 'libp2p'. Libp2p is quite a bit more than a simple p2p pubsub library. In any case, floodsub is just one option you can use for pubsub on top of libp2p (one with a notably high level of reliability and minimal cross network latency for infrequent messaging). We also have a tree pruning gossipi…

Nice, thanks for clarifying, I stand corrected. This is great to hear/see, do you guys also have benchmarks yet?

Re: Libp2p – A modular network stack

#27

Post by orbifold »

TheAceOfHearts wrote: post #10
sytelus wrote: 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?

LLVM has python, go, ocaml and c bindings all in the same repository https://github.com/llvm-mirror/llvm/tree/master/bindings (the c bindings live somewhere else)

Re: Libp2p – A modular network stack

#28

Post by hobofan »

TheAceOfHearts wrote: post #13
codr4 wrote: post #9

Earlier quoted context omitted.

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...

There is also a Rust implementation of libp2p[0]. Exposing C functions from that library is probably the most "proper" way currently feasible to use libp2p from C.

[0]https://github.com/libp2p/rust-libp2p

Re: Libp2p – A modular network stack

#30

Post by kodablah »

chrissnell wrote: post #2

I 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)

Also found it very annoying using it. Coupled with the multi-whatever repos, that they make backwards incompatible changes, and they use IPFS paths in some of their imports (iirc) made for a non-welcoming library experience.

Post reply on HN