Response to a recent Twitter debate

Ecosystem and Community
1

In this post I want to respond to a recent debate on Twitter, started by this Tweet.

Before I start, for those that don’t know me, I am Max, libp2p maintainer, working at Protocol Labs, focusing on protocol design (GitHub - libp2p/specs: Technical specifications for the libp2p networking stack) and the libp2p implementation in Rust (GitHub - libp2p/rust-libp2p: The Rust Implementation of the libp2p networking stack.). As a disclaimer, before working at Protocol Labs, I worked at Parity and I’ve been part of the libp2p ecosystem for ~3 years.

I think the debate touches many problems that are worth further discussing. I hope to help these discussions by adding more context. But also I would like to use the chance to share my more positive view on these aspects of libp2p.

I would appreciate and encourage people to join the discussion in the comments below. My only ask is to do so in a constructive manner. I look forward to your feedback on how libp2p can improve.

Modularity in libp2p

- It’s plagued by “we’re keeping this modular”

Yes, one of the core principles of libp2p is modularity. Contrary to seeing it as a downside, I see it as one of libp2p’s greatest strengths.

Modularity has its costs and challenges. It adds confusion, e.g. when having to choose which protocols to use in which scenario and how to integrate them into a larger application. It adds complexity, e.g. when wrapping a hash into a multihash, then a multibase and then a multiaddr. It adds overhead, e.g. when negotiating the set of supported protocols via multistream-select instead of just using a fixed set.

That said, I think it also has many upsides. Multistream-select allowed us to deprecate SecIO and adopt Noise with zero downtime or breaking changes across the networks. Multiaddr allows implementations to select transports based on context (QUIC, TCP, WS), and it even allows us to adopt new ones (e.g., WebTransport, WebRTC) in the future without breaking compatibility with older versions. The modularity on protocols allows the many users of libp2p (e.g., Ethereum2, Polkadot, IPFS, Filecoin) to use different sets of protocols, while sharing the same network core. It even allows them to communicate with each other.

Overall I am convinced that the modularity of libp2p is net positive.

libp2p specifications

- “Still no precise specs on many aspects after 5 years of shouting that a spec is needed”

Yes, we could do better specifying libp2p, especially for projects in the past that predated the spinoff from IPFS (e.g., Kademlia). I know what it feels like to work on libp2p while at the same time not working at Protocol Labs (see disclaimer above).

I think we have been improving here in recent times, setting a good precedent on projects like GossipSub andCircuit Relay v2. These examples were spec first and have had active community engagement with the specs and implementations.

There are no plans to back down from the specs-first approach (see the WebRTC and WebTransport protocols).

I know most of the contributions on GitHub - libp2p/specs: Technical specifications for the libp2p networking stack are from Protocol Labs folks - but that definitely isn’t the desired state. I think we at Protocol Labs need to be more inviting to the community, encouraging others to contribute to the specification. Suggestions on how we can make it easier for others to contribute here very welcome too!

libp2p as an open project

- “Talking to the people who decide is like talking to a deaf person”

On that last point I’ve been generally optimistic and friendly in 2017 and 2018, but the constant frustration that I’ve received when everything I say is completely ignored (not answered, ignored) has made me more and more annoyed. To be honest I’m not even trying anymore.

I can see why Pierre feels this way. Still I don’t think it is correct. What I think he confuses here is the difference between ignoring someone and hearing someone’s arguments but deciding against it. Two recent examples:

I am generally trying to reply to every comment on the various GitHub repositories. I don’t think anyone from the community is being ignored. Please share in case you disagree or I am missing something.

DoS defense in libp2p

- Several protocols don’t understand anything about DoS resilience

I don’t think DoS resilience has gotten as much attention in libp2p as it should have. That said, I think we made a lot of progress here, e.g. see the Gossipsub v1.1 evaluation. I would even go as far as saying that libp2p does a decent job on the very hard problem of DoS prevention in a p2p setting.

I think it is fine to discuss this on a high level. What do people think? How can we further improve? Though dear reader, in case you are aware of concrete issues, please responsibly disclose to security@libp2p.io instead.

multistream-select v2 or large changes at libp2p’s core

If you want to make a libp2p person sweat, just say the words “multistream-select v2”

Yes. multistream-select v2 has been a failed project again and again. I have to be honest, the Tweet made me smirk. :smirk:

I don’t think postponing multistream-select v2 in itself is bad, i.e. we have to choose our battles and I think we have chosen wisely. That said I think we could have done a far better job on expectation management, e.g. being very explicit on early stage drafts being early staged drafts.

I encourage everyone interested to get involved on https://github.com/libp2p/specs/pull/349. Though disclaimer, it is very early stage and only a specification for now.

Closing

