1
0
mirror of https://github.com/ipfs/ipfs synced 2024-11-09 17:38:54 +01:00
ipfs/REQUIREMENTS.md

31 KiB

IPFS Project Requirements to 1.0.0

Table of Contents

Description

In order for IPFS to reach its maturity state, going from Alpha, to Beta and to v1.0.0, the project will need:

  • For its specifications to be 100% complete. This includes the IPFS, libp2p, multiformats and IPLD specs.
  • Compliance tests for the specification.
  • The golang and JavaScript implementations to be 100% complete and spec compliant.
  • A third party implementation of IPFS, fully interoperable with the go and JavaScript versions.
  • A release plan and cycle, including a strategy to support specific key releases for longer periods of time (i.e LTS releases vs stable)

Milestones

Here you will find a comprehensive list of the various challenges and milestones in the IPFS Project to reach version 1.0.0. They are not ordered in any way at the moment, merely grouped.

Sustainability and Governance

These are some of the milestones to hit to create a active, sustainable, inclusive and participatory governance model for IPFS.

  • Organize IPFS All Hands.
  • Have IPFS lead by a Steering Working Group.
  • Define several Working Groups focused on different parts of the project (e.g Community Engagement, Documentation and Education, IPFS in Web Browsers).
  • Define a release plan and long term support plan.

IPFS Use Cases

These are some use case milestones to drive development.

  • Support for file distribution
    • Support for personal file storage, backups, and distribution
    • Support for basic p2p file distribution
    • Support for fast local area network file distribution
  • Support for immutable, permanent links to files, websites, data
  • Support for mutable links to files, websites, data
  • Support for websites and web applications
    • Support for static web applications
    • Support for API based web applications
    • Support for fully dynamic websites entirely on IPFS (eg chat)
  • Support for collaborative seeding/pinning
    • basic support for ipfs ref pinning
    • Cloud ipfs frontend services (cube)
    • clusters of ipfs nodes (RAID/RAIN)
    • byzantine clusters (BA)
  • Support for browsers
    • js-ipfs-api client inside a tab
    • js-ipfs full node inside a tab
    • browser extension gateway redirects
    • browser extension full node
    • impl native inside browsers
  • Support for versioning and archival
    • archival of files
    • archival of data and databases
    • commit based versioning
  • Support other tools or applications via APIs
    • Support for commandline API usage
    • Support for HTTP API usage
    • Support for unix sockets RPC API usage
    • Support for embedded, programmatic API usage
    • Support for HTTP Gateway

Performance Milestones

These are some basic performance milestones to hit.

  • Megabytes / Slow
    • Good enough for small files - MB
    • Good enough for static websites - MB
    • Good enough for distributing webapp code/assets - MB
    • Good enough for images - MB
  • Gigabytes
    • Good enough for personal documents - GB
    • Good enough to stream video on the web - GB
    • Good enough for small scientific datasets - GB
    • Good enough for distributing webapp user data - GB
  • Terabytes
    • Good enough for image collections - TB
    • Good enough for small video collections - TB
    • Good enough for medium scientific datasets - TB
    • Good enough as a package manager (gx) - TB
    • Good enough as a package manager backup (npm-on-ipfs) - TB
    • Good enough as a package manager replacement (npm-on-ipfs) - TB
    • Good enough to distribute small databases - TB
    • Good enough for large (single) archives - TB
  • Petabytes
    • Good enough for large video collections - PB
    • Good enough for large scientific datasets - PB
    • Good enough for Backup Archival - TB/PB
    • Good enough to distribute large databases - PB
  • Exabytes
    • Good enough for massive archives - EB
    • Good enough for the entire web - EB
    • Good enough for top10 websites - EB

Developer Libraries

