- four ETH2.0 implementation teams.
- the libp2p project leads here at Protocol Labs.
to collect impressions, perspectives and suggestions in a neutral, unbiased fashion.
The report is out. It’s concise, eloquent, and well-founded. Read it here:
This document will help grease the wheels of an unprecedented collaboration in the space of P2P networking. After all, the decentralised web is built atop unstoppable networks. Why reinvent the wheel at every project out there? Fragmentation is involution, not evolution. Why not unite communities to build a modular, rock-solid OSS library that any project can rely on?
My key takeaways from this report are:
Co-funding libp2p work with the Ethereum Foundation: we need to establish a public pathway for talented teams/engineers to acquire funds to hack on libp2p.
- We’ve long talked about formalising a DevRFP programme that encourages experimentation and heterogeneity, and we need to expedite this.
- So far, we’ve issued (or pre-approved) a series of discretionary grants for teams that have approached us directly, examples being jvm-libp2p (Harmony) and nim-libp2p (Status.im).
The libp2p team at Protocol Labs needs to scale. We need to HIRE MORE TALENT, FASTER.
- We need to onboard a brilliant, full-time, multi-lingual (Go, Rust, JS, Java, etc.) go-getter within the next weeks/month to act as a forward-deployed engineer for ETH2.0 teams.
- They’ll engage hands-on with them to advise, hack, debug, optimise and iron things out, informing into the libp2p community and engineering efforts to help us improve the technology.
- Interested in working full-time on libp2p and ETH2.0? Fit the description? Apply below, or ping me via DM on Twitter:
Forward conversations to structured, collaborative discussion channels. The hub-and-spoke model of me serving as a point-person via Gitter, Twitter, Telegram, Email, etc. scales poorly. It fulfilled the goal of jumpstarting this collaboration, but it’s turned inefficient now that efforts have matured, and the need for more structure has manifested.
- The libp2p team/community at large are fully/better qualified to answer many questions.
- There’s a person tasked with monitoring these forums, and watching that posts get answered promptly and accurately: @yusef. Refer to the forum operation protocol.
- Discussing here – rather than privately or across venues – creates a running, public indexable knowledge base that (a) seeds future searches, (b), serves as publicly referenceable material, (c) enables people to lurk and level up their knowledge by observing.
- There’s enough libp2p expertise in the world for users to answer other users’ questions, and we should leverage that by transforming this community into a collaborative vortex – which is also the hallmark of successful OSS ecosystems like the Apache Software Foundation.
- Begin to norm on community alignment and governance processes. Challenges we’ve identified include: keeping implementations in sync as specs evolve, conformance test kits, efficient and expeditious RFC/spec’ing process, addressing compatibility issues, continuous interoperability testing, conflicts of interest between implementations, unified/single-point-of-entry documentation site, etc.
Encourage folks to report concrete issues: the more concrete you get with voicing out issues or concerns, the more readily people will help you. It’s in your best interest. If you can lend a hand to fix whatever is broken, plus points! Remember: libp2p is an OSS project, not a monetised product with customer support.
- When reporting technical issues, attach log outputs, CPU profiles, heap dumps, etc. Specify the environment and explain steps for reproduction are. Be available for follow-up questions.
- When suggesting improvements, remove the frustration and emotion out of the discourse. State how the dysfunction impacts you objectively, and propose the solutions you can think of. We’re building this community together. We’re not perfect, but we’re friends, and we want to make things rock’n’roll for everyone.