Repository navigation
Replies: 2 comments
|
Some notes for Road to Devcon, 2026 and IETF hackathon participants interested in exploring IPFS Helia in details alongside Kubo, CID and CBOR-42. Also, the value proposition of Helia and its future, quick comparison with Kubo. Helia is the lightweight, modular JavaScript/TypeScript implementation of IPFS (InterPlanetary File System) designed to run natively in web browsers and Node.js. It completely replaces the js-IPFS project. [1, 2, 3] The Value Proposition of HeliaHelia’s main goal is to bring the decentralized web directly into the browser without making your app slow or heavy. [4, 5]
The Future of HeliaThe future of Helia is tightly tied to making the decentralized web completely invisible and seamless for normal internet users. [11]
[1] https://discuss.ipfs.tech |
Grant Problem Statement: Making Helia Easier for iot DevelopersSubmission deadline: December 18, 2026 How might we make it easier for developers to build real-world applications with Helia? We are looking for practical ideas, prototypes, and integrations that improve the Helia developer experience and expand its adoption across:
The goal is simple:
Successful projects should demonstrate a clear developer experience, meaningful interoperability, and a path toward real-world adoption. If we can make Helia easy to use across these environments, it can become one of the primary application-facing adoption layers for IPFS. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hi everyone,
As many of us prepare for IETF 126 in Vienna, I would like to propose two hackathon ideas that I think could make for an interesting discussion during the week, while also feeding into the broader libp2p-2035 conversation.
Rather than proposing another networking tool or dashboard, these ideas are centered around something that I think deserves much more attention within the libp2p ecosystem: CBOR-42, the new IETF Internet-Draft introduced by members of the IPFS community this year.
The draft provides a deterministic and interoperable CBOR profile that can become much more than a serialization format. It has the potential to become a common foundation for portable networking telemetry, reproducible benchmarks, and verifiable measurement artifacts across decentralized systems.
Today, most networking observability ends up as implementation-specific logs, JSON blobs, Prometheus metrics, or vendor dashboards. Those are useful for operators, but they are difficult to reproduce, compare across implementations, archive, or exchange between ecosystems.
What if we instead treated connectivity measurements as first-class, content-addressed objects?
Instead of:
we could have:
The measurements themselves become portable, reproducible, verifiable, and shareable.
That idea led me to two possible hackathon projects.
1. Universal Connectivity Observatory
Measure, verify, and optimize connectivity across decentralized networks.
Rather than asking:
the Observatory asks:
The project would collect standardized connectivity events across libp2p implementations, including:
Every observation would be encoded using deterministic CBOR-42.
For example:
Instead of implementation-specific logs, we would have a common event vocabulary that could be produced by py-libp2p, go-libp2p, rust-libp2p, js-libp2p, or future implementations.
Because the events are deterministic CBOR, they can be hashed, assigned CIDs, stored in IPFS, archived in Filecoin, signed, replayed, and independently verified.
This immediately opens interesting possibilities for:
Rather than building "another dashboard," we'd be building a reusable connectivity intelligence layer.
2. Universal Connectivity Certification
The second idea builds on the same foundation.
Imagine a standardized connectivity certification suite that every libp2p implementation can run.
Tests could include:
Instead of producing a PDF report or benchmark screenshot, the suite would produce a deterministic CBOR-42 artifact.
The resulting report becomes portable and reproducible.
Different implementations—or even different networks such as Ethereum, IPFS, Filecoin, or future agent networks—could exchange certification artifacts rather than screenshots or custom benchmark outputs.
The objective is not to rank networks, but to establish a common language for interoperability, regression detection, and connectivity quality.
Why I think CBOR-42 is the interesting part
For me, the exciting aspect isn't another observability tool.
It's the possibility that CBOR-42 becomes the common representation for networking measurements across the decentralized ecosystem.
If multiple implementations begin emitting deterministic CBOR-42 telemetry, we gain:
This feels like a natural extension of many ideas we've discussed over the years around interoperability, reproducibility, and shared infrastructure.
Just as CIDs standardized how we identify content, perhaps deterministic CBOR-42 can help standardize how we represent networking observations.
Looking toward libp2p-2035
As we think about where libp2p is heading over the next decade, I wonder if observability itself should become part of the protocol ecosystem rather than something every implementation reinvents independently.
Could we eventually have:
all built on open standards like CBOR-42?
That feels like an interesting direction for libp2p-2035, especially as libp2p continues expanding beyond storage and blockchain into AI agents, autonomous systems, edge computing, and other large-scale decentralized applications.
I'd be interested to hear everyone's thoughts, particularly from maintainers across the different implementations and from those attending IETF Vienna. If there's enough interest, this could make for a collaborative hackathon project and perhaps serve as an early exploration of how CBOR-42 might fit into the future of libp2p observability and interoperability.
All reactions