These are some libraries that must exist to make developers' lives easy. It is critical that making fully dynamic apps on IPFS should be just as easy or easier than traditional systems.

  • file importers for basic files
  • custom file importer tooling
  • ipfs node api bindings
    • ipfs api bindings in Go
    • ipfs api bindings in JS
    • ipfs api bindings in Java
    • ipfs api bindings in Python
    • ipfs api bindings in PHP
    • ipfs api bindings in Ruby
    • ipfs api bindings in Scala
    • ipfs api bindings in Rust
    • ipfs api bindings in Haskell
    • ipfs api bindings in C/C++
    • ipfs api bindings in Erlang
  • full ipfs node implementations
    • go-ipfs - implementation in Go
    • js-ipfs - implementation in JS
  • developer libs for cli tools
  • developer libs for desktop apps
  • developer libs for webapps
    • js-ipfs-api - js api bindings
  • developer libs for mobile apps
    • developer libs for iOS
    • developer libs for Android
  • developer libs for node.js apps
    • go-ipfs-dep - module to install go-ipfs
    • ipfsd-ctl - module to control an ipfs daemon
    • js-ipfs-api - js api bindings
  • developer libs for dynamic webapps (in progress)
    • ipfs-log (CRDT)
    • other "CRDTs on IPFS" libs
    • orbit-db - key-value store and event log
  • developer libs for crypto capabilities
    • typical sharing models over ipfs
  • developer libs for social networks
    • POST datastructure
    • decentralized identity

Security Milestones

  • Network security
    • upgradable transport encryption (multistream)
    • transport encryption: secio (ECDHE)
    • transport encryption: TLS 1.3 (mainstream crypto)
    • transport encryption: CurveCP or MinimaLT (djb crypto)
  • Content Security
    • content security: IPLD hash links (authenticated content)
    • content security: Keychain signed objects
    • content security: native content encryption
    • content security: native crypto capabilities
    • content security: audit
  • Anonymity
    • transport anonymity: tor support
    • transport anonymity: i2p support
    • ship anonymity focused distribution (tor, i2p, no leaking info)
    • peer and content routing anonymity
    • anonymity: audit
  • Anticensorship
    • Anticensorship: decentralized, peering content distribution
    • Anticensorship: access based re-distribution
    • Anticensorship: incentivized distribution
    • Anticensorship: PKI distribution
    • Anticensorship: resilience to powerful sybil attacks on routing
    • Anticensorship: HTTP TLS transport emulation
  • Auditing
    • Audit: full protocol fuzzer tests
    • Audit: test with state of the art exploit test suites
    • Audit: p2p scalability researcher audits
    • Audit: 3x independent professional security audits of full protocol
    • Audit: 3x independent professional security audits of implementations

Network Scalability

The scalability of the IPFS protocol depends on careful design of algorithms and models, careful optimization of our implementations, and careful attention to the security properties of the protocols. Reaching high scalability for self-organizing peer-to-peer protocols is HARD, though definitely achievable. We measure scalability in orders of magnitude, as larger thresholds will require revisiting various parts of our codebase.

Please bear in mind that we are currently still implementing major features of the protocols and reaching implementation completion. We have not yet turned our focus towards scalability, thus there are LOTS of low hanging fruit to optimize and likely many scalability bugs to be worked out. The most important part is to make sure all protocols are meant to scale to billions of nodes, and that they make no centralizing assumptions. All protocols we have chosen make no small scale assumptions and are meant to scale well (typically log(n)).

Our scalability observations are divided into simulations, real network tests, and production networks.

  • Simulations
    • Scalability to 1,000s of nodes
    • Scalability to 10,000s of nodes
    • Scalability to 100,000s of nodes
    • Scalability to 1,000,000s of nodes
    • Scalability to 1,000,000,000s of nodes
  • Real network tests
    • Scalability to 1,000s of nodes
    • Scalability to 10,000s of nodes
    • Scalability to 100,000s of nodes
    • Scalability to 1,000,000s of nodes
    • Scalability to 1,000,000,000s of nodes
  • Production networks
    • Scalability to 1,000s of nodes
    • Scalability to 10,000s of nodes
    • Scalability to 100,000s of nodes
    • Scalability to 1,000,000s of nodes
    • Scalability to 1,000,000,000s of nodes

