IPFS Specifications

This repository contains the specs for the IPFS Protocol and associated subsystems.

• Documentation and Community
• Understanding badges
• Index
• Contribute
  • InterPlanetary Improvement Process (IPIP)

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.

Index

The specs contained in this and related repositories are:

• IPFS Protocol:
  • IPFS Guide - to start your IPFS journey
  • Protocol Architecture Overview - the top-level spec and the stack
• User Interface (aka Public APIs):
  • HTTP Gateways - implementation agnostic interfaces for accessing content-addressed data over HTTP
  • IPFS implementations may provide additional interfaces, for example:
    • Legacy HTTP RPC API exposed by Kubo (go-ipfs)
    • Programmatic Core API for JavaScript
• Data Formats:
  • IPLD - InterPlanetary Linked Data.
    • DAG-CBOR - binary format, supporting the complete IPLD Data Model, with excellent performance, and suitable for any job.
    • DAG-JSON - human-readable format, supporting almost the complete IPLD Data Model, and very convenient for interoperability, development, and debugging.
    • DAG-PB - a binary format for specific limited structures of data, which is highly used in IPFS and UnixFS.
    • CAR - transport format used to store content addressable objects in the form of IPLD block data as a sequence of bytes; typically as an application/vnd.ipld.car file with a .car extension
  • Self Describing Formats (multiformats):
    • multihash - self-describing hash digest format.
    • multiaddr - self-describing addressing format.
    • multicodec - self-describing protocol/encoding streams (note: a file is a stream).
    • multistream - multistream is a format -- or simple protocol -- for disambiguating, and layering streams. It is extremely simple.
• Files / Mutable File System:
  • UnixFS
  • Mutable File System (the Files API) - Virtual File System interface, unix like, on top of the MerkleDAG
• Storage Layer:
  • Pinning Service API
  • Repo - IPFS node local repository spec
    • FileSystem Repo - IPFS node local repository spec
• Block Exchanges:
  • Bitswap - BitTorrent-inspired exchange
• Key Management:
  • KeyStore - Key management on IPFS
  • KeyChain - Distribution of cryptographic Artifacts
• Networking layer:
  • libp2p - libp2p is a modular and extensible network stack, built and use by IPFS, but that it can be reused as a standalone project. Covers:
• Records, Naming and Record Systems:
  • IPNS - InterPlanetary Naming System
    • IPNS over PubSub - IPNS over PubSub Router
  • DNSLink
• Other/related/included:
  • PDD - Protocol Driven Development

Contribute

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.

InterPlanetary Improvement Process (IPIP)

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

See:

• IPIP: Improvement Process for IPFS Specifications.
• List of IPIPs

Accepted proposals can be found in the IPIP/ directory.