Specs 2.0 & libp2p book
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 1.8k
- Forks
- 320
- Avg merge
- 11d 15h
- Merged PRs (30d)
- 1
Description
(some preliminary brainstorming based on a discussion with @whyrusleeping, @bigs)
Goal
Revise/update/improve libp2p specs and provide clearer usage guidance
List of proposed documents
1. Base wire formats
- multistream select
- multiplex (https://github.com/libp2p/specs/pull/96)
- yamux (https://github.com/hashicorp/yamux/blob/master/spec.md)
- secio (https://github.com/libp2p/specs/pull/106)
- Peer IDs (https://github.com/libp2p/specs/pull/100)
2. libp2p book / Usage
(some of these could be considered specs, others would be non-mandatory "suggested usage" guides)
- a doc describing exactly how these are tied together, a spec for the ‘swarm’
- document describing how dialing works.
- document describing the ‘libp2p api’. Which is not language specific, but a broader description of the capabilities of each subsystem in terms of what it does.
- Better diagrams (see https://github.com/libp2p/libp2p/issues/55)
3. Libp2p ‘builtin’ protocols
- Identify
- Ping
- pubsub
- DHT (https://github.com/libp2p/specs/pull/108)
- Relay
4. Other
- probably also something on NAT Traversal
- Also need a multiaddr spec (there may exist one, but lets make sure its "proper")
Format notes:
- Everything in markdown, organized into a gitbook. Gives us a nice website UI, or users can print it all to a single PDF.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
This is a broad roadmap covering libp2p wire formats, usage guidance, builtin protocols, NAT traversal, and multiaddr documentation. Start by reviewing the existing specs and referenced pull requests, then choose one unchecked document and confirm its scope with maintainers. Done means the selected Markdown document is clear, complete, and organized for the planned GitBook.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- markdown
- Domain
- documentation, networking
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100