Polish level

The polish level achieved defined how much effort has gone into polishing all the corners of the tools, APIs, documentation, and so on. Early on, things will be much more rough as we need to focus on implementation speed over final polish. As we reach completion of the implementations, we turn our focus towards scalability, stability, and security. After that, we focus on end user polish.

  • Polish level: alpha - individuals innovators
  • Polish level: alpha - production for early adopters
  • Polish level: beta - production for small orgs (in progress)
  • Polish level: beta - production for large orgs
  • Polish level: 1.0 - production for all

Multiformats

The multiformats are a set of self-describing protocols/formats for future-proofed or "upgradable systems" (systems that make no silly assumptions that are likely to break over time).

  • multiaddr: protocol design
    • multiaddr: impl in Go
    • multiaddr: impl in JS
    • multiaddr: impl in Java
    • multiaddr: impl in Haskell
    • multiaddr: impl in Python
    • multiaddr: impl in Rust
  • multihash: protocol spec
    • multihash: impl in Go
    • multihash: impl in JS
    • multihash: impl in Scala
    • multihash: impl in Java
    • multihash: impl in Clojure
    • multihash: impl in Rust
    • multihash: impl in Haskell
    • multihash: impl in Python
    • multihash: impl in Elixir
    • multihash: impl in Swift
    • multihash: impl in Ruby
  • multicodec: protocol spec
    • multicodec: impl in Go
    • multicodec: impl in JS
  • multistream: protocol spec
    • multistream: impl in Go
    • multistream: impl in JS
  • multibase / baseN: protocol spec
    • multibase / baseN: impl in Go
    • multibase / baseN: impl in JS

libp2p Protocols

The libp2p protocols are the protocol stack for the modular p2p protocols library spun out of IPFS. These form a p2p-first network stack, with no assumptions, self description, and modular interfaces. More at https://github.com/ipfs/specs/tree/master/libp2p

Consult libp2p Requirements here

Bitswap

Bitswap is the exchange protocol of IPFS. It simulates a data market.

  • Bitswap: Protocol and architecture design
    • Bitswap: protocol spec
    • Bitswap: decision engine
    • Bitswap: strategy: altruist
    • Bitswap: strategy: logistic
    • Bitswap: strategy: programmable
    • Bitswap: support for keys
    • Bitswap: support for paths
    • Bitswap: support for selectors
    • Bitswap: hooks for other txns
  • Bitswap: impl in Go
    • Bitswap: testing simulator
    • Bitswap: basic exchange
    • Bitswap: bandwidth accounting
    • Bitswap: decision engine
    • Bitswap: strategy: altruist
    • Bitswap: strategy: logistic
    • Bitswap: strategy: programmable
    • Bitswap: support for keys
    • Bitswap: support for paths
    • Bitswap: support for selectors
    • Bitswap: hooks for other txns
  • Bitswap: impl in JS
    • Bitswap: testing simulator
    • Bitswap: basic exchange
    • Bitswap: bandwidth accounting
    • Bitswap: decision engine
    • Bitswap: strategy: altruist
    • Bitswap: strategy: logistic
    • Bitswap: strategy: programmable
    • Bitswap: support for keys
    • Bitswap: support for paths
    • Bitswap: support for selectors
    • Bitswap: hooks for other txns
  • Bitswap: bssim network simulations
    • Bitswap: bssim: basic in-proc simulation
    • Bitswap: bssim: basic multiproc simulation
    • Bitswap: bssim: basic multi machine simulation
    • Bitswap: bssim: metrics collection
    • Bitswap: bssim: reporting
    • Bitswap: bssim: pluggable strategies
    • Bitswap: bssim: strategies config

IPFS DHT