That is all from my end for now. Thanks for reading. Thanks for your interest in libp2p. I encourage folks to share their thoughts below. Also feel free to contact me directly in case that is preferred.

Max

7 Likes
2

Very much agree (and hats of to you and all the other libp2p maintainers for all the work improving this common good). :pray::pray::pray: Great to see the constructive response to some less-than-constructive feedback :heart:

Re Specs - curious if the spec process needs updating or refining to make it easier for many to contribute new specs – or if a blocker here is missing info on “what specs are needed here”? For the latter, maybe we could add some time in community calls to highlight new draft specs and asks for “specs needed here”?

Re DoS protection - I think important to call out that any application consuming libp2p also needs to think about their own DoS protection for their context (ex, how to set the right limits in the resource manager). There’s a lot of good examples here, but curious if a more detailed “how to” guide would help users thoughtfully consider all the tradeoffs here?

1 Like
3

I do not believe this specification route is working. To see this, I think it’s first needed to define what working would mean. It’s entirely possible to claim specifications are supposed to produce the results they have so far, and by that definition it’s impossible to claim they have failed.

As an example of not working, I’ll point out the short-sightedness of Circuit Relay v2. If a specification has made it to the implemented state and is incomplete, that would be a failing of the specification system IMHO. Circuit Relay can be replaced with circuits across the tor network and leverage the ready to be used network of tor bridges and their infrastructure. The tor project is looking for volunteers to run Snowflake instances. This would seem to be a good symbiotic relationship.

I’ve worked on getting this working, but it breaks the moment I try and have two libp2p applications share infrastructure. The WebRTC Star specs are missing the ability for a signalling server to host multiple projects and this means that some(tor snowflake libp2p) clients would connect and start forwarding tor data, but not be connected to hosts implementing the other protocols they request… There is no way to signal what “network” to try and pair a node up with.

This speaks against the modular system “working” also, though again it depends on how you define things. I’m saying you can’t use the modular system and a WebRTC Star signalling server at the same time. So the WebRTC Star specification should be revisited.

4

@cheako thanks for getting involved here. I am having difficulties to understand the chain of reasoning here. Let me paraphrase what I think I understood:

  • Circuit Relay v2 does not support Tor project circuits.

  • Given that Circuit Relay v2 has been defined via the libp2p specification process and given that it does not support Tor project circuits, thereby follows that the specification process does not work.

  • The WebRTC star specification does not allow using the same signalling server to support both libp2p and Tor.

  • The above two points showcase that libp2p can not be adopted to any environment, and thus the modularity promise of libp2p is not fulfilled.

Let me follow up on a couple of these, though again, I don’t think I fully understand the train of thought here.

Circuit Relay v2 does not support Tor project circuits.

I would see Circuit Relay v2 and Tor as two separate protocols, supporting similar use-cases. I.e. they would live next to each other.

The WebRTC star specification does not allow using the same signalling server to support both libp2p and Tor.

Not sure I understand the motivation here. Though the libp2p WebRTC protocol is currently actively being designed. Thus a good time for you to get involved if you like https://github.com/libp2p/specs/pull/412.

5

I would be curious what others think here. I feel like I am too deeply involved to put myself into the shoes of someone getting started contributing to the specification repository.

Note for those wanting to get involved, we can guide you through the process. No need to understand the whole process by heart upfront.

6

I’m very new here. I’m literally working my way through the example projects, trying to understand how libp2p and P2P networks work, and I’m coming from a background of mostly single-machine, non-networked projects.
I therefore have very little to say about the meat of Pierre’s complaints and arguments.

That said, it is a little disconcerting to me that some of the pages in the main documentation are yet to be written, that they recommend protocols that are marked as “Draft” in the specs, and that some of the tutorials have some glaring issues:

I understand that there may not be the resources to keep all the docs up to date, but it does make the experience feel a little sloppy, and I think this resonates a little with Pierre’s complaints about specifications.

However, without something like libp2p, I wouldn’t have the knowledge to build a well-designed P2P app myself, and I feel like the modular nature of the project means that it should be possible to find and implement solutions to some of the grittier complaints that may or may not be valid.

2 Likes
7

Hey @Gaeel, I’m Prithvi, TPM at PL for libp2p

That said, it is a little disconcerting to me that some of the pages in the main documentation are yet to be written, that they recommend protocols that are marked as “Draft” in the specs, and that some of the tutorials have some glaring issues

I wholeheartedly understand your point. Last week we sat down as a team, triaged the open issues in our docs repo, and and have made significant efforts in recent days to improve our libp2p docs. We’ll be filling out the draft sections and rewriting content over the coming days, weeks, and months.

