InterPlanetary Improvement Proposals

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 langua

#1

Web sites often need to redirect from one URL to another, for example, to change the appearance of a URL, to change where content is located without breaking existing links (see [Cool URIs don't change](https://www.w3.org/Provider/Style/URI), [link rot](https://en.wikipedia.org/wiki/Link_rot)), to redirect invalid URLs to a pretty 404 page, or to enable URL rewriting. URL rewriting in particular i

#2

Currently, the HTTP Gateway only allows for UnixFS deserialization of a single UnixFS file. Directories have to be downloaded one file at a time, using multiple requests, or as a CAR, which requires deserialization in userland, via additional tools like [ipfs-car](https://www.npmjs.com/package/ipfs-car). This is to illustrate we have a functional gap where user is currently unable to leverage tru

#288

Currently, the gateway supports requesting data in the [DAG-PB], RAW, [CAR] and TAR formats. In addition, it allows for traversing of links encoded through CBOR Tag 42, as long as they are intermediate links, and not the final document. It works on both DAG-CBOR, and its JSON representation, DAG-JSON. However, it should be possible to download deserialized versions of the final JSON/CBOR document

#328

Idiomatic and first-class HTTP support for delegated routing is an important requirement for large content routing providers, and supporting large content providers is a key strategy for driving down IPFS content routing latency. These providers must handle high volumes of traffic and support many users, so leveraging industry-standard tools and services such as HTTP load balancers, CDNs, reverse

#337

Currently, the gateway allows for trustless retrieval of data under the `/ipfs` namespace, but fetching the data as a CAR, or Block, and then verifying it locally. This is especially important for light IPFS clients, so that they can retrieve data from other gateways without delegating any of the trust to them. Unfortunately, this is not possible under the `/ipns` namespace. In contrary to DNSLin

#351

One of the motivations of this document is to introduce simple to use HTTP APIs and ultimately reduce barrier for interaction across alternative systems. Expanding on the motivations of :cite[ipip-0337], the work here concentrates on delegation of IPNS over HTTP API. Naming is part of the core IPFS DHT functionality. The performance of naming system over the IPFS DHT can suffer from long delays d

#379

IPFS implementations should support content moderation, particularly when it comes to deployments of publicly-accessible infrastructure like gateways. The first step in a larger strategy to enable decentralized content moderation in IPFS setups is to agree in a denylist format that different implementations can rely on and share.

#383

When hosting a modern Single Page Application on IPFS, one wants to use native URLs to share the app with other users, e.g. `ipns://example.org/cool/feature`. On traditional hosting, deep links are redirected or rewritten to a single entry point, e.g. `/index.html`, and the router on the client side evaluates the path segments to render the correct content. The `_redirects` file, defined in :cite

#386

:cite[trustless-gateway] solves the verifiability problem in HTTP contexts, and allows for inexpensive retrieval and caching in a way that is not tied to a specific service, library or IPFS implementation. This IPIP improves the performance related to trustless HTTP gateways by adding additional capabilities to requests for CAR files. The goal is to enable a client capable of translating/decodin

#402

The main motivation for this change is to allow servers to respond faster to the client with provider records, as soon as they are available. In the current state, the client requests a list of providers for a CID from the server. Then, the client has to wait for the server to collect their final list of providers. After that, the server can respond with the full list of providers. This is a big

#410

We want to make it easier to build light-clients for IPFS. We want them to have low memory footprints on arbitrary sized files. The main pain point preventing this is the fact that CAR ordering isn't specified. This requires keeping some kind of reference either on disk, or in memory to previously seen blocks for two reasons. 1. Blocks can arrive out of order, meaning when a block is consumed (d

#412

The motivation of this IPIP extends the one of :cite[ipip-0337] and :cite[ipip-0379], which introduced delegated content routing and delegated naming, respectively. Now, we expand upon those basis to introduce peer routing, reducing the barrier for interaction across different systems.

#417

IPNS record creation and validation is overly complex due to the legacy of decisions made in 2021. The "V1+V2" record creation and validation was reverse-engineered and documented the current state in [ipfs/specs#319](https://github.com/ipfs/specs/pull/319), which created a base for specifications to improve upon. A quick refresher on how IPNS Record lifecycle works today (2023 Q2): - _Record C

#428

Browser nodes and other resource-constrained clients need to perform peer discovery operations without the overhead of being full DHT clients. The primary use case is for browser nodes performing random walks to find peers that they can make circuit relay reservations on. Currently, to find peers close to a particular key in the DHT keyspace, a node must: 1. Be a full DHT client with all the asso

#476

IPFS aims to allow ubiquitous data exchange across different runtimes and platforms. One of the most challenging aspects of this goal is the diversity of network conditions and capabilities across different environments. Web browsers have a very limited network stack, and most web browsers do not support the full range of network transport protocols that are commonly used in other IPFS implementat

#484

While CIDs and UnixFS DAGs are cryptographically verifiable, the same file or directory can produce different CIDs across UnixFS implementations, because DAG construction parameters like chunk size, DAG width, and layout vary between tools. Often, these parameters are not even configurable by users. This creates two problems: - **Broken hash semantics:** Unlike standard hash functions where iden

#499

Identity CIDs are unique in that they inline data directly into the CID itself rather than hashing it. Without clear limits, this creates several problems: 1. **Resource Exhaustion**: Poorly written clients could encode large payloads as identity CIDs and propagate them through the network, consuming bandwidth and resources without providing value. 2. **Security Vulnerabilities**: Identity CIDs

#512

The current Delegated Routing V1 HTTP API specification requires servers to return HTTP 404 (Not Found) when no matching records are found for a query. This creates two significant problems: 1. **Browser Console Errors**: When routing queries are made from web browsers and return 404s, browsers log error messages to the console that cannot be prevented programmatically. These error messages confu

#513

The [`Accept`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept) HTTP request header can be sent with an HTTP request to provide a prioritized list of response formats the client will accept for a given resource. The [`format`](https://specs.ipfs.tech/http-gateways/path-gateway/#format-request-query-parameter) URL query parameter can also be sent to an IPFS HTTP Gateway

#523

When sending an [Accept](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept) header or [format](https://specs.ipfs.tech/http-gateways/path-gateway/#format-request-query-parameter) query parameter to specify the response format of a request, the IPFS HTTP Gateway specs [allow translation](https://specs.ipfs.tech/http-gateways/path-gateway/#accept-request-header) of the reque

#524