The IPFS DHT is (today) a Kademlia based DHT implementing several libp2p protocols: Peer Discovery, Peer Routing, Content Routing, and some NAT Traversal assistance.

  • IPFS DHT: Protocol and architecture design
    • IPFS DHT: protocol spec / messages
    • IPFS DHT: kad queries
    • IPFS DHT: kbucketing
    • IPFS DHT: churn resistance
    • IPFS DHT: censor resistance
  • IPFS DHT: impl in Go
    • IPFS DHT: messages
    • IPFS DHT: kad queries
    • IPFS DHT: kbucketing
    • IPFS DHT: churn resistance
    • IPFS DHT: censor resistance
  • IPFS DHT: impl in JS
    • IPFS DHT: messages
    • IPFS DHT: kad queries
    • IPFS DHT: kbucketing
    • IPFS DHT: churn resistance
    • IPFS DHT: censor resistance
  • IPFS DHT: dhtHell simulations
    • IPFS DHT: dhtHell programmable config
    • IPFS DHT: dhtHell in-proc tests
    • IPFS DHT: dhtHell multi-proc tests
    • IPFS DHT: dhtHell multi-machine tests
    • IPFS DHT: dhtHell 1,000 nodes
    • IPFS DHT: dhtHell 10,000 nodes
    • IPFS DHT: dhtHell 100,000 nodes
    • IPFS DHT: dhtHell 1,000,000 nodes

IPFS pub/sub

The IPFS pub/sub service will provide fast delivery and routing for subnets of ipfs nodes. This is critical for dynamic applications. pub/sub (or multicast) will implement: Peer Discovery, Peer Routing, Content Routing, and some NAT Traversal assistance. It fulfills similar roles as the IPFS DHT, but with drastically different performance, security, and scalability guarantees. IPFS Pub/Sub is currently in development.

  • IPFS pub/sub: Protocol and architecture design
    • IPFS pub/sub: protocol spec / messages
    • IPFS pub/sub: record spec
    • IPFS pub/sub: one-hop support
    • IPFS pub/sub: multihop tree forming
    • IPFS pub/sub: churn resistance
    • IPFS pub/sub: censor resistance
    • IPFS pub/sub: topic/channel support
    • IPFS pub/sub: hierarchical topic/channel support
    • IPFS pub/sub: authenticated subnets
    • IPFS pub/sub: private subnets (symmetric)
    • IPFS pub/sub: private subnets (PKI)
  • IPFS pub/sub: impl in Go
    • IPFS pub/sub: prototyping in Go
  • IPFS pub/sub: impl in JS
    • IPFS pub/sub: prototyping in JS
  • IPFS pub/sub: pssim simulations
    • IPFS pub/sub: pssim programmable config
    • IPFS pub/sub: pssim in-proc tests
    • IPFS pub/sub: pssim multi-proc tests
    • IPFS pub/sub: pssim multi-machine tests
    • IPFS pub/sub: pssim 1,000 nodes
    • IPFS pub/sub: pssim 10,000 nodes
    • IPFS pub/sub: pssim 100,000 nodes
    • IPFS pub/sub: pssim 1,000,000 nodes

IPLD

IPLD is the core format for data on IPFS. More at https://github.com/ipfs/specs/tree/master/ipld

  • ipld v0 protobuf: spec
    • ipld v0 protobuf: impl in go
    • ipld v0 protobuf: impl in js
  • ipld: spec
    • ipld: Linking
    • ipld: Pathing
    • ipld: Selector
    • ipld: Query
    • ipld: v0 compat
    • ipld: cbor serialization
    • ipld: links and resolving
    • ipld: streaming support
  • ipld: impl in Go
    • ipld: Linking
    • ipld: Pathing
    • ipld: Selector
    • ipld: Query
    • ipld: v0 compat
    • ipld: cbor serialization
    • ipld: links and resolving
    • ipld: streaming support
  • ipld: impl in JS
    • ipld: Linking
    • ipld: Pathing
    • ipld: Selector
    • ipld: Query
    • ipld: v0 compat
    • ipld: cbor serialization
    • ipld: links and resolving
    • ipld: streaming support
  • ipld: website
    • ipld: website: front page
    • ipld: website: spec
    • ipld: website: about
    • ipld: website: playground
      • ipld: website: playground spec
      • ipld: website: playground impl

