🌳 IPFS Newsletter 205: HTTP, P2P in browsers, Kubo speedup & more

🌳 IPFS Newsletter 205: HTTP, P2P in browsers, Kubo speedup & more
#newsletter
Share this item:

Welcome back to the IPFS Newsletter! After a hiatus, we have many exciting updates to share.

# More HTTP Support Across the IPFS Stack

Multiple IPFS libraries are embracing or adding support for HTTP (usually in addition to Bitswap). Benefits include lower data provision costs, easier integration with existing HTTP libraries and services, and seamless web compatibility.

The next step is adding support for HTTP providing to the DHT (issue #496 (opens new window)). This would let nodes announce themselves as HTTP providers alongside or instead of Bitswap.

# Service Worker Gateway Provides P2P Capabilities in the Browser

The Service Worker Gateway (opens new window) is a browser-based IPFS gateway that uses Service Workers to handle p2p retrieval, hash verification, and other IPFS functionality. Try it out at inbrowser.link (opens new window).

The Service Worker Gateway has been getting a lot of love recently: v1.12 (opens new window) includes configurable timeouts, better error pages, and a signed binary for local deployment. For a deep dive, check out the Service Workers for IPFS on the Web (opens new window) video. (Shipyard (opens new window))

# Drop-in Service Worker Example for App Developers

Here's a drop-in service worker example (opens new window). It intercepts hardcoded requests to centralized gateways, using @helia/verified-fetch (opens new window) to retrieve and verify content directly from peers. (Shipyard (opens new window))

# IPNI Service Update

The IPNI (opens new window), a content routing index for large content providers, suffered service degradation in April, disrupting the ability to find providers for CIDs. The IPNI team has made hardware and software improvements to avoid future disruptions, and service is improving as the newly-upgraded indexers catch up.

In the interim, a new feature (opens new window) in Someguy (opens new window) allows large content providers to run a self-hosted HTTP delegated routing (opens new window) endpoint, providing an immediate remedy until IPNI service was restored.

Join the #ipni channel on the Filecoin Slack (opens new window) to follow along. A Content Routing WG will be meeting biweekly. More: background (opens new window) & latest notes (opens new window).

# 20-40x Speedup for Data Onboarding in Kubo

In the past, adding data to Kubo with ipfs add while Kubo was running was slow due to inefficient provider queue handling. A new optimization (opens new window) in Boxo yields a 20-40x speedup (higher for larger datasets), making it easier to onboard large data sets while Kubo is running. Available in Kubo v0.35 (opens new window). (Shipyard (opens new window))

# Protocol and Standards

# DASL and IETF Draft for CBOR/c-42

DASL (opens new window) (Data-Addressed Structures & Links) is a small set of specs for working with content-addressed, linked data. First released in December 2024, DASL now includes sub-specs for encoding (CID and dCBOR42, which are strict subsets of IPFS CIDs and IPLD), metadata (MASL (opens new window)), and retrieval (RASL (opens new window)) of content addressed data.

The tag-42 profile of CBOR Core (opens new window) was submitted as an IETF Draft on 22 May, paving the way for web-wide standardization of CBOR/c-42 and CIDs. (IPFS Foundation)

# Practical Interoperability for CIDs

The original CID specification (opens new window) was designed for flexibility and future-proofing, supporting various encodings, graph widths, and optimizations. In practice, this flexibility yields multiple CIDs for the same input, making it challenging to establish CID equivalency for the same data across implementations.

Efforts are underway to increase practical interop without losing futureproofing: IPIP-499: CID Profiles (opens new window) proposes a set of standard profiles for UnixFS, and Kubo v0.35 (opens new window) adds new config options (opens new window) towards this goal. For more context, see the lively forum thread (opens new window).

# Amino DHT Spec

The Amino DHT is a distributed key-value store used for peer and content routing records within IPFS Mainnet. It extends the libp2p Kademlia DHT with IPFS-specific features, such as CIDs and IPNS records. Until recently, it had no formal spec beyond the libp2p Kademlia DHT spec (opens new window).

PR #497 (opens new window) addresses this gap with the goal of improving interoperability, security, and clarity across implementations. (Shipyard (opens new window))

# Code and Tools

# 🚢 Releases

# Ecosystem Spotlights

# Services and Providers

# Articles and Tutorials

# Community & Events

If you made it this far, thanks for reading!