IPFS Specifications

Don’t read the specs here! Go to specs.ipfs.tech, it’s a much better experience!

Documentation and Community

Looking for user support?

See Documentation, Discussion Forums, and other Community Resources instead.

Understanding the meaning of the spec badges and their lifecycle

We use the following label system to identify the state of each spec:

• - A work-in-progress, possibly to describe an idea before actually committing to a full draft of the spec.
• - A draft that is ready to review. It should be implementable.
• - A spec that has been adopted (implemented) and can be used as a reference point to learn how the system works.
• - We consider this spec to close to final, it might be improved but the system it specifies should not change fundamentally.
• - This spec will not change.
• - This spec is no longer in use.

Nothing in this spec repository is permanent or even stable yet. Most of the subsystems are still a draft or in reliable state.

Contribute

• Want to propose a change to an existing specification?
• Or add a new protocol?

This works through the InterPlanetary Improvement Process (IPIP). See:

• IPIP: Improvement Process for IPFS Specifications
  • List of ratified IPIPs
  • List of open IPIPs

If you are wondering how to decide between an issue and an IPIP:

• Does Not Need an IPIP:
  • The spec has a bug - something that is plainly a mistake.
  • Adding more details, test vectors, and editorials/cosmetic changes.
• Needs an IPIP:
  • An addition to the protocol that could cause an interop issues.

Suggestions, contributions, criticisms are welcome. Though please make sure to familiarize yourself deeply with IPFS, the models it adopts, and the principles it follows. This repository falls under the IPFS Code of Conduct.