IPLD Data Structures and Importers

IPLD data structures and importers are various data structures and programs that covert data or files from other native representations to and from IPLD graphs. Think of these as both the graph representation datastructs, and conversion codecs.

  • unixfs for unix/posix files
    • unixfs spec
      • unixfs file
      • unixfs file sharding
      • unixfs file trickledag
      • unixfs dir
      • unixfs dir sharding
      • unixfs metadata
    • unixfs impl in Go
      • unixfs file
      • unixfs file sharding
      • unixfs file trickledag
      • unixfs dir
      • unixfs dir sharding
      • unixfs metadata
    • unixfs impl in JS
      • unixfs file
      • unixfs file sharding
      • unixfs file trickledag
      • unixfs dir
      • unixfs dir sharding
      • unixfs metadata
  • archives spec
    • tar
    • zip
    • rar
  • keychain spec
    • keychain: keys
    • keychain: sigs
    • keychain: caps
    • keychain: proofs

IPFS Repo

More at https://github.com/ipfs/specs and https://github.com/ipfs/fs-repo-migrations

  • IPFS repo spec
    • IPFS repo impl in Go
    • IPFS repo impl in JS node
    • IPFS repo impl in JS browser
  • IPFS fs-repo spec
    • IPFS fs-repo v0
      • IPFS fs-repo datastore (blocks and metadata)
      • IPFS fs-repo config file
      • IPFS fs-repo lock file
      • IPFS fs-repo logs dir
    • IPFS fs-repo v1
      • IPFS fs-repo version file
      • IPFS fs-repo api file
      • IPFS fs-repo blocks (data)
      • IPFS fs-repo datastore (metadata)
    • IPFS fs-repo v2
      • IPFS fs-repo ipld pinset
    • IPFS fs-repo impl in Go
    • IPFS fs-repo impl in JS node
    • IPFS fs-repo impl in JS browser
    • IPFS fs-repo-migrations
      • IPFS fs-repo-migrations 0-to-1
      • IPFS fs-repo-migrations 1-to-2
      • IPFS fs-repo-migrations 2-to-3

IPFS Protocol and Architecture

  • IPFS architecture: macro protocol architecture
  • IPFS architecture: futureproofing and self-description (multis)
  • IPFS architecture: networking
    • IPFS architecture: encrypted and authenticated connectivity
    • IPFS architecture: peer and content routing
    • IPFS architecture: NAT traversal
    • IPFS architecture: line and pkt switching relay
    • IPFS architecture: abstracting and extracting libp2p
    • IPFS architecture: basic private networks (symmetric encryption)
    • IPFS architecture: advanced private networks (PKI)
  • IPFS architecture: merkle-linked graph and IPLD
    • IPFS architecture: pathing model for fs and web
    • IPFS architecture: selectors for graph traversals
  • IPFS architecture: addressing
    • IPFS architecture: content addressing and resolution
    • IPFS architecture: key addressing and resolution
    • IPFS architecture: other resolver addressing and resolution
  • IPFS architecture: node data sync model
    • IPFS architecture: ref pull resolution and retrieval
    • IPFS architecture: ref push
    • IPFS architecture: ref pinning
    • IPFS architecture: peer-to-peer RPC auth
  • IPFS architecture: projection of protocol to programs
    • IPFS architecture: program model
    • IPFS architecture: service design
    • IPFS architecture: tool design
    • IPFS architecture: core api design
      • IPFS architecture: cli api design
      • IPFS architecture: http api design
      • IPFS architecture: RPC api design
  • IPFS architecture: distribution of programs
  • IPFS architecture: webui design
  • IPFS architecture: app designs
  • IPFS architecture: programmable policy hooks
    • IPFS architecture: bitswap strategies and trading
    • IPFS architecture: data advertising and serving
    • IPFS architecture: social network
    • IPFS architecture: blocklists design
      • IPFS architecture: blocklist support in gateway
      • IPFS architecture: blocklist support in net
      • IPFS architecture: scalable blocklist (bloom)
  • IPFS architecture: clustering
    • IPFS architecture: cluster RAID/RAIN modes
    • IPFS architecture: cluster consensus

