// HACKER NEWS — CYBERSECURITY
Prolly: A content-addressed ordered map built on prolly trees
Prolly publishes the prolly Rust library crate. Users depend on the
package as prolly-map, while code imports stay concise:
use prolly::{Config, Prolly};.
The crate provides content-addressed prolly tree storage primitives: an
immutable, ordered key-value index over byte keys and byte values, with stable
content-derived structure for efficient structural sharing, diff, merge, and
bulk loading.
At the API boundary, a Tree is a small persistent handle:
The actual nodes live in a pluggable Store. Operations clone and rewrite only
the affected path or subtrees, write new content-addressed nodes, and return a
new Tree handle.
All storage-backed tree work is implemented once by a runtime-neutral,
async-first engine. AsyncProlly uses it directly;
Prolly drives the same complete operation through an inline
ready-only adapter. The synchronous path does not create a runtime, park a
thread, or dispatch store calls to Tokio.
The same diagram is also rendered as
diagram/prolly-tree-architecture@2x.png
for contexts that prefer raster images.
The full end-user documentation set lives in docs/, with getting
started material, guides, cookbook recipes, architecture, design spec,
implementation notes, roadmap, and language-porting guidance. The canonical
cookbook is docs/cookbook.md.
Native approximate nearest-neighbor indexing is documented in
docs/proximity-map.md.
Breaking changes and release qualification are recorded in
CHANGELOG.md.
The browser app in
3rd/prolly-tree-visualizer executes
mutations against this repository's real @crabbuild/prolly-wasm binding and
renders the resulting content-addressed tree, lookup paths, structural diffs,
and storage history.
For application builders who want a Git-like repository layer on top of prolly
trees, see the proposed prolly-vcs design. It
keeps prolly-map focused on immutable ordered maps while outlining a separate
crate with a general backend-neutral KvStore substrate for commits, refs,
reflogs, patches, merge orchestration, sync planning, and repository-level GC.
All update APIs are persistent. The old Tree handle remains valid as long as
the store still contains the nodes it references.