It's hard to believe that it was 2025 only two weeks ago, but all the same we'd like to wrap the year up tidily and look back at what happened in content addressing leading up to 2026!
"Content addressing?" you say. "Is there enough going on around content addressing to write a year in review post?" Content addressing has many uses, but two salient ones include trusting that you're getting the data you really want and ensuring that data can be independently verified without relying on the power of a centralized authority. It's easy to see how those two features are key to facing today's challenges. Over the past decade, the IPFS community has been at the forefront of making content addressing practical and accessible. Today, thousands of projects build on it, from decentralized websites and scientific data repositories to verifiable archives and supply chains.
The IPFS project began as an integrated full stack—content addressing, data formats, and peer-to-peer networking bundled together. Over time, it has evolved into a suite of technologies that work well together but also make sense independently.
This post focuses on one pillar: content addressing — the building blocks that let you identify, verify, and link data by what it contains. These tools (IPLD, multiformats, CIDs) are network-agnostic: you can use them with peer-to-peer systems, client-server architectures, or anything in between. The other historic pillar of IPFS, peer-to-peer networking, is a story for a future post.
# Modularity
Closer to home, about a year ago we said that we wanted to focus on making the IPFS technology suite more modular, adopting the principle that it should operate more in line with the good old-fashioned tenets of Unix philosophy: small tools strung together to assemble great power (if not always with great responsibility). For all that it may be accepted wisdom that the best-laid plans of mice and men often go awry, looking back over 2025 we're delighted to see that this one panned out.
In truth, the community was already ahead of us here, quietly shipping tight, purpose-built libraries for CAR, IPLD, and other primitives in the IPFS family. Together, over the past year, we’ve made real progress on modularity through community-wide efforts – spanning standards work, new specifications, and rethinking how our core libraries are structured.
And dawg, how best to show off modularity by giving you a year-in-review post (about Rust IPLD) (opens new window) in this year-in-review post? Check out how we got a 50% speed improvement (opens new window) in the Python wrapper around the Rust lib and other great boosts from migrating off of the old libipld and to more modular implementations.
This year also saw lots of action in the DASL (opens new window) space. If you don't know DASL, it's the part of the IPFS family that's laser-focused on adoption, interoperability, and web-style systems that need to be resilient in the face of dubious code, open-ended systems, and — gasp — potentially high volumes of users. DASL is all about modularity and tiny specs that mesh together like small Unix tools. (Read our introduction to DASL (opens new window) from earlier this year.) In addition to simple subsets of CIDs (opens new window), CAR (opens new window), and DAG-CBOR (aka DRISL (opens new window)), DASL also supports HTTP retrieval (RASL (opens new window)), packaging metadata (MASL (opens new window)), and bigger data (BDASL (opens new window)). And before you ask: yes, we do have a resident acronym expert on staff.
We're driving interoperability between implementations thanks to the amazing test suite (opens new window) that the Hypha Worker Co-Operative (opens new window) built based on an IPFS Foundation grant. (They wrote about the testing work (opens new window) on this very blog.) Looking at test suites over the weeks has been cause for celebration: where initially there had been red everywhere — because no one writes perfectly interoperable code without a test suite — we can see green growing fast with increasing alignment across the board. And this very interoperability has made it possible for us to submit an Internet Draft lovingly titled The tag-42 profile of CBOR (opens new window) (after the CBOR tag for CIDs) to the IETF. This draft covers DASL CIDs and DRISL, and is particularly interesting in the context of ongoing discussions to standardize higher-level parts of the AT protocol at the IETF, like the “repository sync” operated over (DRISL-encoded) personal data servers by relays polling them for recent changes.
We hold monthly virtual meetings for the content addressing community, alternating between CID Congresses (presentations and discussions) and DASLing groups (hands-on working sessions). They’re always on the 3rd Thursday of each month – subscribe to the CID Congress Luma calendar (opens new window) to join.
# Ecosystem Tooling
One of the joys of working on a truly open ecosystem is that you get genuine surprises. In July a new IPFS client, identifying itself as P2Pd and written in Python, that none of us had ever heard about launched and within only a few days skyrocketed to power 15% of the IPFS public network (Amino), now stabilizing near 10%.
Also within the Python community, growing number of geospatial projects have been using IPFS and contributing new tooling. One example is the ORCESTRA Campaign (opens new window), an international field study of tropical convection over the Atlantic Ocean. It generated large volumes of observational data from aircraft, ships, and ground stations to study how tropical storms form and organize. ORCESTRA chose IPFS as their distributed storage layer to make datasets immediately accessible, verifiable, and resilient to single points of failure — addressing pain points from previous field campaigns where centralized systems were too slow for day-to-day scientific work. ipfsspec (opens new window) brings IPFS into the Python data science ecosystem by implementing the fsspec (opens new window) interface, the same abstraction layer used by xarray, pandas, Dask, and Zarr for remote data access.
The University of Maryland’s EASIER (Efficient, Accessible, and Sustainable Infrastructure for Extracting Reliable) Data Initiative has also released ipfs-stac (opens new window) v0.2.0, a pivotal tool for onboarding and interfacing with geospatial data via STAC (opens new window) APIs on IPFS.
Of note is how they have a straightforward tooling reuse approach in which they prepare data to work with IPFS and integrate with Kubo, as can be observed in their codebase (opens new window). We've been interested in IPFS tooling for geospatial work and for scientific data in general, and this is as good an example as they get.
One thing that content addressing is useful for is data management, notably data provenance and attaching verifiable attestations to data sets for governance or compliance purposes. Within that space, we've been impressed with EQTYLab's product suite (opens new window) that uses IPFS primitives for precisely those purposes. It simply looks slick and eminently usable.
And lest we forget: Bluesky blew past 40 million users this year, the growing AT ecosystem has over 400 apps with daily activity, and the community has shipped many libraries for all major languages to work with AT data and protocol components. Not too shabby for a content-addressed social network. (See our write-up of AT and the Eurosky event (opens new window) from November.)
# Performance and Usability
It's been a great year for Kubo, shipping seven major releases up to the latest and shiniest v0.39 (opens new window). But the number of releases is less impressive than what was in them and if it feels like you're breathing dust right now it might be from Kubo's radical performance improvements. The DHT system was rebuilt from the ground up and the new "sweep" provider (opens new window) is able to efficiently provide hundreds of thousands of CIDs without tickling your memory or risking open warfare with your ISP. This joins Bitswap improvements that have demonstrated 50-95% bandwidth improvements and 80-98% message volume reduction in testing. Even better, those CIDs can now be served directly from your node to browsers using AutoTLS (opens new window), automatically setting up the certificate needed to make Secure WebSocket connections work in many places they could not previously. Conversely, Kubo is now able to fetch from HTTP so that you can use battle-tested HTTP infrastructure to serve content to IPFS networks.
Helia scored a big win shipping verified fetch (opens new window), a drop-in replacement for the classic Fetch API that verifies data for you. In turn, verified fetch powers the mighty Service Worker Gateway (opens new window) which is a key component that will allow us to phase out HTTP gateways entirely very soon. This makes IPFS all the more usable in the browser, without the end-user needing to manually install anything.
Iroh too had a rocking year with no fewer than 19 releases (and there I was thinking Rust made shipping hard…) and adding over 4,500 GitHub stars inside of 2025. They added support for many protocols, including live audio/video (working with Streamplace (opens new window)!) and many of those like gossip or blobs compile to WASM and run in the browser. The community growing around Iroh is nothing short of amazing, having brought us Typescript bindings (opens new window), Alt-Sendme (opens new window) (with 4,500 stars of its own in Q4 alone!), high-performance end-to-end testing platform Endform (opens new window), wallet Fedi (opens new window), or Strada (opens new window), a collaborative suite for creative teams that need high-speed access to massive media content.
And the standards appreciators among you have some meaty, perhaps even gamey from long maturation, specs to sink your teeth into: the UnixFS (opens new window) format used by most IPFS systems that expose some form of file system abstraction and Kademlia DHT (opens new window), which describes how DHT-based IPFS networks make it possible for nodes to find content from one another.
We also have the CID Profiles (opens new window) specification almost, almost finished. CIDs have a lot of options, which is great whenever you need to take a Swiss Army chainsaw to your content identifiers but can make it challenging to get two people to generate the same CIDs (and therefore to verify content) as they need to be using exactly the same options. Profiles solve this by listing all the possible options so that they can be easily shared between parties that need to talk.
# Events With A Wide Community
One of our areas of focus this year (and we're not about to stop!) was to find out more about how our stack or content addressing in general could be used to solve problems that people have across the board, from syncing data faster to helping save democracy with more governable protocols (which, yes, content addressing does help with). We do this by meeting people where they are, learning about the problems you have across many domains and walks of life.
This included our own Hashberg (opens new window) event in Berlin of course, but also so much more. We did attend a number of web3 events, such as the excellent ProtocolBerg (opens new window), LabWeek (opens new window), and DevConnect (opens new window), but we deployed more energy connecting with the wider world. This included hacking heavies like the Local-First Conference (opens new window), FOSDEM (opens new window), and Web Engines HackFest (opens new window), as well as more ecosystem-like events like Eurosky (opens new window), DecidimFest (opens new window), the Cypherpunk Camp (opens new window), and classics like Re:publica (opens new window) or MozFest (opens new window). We also hopped over to Japan to see how content addressing might work with the Originator Profile (opens new window). We rubbed elbows with research and standards communities at the Dagstuhl Seminar (opens new window), the Public AI Retreat (opens new window), and of course the IETF (opens new window).
We also went well outside of tech and into the real world at RightsCon (opens new window), the French AI Summit (opens new window) and its FreeOurFeeds (opens new window) side event, the IGF (opens new window) notably with its workshop on social media infrastructure, the Summit on European Digital Sovereignty (opens new window), and the UNDP (opens new window)'s event on governance innovation. It's been a whirlwind of a year and we've learned a lot that continues to inform our work.
We'll be announcing more in 2026 but you can already catch us speaking at FOSDEM in early February (both Mosh (opens new window) and Robin (opens new window)), as well as at the AT Proto meetup on the Friday prior (opens new window), and ATmosphereConf (opens new window) in March. And look for Volker speaking on An Open, Decentralized Network for Metadata (in German) at FOSSGIS Göttingen (opens new window)!
# Looking Ahead
As we ride into the reddened sunrise of 2026, looking ominously stylish as four horsepeople are wont to, we already have a batch of goodies we've been preparing.
We want to extend the capabilities of our current content-addressing stack, especially for large data. Watch out for exciting announcements in the pipeline around geo data and verifiable range requests that work over vanilla HTTP. We're also continuing our partnership with the always-brilliant Igalia (opens new window) and hope to bring a number of improvements to ye aulde browsers, notably for streaming verification.
We've also been talking with our friends at Streamplace (opens new window) about collaborating on specs for a usable subset of C2PA (opens new window) and deterministic MPEG-4 containers so that you can watch content-addressable videos about content addressing. Another potential collaboration with secure chat providers and others who'd like to align on web-app containers might happen. It's still early days, we'll be sure to keep you posted as soon as there's even just a public description of the problem that covers more than me being a tease about it.
Overall, we'll be bringing more of the same. We'll keep working on modularization, interoperability, and adoption. We'll keep investing in test suites and implementations as needed. We'll keep pushing the IPFS family of technologies forward until it's so consistently easy to use that you stop noticing it entirely, until it's so straightforward you need not think about anything other than the specific problem you wish to solve.
Finally, the most important thing that we look forward to in 2026 is your participation. Everything we did in 2025 was to make things better for you and was always informed by what we heard from people or observed in the wild. Next year will be no different — but for that to work we need to hear from you! There's many ways you can reach out: you can post on the forum (opens new window), you can hit @ipfs.tech (opens new window) up on the Bluesky, you can open an issue on the relevant repo, come talk to us at an in-person event, or join any of the meetings on the IPFS Calendar (opens new window) that strikes your fancy. The rumors are true: we do bite; but we only bite the bad people, so come talk!