Go implementation of IPFS

The go-ipfs effort is the Go implementation of IPFS. It is meant to run as a commandline tool, as a background service, as a programmatic embedded node, through an RPC API, and to be used as part of other tools. go-ipfs is the reference implementation of IPFS. It includes the HTTP-to-IPFS Gateway implementation. More at https://github.com/ipfs/go-ipfs

  • go-ipfs ipfs node components
    • go-ipfs multi protocols
    • go-ipfs component: repo
    • go-ipfs component: networking (libp2p)
    • go-ipfs component: bitswap
    • go-ipfs component: dag / ipld
    • go-ipfs component: pinning
    • go-ipfs component: block api
    • go-ipfs component: object api
    • go-ipfs component: files api
    • go-ipfs component: daemon
    • go-ipfs component: data importing
    • go-ipfs component: gateway
    • go-ipfs component: http api
  • go-ipfs ipfs node api
    • go-ipfs core api impl
      • go-ipfs core api: version
      • go-ipfs core api: daemon
      • go-ipfs core api: id
      • go-ipfs core api: block
      • go-ipfs core api: object
      • go-ipfs core api: refs
      • go-ipfs core api: repo
      • go-ipfs core api: pin
      • go-ipfs core api: log
    • go-ipfs ext api impl
      • go-ipfs ext api: name (ipns)
      • go-ipfs ext api: dns
      • go-ipfs ext api: tar
      • go-ipfs ext api: tour
      • go-ipfs ext api: files
      • go-ipfs ext api: stat
      • go-ipfs ext api: mount
      • go-ipfs ext api: bootstrap
      • go-ipfs ext api: bitswap
    • go-ipfs tool api impl
      • go-ipfs tool api: init
      • go-ipfs tool api: config
      • go-ipfs tool api: update
      • go-ipfs tool api: commands
    • go-ipfs net api impl
      • go-ipfs net api: ping
      • go-ipfs net api: dht
      • go-ipfs net api: swarm
      • go-ipfs net api: records
  • go-ipfs cli api impl
    • go-ipfs cli codecs
  • go-ipfs http api impl
    • go-ipfs http api: streaming
    • go-ipfs http api: multipart

Javascript implementation of IPFS

The js-ipfs effort is the javascript implementation of IPFS. It is meant to run on both node.js and today's regular web browsers. It is close, but not yet ready. More at https://github.com/ipfs/js-ipfs

  • js-ipfs ipfs node components
    • js-ipfs multi protocols
    • js-ipfs component: repo
    • js-ipfs component: networking (libp2p)
    • js-ipfs component: bitswap
    • js-ipfs component: dag / ipld
    • js-ipfs component: pinning
    • js-ipfs component: block api
    • js-ipfs component: object api
    • js-ipfs component: files api
    • js-ipfs component: daemon
    • js-ipfs component: data importing
    • js-ipfs component: http api
  • js-ipfs ipfs node api
    • js-ipfs core api impl
      • js-ipfs core api: version
      • js-ipfs core api: daemon
      • js-ipfs core api: id
      • js-ipfs core api: block
      • js-ipfs core api: object
      • js-ipfs core api: refs
      • js-ipfs core api: repo
      • js-ipfs core api: pin
      • js-ipfs core api: log
    • js-ipfs ext api impl
      • js-ipfs ext api: name (ipns)
      • js-ipfs ext api: dns
      • js-ipfs ext api: tar
      • js-ipfs ext api: files
      • js-ipfs ext api: stat
      • js-ipfs ext api: mount
      • js-ipfs ext api: bootstrap
      • js-ipfs ext api: bitswap
    • js-ipfs tool api impl
      • js-ipfs tool api: init
      • js-ipfs tool api: config
      • js-ipfs tool api: update
      • js-ipfs tool api: commands
    • js-ipfs net api impl
      • js-ipfs net api: ping
      • js-ipfs net api: dht
      • js-ipfs net api: swarm
      • js-ipfs net api: records
  • js-ipfs cli api impl
  • js-ipfs http api impl
    • js-ipfs http api: streaming
    • js-ipfs http api: multipart