I would also love to have your input on the existing documentation; whether you think concepts are articulated clearly, whether some sections could be improved, etc. So feel free to open an issue here: Issues · libp2p/docs · GitHub

I also created issues for the js-libp2p point you brought up:

I think for the purposes of Rust example, the existing naive seed is fine but I’ll let @mxinden chime in.

8

Thanks for your input @Gaeel.

The assumption is correct. The u8 as a seed for a keypair is for examples only.

9

I tried to learn this (Rust) crate last year. After spending 3 -4 days, I gave up. (Disclaimer: I am not a newbie in programming, have degree in CS, have a strong background in Networking, etc).

  1. First of all it is poorly documented (close to nothing), and as usually such open source projects have a ready excuse: it is open source, you are welcome to improve it.
  2. I tried to explore and understand the concepts and abstractions. It does make much sense, inter twisted, complicated. You simply jump from one doc page to another. I don’t understand why the author(s) came up with such “abstractions” (drunk?). They don’t simplify P2P programming, or put it into some meaningful framework, where concepts and abstractions hide details and allow focus on higher level. On the contrary, besides the things such as Tcp, IDP, broadcast, etc, you also need to understand (if you can) tons of so called abstractions that are two or three fold the existing networking concepts.

Have a look at the examples in the repo. Start from the simplest Ping example. The Tokio example is much more simpler than this one: Swarm, Behaviour, tracing_subscriber, EnvFilter. Then calls such as
.with_new_identity()
.with_tokio()
.with_tcp()
.with_behaviour(…)
.with_swarm_config
…
swarm.listen_on(“/ip4/0.0.0.0/tcp/0”.parse()?)?; //<= wtf ??
…

Then I had a look at the Kademlia. It is worse that the Ping example.

Rolling your own specific solution seems to be much more easier than spending nights by reading its source code and finally, if you understand anything, locking yourself in this crate. So, I understand the position of tomaka. It is sh…y at least from the point of view design, complexity, documentation.

10

@fade2black I’d be happy to answer some of the questions you had that tripped you up. I bet a quick 20 minutes on our slack channel would get you unblocked: Filecoin Slack #libp2p-implementers

When I first learned rust-libp2p I found the largest hurdle was just mapping the names for things in rust-libp2p to the names of the same things in my head. There are a couple of key abstractions that make libp2p modular that sometimes are a blocker. Your frustration isn’t unique and there is some energy going into explaining rust-libp2p better. Drop into our slack channel and say hello and let’s see if we can get you unblocked.

Cheers! :beers:

11

Hi, you forgot to mention how to join this slack server. The link you posted only allows existing users to log in.

Took me a few minutes to find this invitation link: Slack

12

@btwiuse my apologies. thanks for the correct link.

13

Agreed by your thoughts :slightly_smiling_face:

14

Hey, every amateur of decentralized stuff . Call me Leo.
@mxinden, I love you your sentient attitude.

About issue of contribution complexity
You could read about my understanding of the problem over there
Simply put a potential implementor must:

  • admire concept of libP2P
  • deeply understand it’s principles
  • know high-level abstraction
  • be well acquainted with documentation
  • know where to find an exhaustive specification by a topic
  • know few common interfaces of stream and switch abstractions. And probably some commonly accepted in community practices of implementation(if there’re such)

One who’s not going to contribute with code must know even less.

What I’ve managed to understand only with a pinch of salt and ChatGPT
Flow of a stream building and how all described protocols embedded into it(especially multistream-select)
My current understanding is the following:
Every stream setup process starts from a transport then upgraded.
Every upgrade could intoduce a handshake, message headers, data transformations.
All upgrades could be both negotiated(multistream-select) as preconfigured.
Preconfigured upgrade process not declares protocol IDs as multistream-select does.
There’re two sources of preconfiguration: multiaddress and negotiation via relay.
As soon as preconfigured upgrade terminates all data in a resulting stream gets essentially wrapped with multistream-select’s header declaring protocol ID.
Here’s a list of stream qualities(optional or essential) which could require upgrade:
reliability, order, flow control, encryption, fast recovery, multiplexing, backpressure, compression. Every upgrader or transport could introduce one or several of the qualities.
There’s a special upgrader - multiplexer turning a stream into several.
Streams after a multiplexer are full-fledgeg and could be upgraded forth.

My need help
For now I want contribute into standardization introducing a low-level abstraction of “stream” and “switch”. Stream is simple and described fairly enough. Switch is vice versa something complex. And this is what I’d like to understand better.
Is there a coherent documentation or a pattern of successful implementation for the matter?

15

Sorry for my confusion with “headers” in protocol upgrade description.
Of cause headers is not something of streams domain. Multistream-select just adds a handshake round trip. I’ve updated the understanding or upgrade process over there