Trending

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

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

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

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

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

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

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

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

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.

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