IPFS directly on the Browsers

As a protocol for the web, the ultimate goal of IPFS is to run directly in the browsers. We are achieving this through a four-step plan:

  • (1) Implement IPFS in any language, and use a js-ipfs-api library to delegate commands to an IPFS API (e.g. go-ipfs running on localhost). This already works today, and many applications already exist leveraging IPFS in the browser this way.
  • (2) Implement IPFS in javascript, and use js-ipfs directly in the browser tab. This is in progress today.
  • (3) Build browser extensions that use IPFS to serve IPFS URIs and expose ipfs to the browser tab. This can be done using go-ipfs (API on localhost) or ideally a bundled js-ipfs. This is in progress today. The firefox extension already has 400+ daily users.
  • (4) Finally, submit patches to the major browsers adding IPFS support.

We have finished step (1). We are currently working on steps (2) and (3). Step (4) is likely a 2017 endeavor.

  • IPFS API used in a browser tab
    • go-ipfs implementation
    • js-ipfs-api client library
    • use background go-ipfs node (localhost or elsewhere)
  • IPFS protocol running in a browser tab, in js
    • js-libp2p implementation
    • js-ipfs implementation
    • libp2p.js browser library
    • ipfs.js browser library
  • IPFS running with a browser extension
    • go-ipfs implementation
    • js-ipfs implementation
    • firefox extension
      • use background go-ipfs node
      • easy install of go-ipfs node
      • bundling of js-ipfs node
      • url rewriting
      • node management
      • api configuration
      • simple UX for users
      • expose ipfs and p2p in the browser window
    • chrome extension
      • use background go-ipfs node
      • easy install of go-ipfs node
      • bundling of js-ipfs node
      • url rewriting
      • node management
      • api configuration
      • simple UX for users
      • expose ipfs and p2p in the browser window
  • IPFS running natively in a browser
    • go-ipfs implementation (for chrome or firefox)
      • go-ipfs static lib (for chrome or firefox)
    • js-ipfs implementation (for chrome or firefox)
    • rust-ipfs implementation (for servo)
    • chromium patches adding IPFS support
    • firefox patches adding IPFS support
    • servo patches adding IPFS support
    • safari patches adding IPFS support

IPFS Node Management Console (webui)

We have an ipfs node "management console" GUI, delivered as a distributed webapp (dapp). This shows information about an ipfs node, and allows issuing some commands. The webui is entirely hosted and distributed through IPFS itself, demonstrating dynamic web applications on IPFS. More at https://github.com/ipfs/webui

  • webui console architecture
    • R/W privileged API route (:5001)
      • Security: Origin and CORS
      • Security: exposed only locally
      • Security: token based access
    • distributed through IPFS itself
    • accessed through http-to-ipfs gateway
  • webui console v0
    • webapp design
    • basic node info
    • peer map (3D earth)
    • ipfs dag explorer
    • ipfs file viewer
      • listing all files
      • adding files (+ drag and drop)
    • tail logs (json)
    • view & edit config (json)
  • webui console v1
    • webapp redesign
    • peer map (flat and 3D)
    • new dag explorer
    • new file explorer
      • file navigation
      • drag and drop support
      • file previews

