Diamond Types: A Rust CRDT for concurrent plain-text editing

Diamond Types' plain-text collaboration boundary

Diamond Types addresses a specific coordination problem: several users or devices need to edit the same sequence of characters while their operations can arrive in different orders, even in a peer-to-peer network with no centralized server. Its intended users are engineers building collaborative editors who need a Rust CRDT implementation or a WebAssembly-based option. The project does not attempt to synchronize arbitrary application state. Its supported model is plain text, corresponding to a list of characters, and the README says work on JSON-style data types is happening on the `more_types` branch.

That boundary matters. A collaborative editor may also need rich text marks, object fields, transactions, presence data, permissions, or application-specific metadata. Diamond Types does not document those capabilities in the repository overview, so they should not be inferred from its sequence-CRDT foundation. The project solves merging concurrent character-list edits, not the wider problem of storing and synchronizing a complete application document.

The README describes the repository as work in progress and says the library is being expanded from a prototype into a fuller CRDT. That statement narrows the adoption case. Engineers can use it to study optimized CRDT structure or build against the current repository, but a project expecting stable release semantics should account for API and implementation changes.

Stable character IDs and the bidirectional edit path

Diamond Types gives every client or device a unique ID. Each character typed or deleted on that device receives an incrementing sequence number beginning at 0. A character is therefore identified by the pair `(client ID, sequence number)`. This gives each position in the document a stable name that does not depend on its current numeric offset in the rendered text.

The internal structures focus on two conversions. First, a local action such as inserting at document position 100 becomes a CRDT operation that can refer to another character's identifier, such as `(B, 50)`. Second, an incoming operation is translated back into a position in the current document representation. This separation lets an operation identify content and ordering without assuming that every peer currently renders the document at identical character offsets.

The repository points readers to `INTERNALS.md`, a Braid user meeting, and a project-specific blog post for deeper explanation. Based on the repository layout, the implementation is more than a thin public wrapper: it includes internal Rust crates, examples, profiling support, benchmark data, test data, and separate build scripts for WASM and Swift. Those artifacts indicate an implementation with performance-oriented internals, although they do not provide a stable compatibility contract on their own.

Positional updates versus operational transform

Diamond Types is designed to interoperate with positional updates, allowing simpler peers to interact with the CRDT through operational transform. This is a material architectural difference from systems that expose only a conventional CRDT operation API or expect every participant to understand the same internal representation.

Positional updates provide a bridge between the externally visible document offset and the CRDT's stable identifiers. The README's example makes the direction clear: a user's insert at position 100 can refer to a position anchored by another client's sequence number, then resolve to a current document position when peers interpret it. Operational transform peers can therefore use their familiar insert and delete semantics at the interface while Diamond Types handles CRDT representation beneath that boundary.

The repository's `Cargo.toml` also contains references to OT test data, and `test_data/` is part of the top-level layout. That supports the stated interoperability goal, but the README does not describe a complete OT wire protocol, compatibility matrix, or versioning policy. Engineers building an OT peer should not assume interoperability merely because the feature is mentioned. They need to inspect `INTERNALS.md` and the relevant repository APIs for the actual operation format.

Installing Diamond Types when Cargo and master differ

The README does not provide a copy-and-paste installation command or a first-use example. It directs Rust users to the `diamond-types` package on crates.io and the package documentation on docs.rs. However, it also warns that the Cargo package is substantially out of date in both API and performance. That warning should determine which source a new engineer uses.

The repository manifest identifies the package as `diamond-types`, version `2.0.0`, edition `2021`, with the ISC license. It requires Rust `1.96.0` because the source uses `std::range::Range`. Workspace members live under `crates/*`, while the root manifest contains dependencies for string storage, run-length encoding, random number generation, serialization, compression, and the internal RLE crate. Optional dependencies also serve WASM and command-line use.

