mirror of
https://github.com/ipfs/ipfs-blog.git
synced 2026-03-28 17:32:37 +01:00
Create 2026-01-ipld-2025-review.md
This commit is contained in:
64
src/_blog/2026-01-ipld-2025-review.md
Normal file
64
src/_blog/2026-01-ipld-2025-review.md
Normal file
@@ -0,0 +1,64 @@
|
||||
---
|
||||
title: "IPLD 2025 Review: From Monoliths to Modules"
|
||||
description: "The year that brought us modular Rust libraries, faster DAG-CBOR, stable multiformats, and a simpler on-ramp with DASL."
|
||||
author: Volker Mische
|
||||
date: 2026-01-20
|
||||
permalink: '/2026-01-year-in-review/'
|
||||
header_image: '/2026-01-rusted-facade.jpg'
|
||||
tags:
|
||||
- ipld
|
||||
---
|
||||
|
||||
# IPLD 2025 Review
|
||||
|
||||
_Cross-posted from the [IPFS Foundation blog](https://ipfsfoundation.org/ipld-2025-in-review/)._
|
||||
|
||||
Whether you're building on [IPFS](https://ipfs.tech/), [Filecoin](https://filecoin.io/), or [ATProto](https://atproto.com/), [IPLD](https://ipld.io/) (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](https://ipld.io/libraries/javascript/) 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](https://github.com/ipld/libipld/commit/6f0028519d60078f062b1fad403e2c783ce3fb2c) the Rust implementation [`libipld`](https://crates.io/crates/libipld). 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](https://ipld.io/docs/codecs/known/dag-cbor/) library [`python-libipld`](https://github.com/MarshalX/python-libipld) to [`cbor4ii`](https://crates.io/crates/cbor4ii) and the latest [Rust `cid`](https://crates.io/crates/cid) version made [Bluesky custom feeds in Python ~2x faster](https://bsky.app/profile/marshal.dev/post/3m6wqrij2es2v).
|
||||
|
||||
## 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`](https://crates.io/crates/ipld-core), which is similar to the deprecated [`libipld-core`](https://crates.io/crates/libipld-core).
|
||||
|
||||
### For encoding/decoding
|
||||
|
||||
**Old way:** Custom `libipld` traits for [DAG-CBOR](https://ipld.io/docs/codecs/known/dag-cbor/), [DAG-JSON](https://ipld.io/docs/codecs/known/dag-json/), and [DAG-PB](https://ipld.io/docs/codecs/known/dag-pb/). [`libipld-cbor-derive`](https://crates.io/crates/libipld-cbor-derive) 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`](https://crates.io/crates/serde_ipld_dagcbor/) for DAG-CBOR
|
||||
- [`serde_ipld_dagjson`](https://crates.io/crates/serde_ipld_dagjson/) for DAG-JSON
|
||||
- [`ipld-dagpb`](https://crates.io/crates/ipld-dagpb) for DAG-PB (not Serde-based since DAG-PB doesn't support the full IPLD Data Model)
|
||||
|
||||
[IPLD Schema-like transformations](https://ipld.io/docs/schemas/features/representation-strategies/) can now be done directly with [Serde attributes](https://serde.rs/attributes.html).
|
||||
|
||||
**Adoption in the wild:** `serde_ipld_dagcbor` is now widely used in the Rust ATProto community, including [rsky](https://github.com/blacksky-algorithms/rsky) (AT Protocol implementation in Rust), [ATrium](https://github.com/atrium-rs/atrium), and [jacquard](https://tangled.org/nonbinary.computer/jacquard) (ATProto/Bluesky libraries).
|
||||
|
||||
## IPLD Schemas
|
||||
|
||||
[@rvagg](https://github.com/rvagg/) made a [big upgrade to the code generation of IPLD Schemas](https://github.com/ipld/js-ipld-schema/pull/135). When you define a schema, you can now generate code for Go, Rust, and TypeScript.
|
||||
|
||||
## Multiformats
|
||||
|
||||
The Rust [multiformats](https://multiformats.io/) implementations are under active maintenance and all actionable items on [`cid`](https://crates.io/crates/cid), [`multihash`](https://github.com/multiformats/rust-multihash), and [`multibase`](https://crates.io/crates/multibase) 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)](https://dasl.ing/) 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](https://github.com/Stebalien/) and [@rvagg](https://github.com/rvagg/) for their countless hours helping maintain various IPLD and multiformats libraries.
|
||||
Reference in New Issue
Block a user