HTTP to IPFS Gateway

In order to ease the adoption and deployment of IPFS, we have HTTP-to-IPFS Gateways. This means two related things: (a) implementation of an HTTP-to-IPFS gateway server (currently part of go-ipfs), and (b) a globally accessible service Protocol Labs runs for the community. All of the official IPFS websites are now self-hosted directly on IPFS.

  • HTTP Gateway implementation (in go-ipfs)
    • HTTP Gateway file listing
    • HTTP Gateway /ipfs route for files
    • HTTP Gateway /ipns route for names
    • HTTP Gateway /ipfs POST writes
    • HTTP Gateway /ipns PUT/POST writes
    • HTTP Gateway CORS and Headers support
  • HTTP Gateway Service (ipfs.io)
    • HTTP Gateway Service: solarnet vps infrastructure
    • HTTP Gateway Service: DNS architecture
      • HTTP Gateway Service DNS: deployed at ipfs.io
      • HTTP Gateway Service DNS: dnslink, CNAME, A support
      • HTTP Gateway Service DNS: zone automation
      • HTTP Gateway Service DNS: TLD redundancy
    • HTTP Gateway Service: nginx frontend
      • HTTP Gateway Service: backend fallbacks
      • HTTP Gateway Service: nginx blocklists (dmca)
      • HTTP Gateway Service: rate limiting
    • HTTP Gateway Service Devops
      • HTTP Gateway Service Devops: containers
      • HTTP Gateway Service Devops: automated deployments
      • HTTP Gateway Service Devops: logging
      • HTTP Gateway Service Devops: event monitoring
      • HTTP Gateway Service Devops: status alerts
      • HTTP Gateway Service Devops: status webpage (status.ipfs.io)
      • HTTP Gateway Service Devops: chaos monkey
  • HTTP Gateway Self-hosting
    • HTTP Gateway Self-hosting: ipfs.io project website
    • HTTP Gateway Self-hosting: dist.ipfs.io
    • HTTP Gateway Self-hosting: blog.ipfs.io
    • HTTP Gateway Self-hosting: refs.ipfs.io

IPFS Distributions

IPFS Distributions is the distribution model for IPFS Project programs. This means a repository of pages, source, binaries, and links for all programs officially distributed by the project.

  • IPFS Distributions: architecture
  • IPFS Distributions: security
    • IPFS Distributions: TLS cert for HTTP site
    • IPFS Distributions: code signing
      • IPFS Distributions: code signing source
      • IPFS Distributions: code signing protocol
      • IPFS Distributions: code signing team yubikeys
  • IPFS Distributions: website
    • IPFS Distributions: website design
    • IPFS Distributions: website landing page
    • IPFS Distributions: website program listings
    • IPFS Distributions: website domain (dist.ipfs.io)
    • IPFS Distributions: website localization
  • IPFS Distributions: tools
    • IPFS Distributions: go-ipfs
    • IPFS Distributions: ipfs-update
    • IPFS Distributions: ipget
    • IPFS Distributions: fs-repo-migrations
    • IPFS Distributions: gx, gx-go
    • IPFS Distributions: station
    • IPFS Distributions: webui

Security

  • Create a bug bounty program for IPFS
  • Have IPFS go and js implementations be fully Audited
  • Create a Security Working Group
  • Create a responsible disclosure program

IPFS Blog and Newsletter

In order to keep the community updated, we run a blog. This blog is distributed through IPFS itself, and through an email newsletter.

  • ipfs blog
    • blog design
    • distribute through ipfs
    • blog.ipfs.io domain
    • use POST datastructure
  • weekly/newsletter
    • establish newsletter process
    • highlight contributions and contributors
    • post to the blog
  • email subscription
    • use tinyletter
    • post weekly
    • post blog