Today, protocol design discussions often take place in a repository of an IPFS implementation. These conversations are unintentionally obscured from the useful input of Specs Stewards, other implementations, service operators and the wider IPFS Community.
The IPFS Project needs a mechanism for proposing and evaluating specification improvements that are not tied to a specific programming language or implementation of IPFS.
Adopt an informal IPIP process for the ipfs/specs repository, providing a minimal structure for opening, reviewing, and merging specification changes.
The purpose of IPIP documents is to document motivation behind the change applied to the spec. IPIP is not to be the spec itself.
ipfs/specs/IPIP/000N-webdav-gateway.mdwould only include Motivation and explainer why certain design decisions were made at a certain point in time. Initial
IPIP/000N-webdav-gateway.mdwould explain why we added WebDAV spec in the first place.
ipfs/specs/IPIP/000M-webdav-fix-for-foo.mdexplaining why we make the breaking spec change, compatibility/migration considerations etc.
Up-to-date process and IPIP lifecycle will be published in [ipip-process].
Changes to IPFS specifications can be proposed by opening a Git pull-request
(PR) against the
In addition to specification changes, such PR must include a short IPIP
document based on the template in
When a new specification file is added to the repo, it should be based on
the template at
Specs Stewards will review new IPIP PRs during periodical (best-effort) triage.
IPFS Community is encouraged to participate in the review process.
IPIP can be either:
The final decision belongs to Specs Stewards.
PR with a IPIP can be merged only after two Specs Stewards approve it and there are no objections from other Stewards.
IPIP number is assigned before the PR merge.
IPIP author and two approving Specs Stewards are added to
to be automatically asked to review any future changes to files added or
modified by the IPIP.
Specs Stewards will adjust the process based on usage patterns.
We want to empower IPFS community members and implementers with the ability to propose changes in a well-known way, without introducing much overhead.
End users will indirectly benefit from a healthy IPIP process being in place:
As a result, IPFS will become easier to implement, useful in more contexts, and benefit more people.
Existing contents of ipfs/specs repository act as the initial state against which IPIP PRs can be opened.
Existing Git-based review infrastructure, user accounts and reputation system will be reused.
Merging IPIP will require approval from two Specs Stewards.
Copyright and related rights waived via CC0.