2026-09-03 –, Room4
What if data formats didn't need their own libraries? The cylf ecosystem leverages WebAssembly to make codecs, format drivers, and storage drivers modular, sandboxed, and fetchable on-demand. Each can be developed independently and on its own lifecycle. We'll demo a working proof of concept.
Zarr, Parquet, COG: we treat different formats as distinct, each requiring its own libraries, its own codecs, its own tooling. But look closer: each one chunks data, encodes those chunks, linearizes them into a stream, and attaches metadata that explains how to read it back. The differences are real, but they are surface-level. The underlying structure is shared. If that's true, why do we build tooling as if these formats are fundamentally different things?
The cylf ecosystem takes this question seriously. It is a new open-source effort to build a shared, format-agnostic codec layer. Codecs are specified declaratively and resolved on demand from a bundled native standard library, or as sandboxed WASM modules fetched by registry identifier or by URI, the same way a browser fetches and runs code from the web. Data producers declare which codecs their data requires; consumers resolve and run them automatically, with no environment setup, no out-of-band coordination, and no need to trust the codec author.
Codecs compose into pipelines defined as JSON DAGs, with typed ports and explicitly declared encode and decode directions. Asymmetric codecs, where the two directions have genuinely different shapes, are wired naturally rather than inverted by the runtime. Data copies are accounted for at every step boundary, down to zero where adjacent steps use native implementations. Looking further out, the same model could extend upward to format and storage drivers, letting formats, access protocols, and codecs each evolve on their own lifecycle.
The project includes a spec and a Python proof-of-concept library, both developed with partial support from the NASA-IMPACT VEDA project. We demo the library with COG encode and decode, with Parquet as the next target. Along the way we present a survey of 60+ codecs across Zarr, TIFF, Parquet, ORC, HDF5 and others with their signatures and composition properties, and a taxonomy of what those codecs must know about the data—bytes only, stride, dtype, or full dimensional structure—which is where our answer to the opening question comes from. We also present preliminary benchmarks, including one result that turned out to measure something quite different from what we set out to measure. We are seeking collaborators, critical feedback from the standards and data formats communities, and institutional support to build a native reference runtime.
Jarrett Keifer is a Senior Geospatial Software Engineer at Element 84, a commercial geospatial consultancy that uses open-source to build effective customer solutions. His interests include education and outreach, geospatial data formats, and high-performance systems/network programming. He enjoys designing systems to operate at scale, particularly to support remote sensing data processing and earth science applications, and has over ten years of experience contributing to open source projects.