Because no documented first-use API appears in the README and the package-level documentation is external, this review cannot provide a verified executable example without inventing method names. Start with the current package documentation on docs.rs, then confirm whether its API corresponds to the repository's `master` branch. If those differ, treat a crates.io dependency as adoption of the older package, not as an exact build of the repository shown here. The absence of GitHub releases leaves the repository state and Cargo artifact especially important to distinguish.

Rust, WebAssembly, and platform distribution options

Diamond Types exposes three distribution paths through links in the README: the Rust Cargo package, the `diamond-types-node` npm package using WASM, and the `diamond-types-web` browser package using WASM. This makes the repository relevant beyond native Rust applications, although the README does not document installation commands or package versions for the npm distributions.

The repository includes `build_wasm.sh` and `build-swift.sh`, along with `js/`, `npm-pkg-isomorphic/`, and workspace crates. The `Cargo.toml` includes conditional dependencies for WASM and CLI functionality. It also notes that `crc32c` was rejected in favor of `crc` because the latter adds roughly 1 KB to the WASM bundle while `crc32c` adds roughly 10 KB. That is a concrete example of the project making package-size trade-offs for browser delivery.

Platform availability should therefore be separated from package maturity. The repository links Node.js and browser distributions, but it provides no release history for them and warns that the Cargo artifact is stale. The ISC license is declared in both the README and root manifest. No stronger licensing commitment can be inferred from the available files, and downstream packagers still need to inspect the exact source distribution they ship.

Performance claims without a reproducible adoption test

The README calls Diamond Types a high-performance CRDT and describes it as the result of testing how fast an optimized CRDT could become. It links to a post about making it 5000 times faster than competing implementations and adds that performance reportedly increased another 10 to 80 times afterward. Those are project-authored claims, not independent measurements, and no benchmark commands or complete workload definitions appear in the README.

The repository does expose `bench.sh`, `profile.sh`, `bucket_counts.js`, `benchmark_data/`, and several Rust examples, including `examples/profile.rs` and `examples/posstats.rs`. Those files are useful entry points for examining the project's own performance work. They do not establish that a particular application will receive the same result. Text length, operation distribution, edit locality, peer count, memory constraints, and serialization frequency all affect whether a fast core solves an application's cost problem.

For an engineer, the correct claim is narrower: the project is explicitly designed and instrumented for high throughput. The evidence needed for adoption is a reproducible comparison using the intended editor workload and the exact commit or package being deployed. Claims based only on the repository description should not drive a production decision.

Maintenance signals and the cost of moving from Cargo

The repository is not archived, and its last push was on 2026-09-02. That is the available maintenance signal. The repository has no GitHub releases, while the README directly warns that the published Cargo package is out of date. As a result, recent repository work does not translate cleanly into a recent, stable dependency release.

The immediate upgrade cost is API uncertainty. A project pinned to crates.io may use an older API and miss current performance work. A project depending directly on Git may access newer behavior but loses the normal release boundary and must track repository changes itself. Both choices are different from adopting a named release, and the available files do not describe compatibility guarantees, deprecation policy, release automation, or migration notes.

The source uses Rust edition `2021` and requires Rust `1.96.0`, so adopting the repository also requires a toolchain new enough to build it. Workspace dependencies add build and upgrade surface. Plain-text-only support can reduce feature complexity today, but it may also force an architectural migration if an editor later needs JSON-style values. The WIP status makes that possibility a project constraint rather than a minor omission.

Editorial conclusion

Diamond Types fits engineers prototyping high-throughput plain-text collaboration, WASM integrations, or interoperable sequence-CRDT behavior who can work directly against the repository. It is a poor fit for production adoption through `diamond-types` on Cargo, JSON collaboration, or teams needing a documented, stable release process. Verify the current repository API, WASM package status, interoperability expectations, and your own performance and memory requirements before adopting it, because the README explicitly labels the Cargo package out of date.

Frequently asked questions

Official sources

1. Issues
2. josephg/diamond-types on GitHub
3. README