IPLD 2025 Review: From Monoliths to Modules

Cross-posted from the IPFS Foundation blog (opens new window).

Whether you're building on IPFS (opens new window), Filecoin (opens new window), or ATProto (opens new window), IPLD (opens new window) (InterPlanetary Linked Data) — a shared data model for the self-certifying, content-addressable web — ensures your data is portable and verifiable across platforms. This post covers the past year's progress in the IPLD ecosystem and a preview of what to expect in 2026, with a focus on Rust IPLD.

Rust IPLD: From Monolith to Modules

Following the JavaScript implementation's (opens new window) lead, we recognized that most projects only need specific IPLD components rather than the full stack. Earlier this year, we successfully migrated the libipld functionality into separate, focused crates and officially deprecated (opens new window) the Rust implementation libipld (opens new window). This modular architecture is now the standard across all IPLD implementations.

Over the past few months, we helped migrate all actively maintained projects that had updates in the past two years. Many projects had already made the switch on their own.

Performance win: Moving the Python DAG-CBOR (opens new window) library python-libipld (opens new window) to cbor4ii (opens new window) and the latest Rust cid (opens new window) version made Bluesky custom feeds in Python ~2x faster (opens new window).

Migration Guide: What Replaces What

If you're a Rust developer still using libipld, here's your upgrade path:

For IPLD Data Model work

Use: ipld-core (opens new window), which is similar to the deprecated libipld-core (opens new window).

For encoding/decoding

Old way: Custom libipld traits for DAG-CBOR (opens new window), DAG-JSON (opens new window), and DAG-PB (opens new window). libipld-cbor-derive (opens new window) for IPLD Schema-like transformations.

New way: Serde-based crates that go directly from serialization to native Rust types without the IPLD Data Model conversion in between:

• serde_ipld_dagcbor (opens new window) for DAG-CBOR
• serde_ipld_dagjson (opens new window) for DAG-JSON
• ipld-dagpb (opens new window) for DAG-PB (not Serde-based since DAG-PB doesn't support the full IPLD Data Model)

IPLD Schema-like transformations (opens new window) can now be done directly with Serde attributes (opens new window).

Adoption in the wild: serde_ipld_dagcbor is now widely used in the Rust ATProto community, including rsky (opens new window) (AT Protocol implementation in Rust), ATrium (opens new window), and jacquard (opens new window) (ATProto/Bluesky libraries).

IPLD Schemas

@rvagg (opens new window) made a big upgrade to the code generation of IPLD Schemas (opens new window). When you define a schema, you can now generate code for Go, Rust, and TypeScript.

Multiformats

The Rust multiformats (opens new window) implementations are under active maintenance and all actionable items on cid (opens new window), multihash (opens new window), and multibase (opens new window) have been resolved.

Rust multiformats now joins Go and JS in being stable and production-ready, and you can expect mostly minor dependency updates in 2026.

DASL: Starting Simple, Staying Compatible

Not every project needs IPLD's full flexibility. DASL (Data Addressable Structures and Links) (opens new window) offers a streamlined subset: fewer decisions, fewer dependencies, easier to implement. We worked to ensure the DASL specifications remained a strict subset of IPLD, so data created with DASL tools remain seamlessly compatible with the broader IPLD ecosystem.

Thank You

Special thanks to @Stebalien (opens new window) and @rvagg (opens new window) for their countless hours helping maintain various IPLD and multiformats libraries.