about codemp

Yes! You can email us at support@codemp.dev.

You can also reach out on Gitter, but a GitHub or Matrix account will be necessary to write.

As software engineers, we are familiar with the challenges posed by cooperative remote development: low-resolution screensharing, waiting for pushes and having to rebase, and constantly referencing misaligned line numbers.

codemp was born from our own struggles with working together remotely, and is built from scratch to make it easy, with impeccable performance and accuracy.

No, codemp wants to keep your work synchronized in real time, after a live development session you may still want to commit source to your VCS of choice!

Very soon! We are ending a closed beta phase, which will be followed by an open beta for everyone to try it out.

We need your help benchmarking, spotting bugs and adding the finishing touches.

We plan to provide enterprise-oriented software, services and deployments in the future, but at the time our focus is entirely on finishing the core product.

Some examples of future features are fine-grained access control and fully remote development.

If you want to sponsor codemp's future development, get in touch!

Currently hexed.technology, which is also hosting the main server.

The first commit on the main library repo is from 10 July 2022, but most development started happening in late 2023.

Yes: while we provide the main library and all editors as open source software licensed under GPL, the main server is hexed.technology's main product.

We want to fund further development and expanded infrastructure, which is unfortunately not possible without a stable source of revenue.

When developing a system like this, one of the first challenges is adoption: getting an entire team to switch the same editor is unlikely to happen painlessly. Supporting a multitude of plugins in different languages and possibly different architectures, however, is a daunting task even for larger teams.

Our solution to this problem is to maintain a single, common native library, developed in Rust with safety and performance in mind. Via FFI (Foreign Function Interface), we can then access it from any plugin in any language.

This allows us to maintain a single codebase for multiple plugins, rather than one each, at the one-time cost of FFI complexity. Having already largely handled the problem of "glue code", our team can now focus on first-class integration in each editor's API.

Our investigations in the field of text synchronization for multi agent editing showed that there are mostly two approached to solve the problem: Operational Transforms (older, more used) and Conflict-free Replicated Data Structures (CRDTs, a newer technology).

While initial prototypes used OT to achieve synchronization, we quickly found issues. The editor is not under our plugin's control, and could always apply new insertions/deletions while processing remote changes. This was a huge issue with OTs, as it would require control over the integration process.

We introduced CRDTs first with a hand-crafted prototype, and were very impressed by the results. Because of the nature of CRDTs, we have an internal state which is always kept in sync with the server (and all other peers), and this state can then be finely synchronized with the effective editor state. Edits coming while integrating just branch more, and our inner CRDT merges them seamlessly.

We have since swapped our prototype for a more optimized solution backed by diamond-types, with impressive results: we jumped from processing ~2 thousand operations per second to an astonishing ~8 million, a 1000x improvement!

Network layout posed a challenging decision: a distributed system could provide lower latency but a centralized arbiter could dramatically reduce necessary resources for each peer.

We want codemp to be a viable solution for low power devices in unreliable networks, and thus opted for a centralized approach.

While for small work groups the benefits are negligible, bigger sessions dramatically benefit from having a central server which can handle reduntant merging and skip irrelevant operations, all while masking IPs and removing the problem of punching through NATs.

We hope to provide a solution capable of scaling to hundreds or thousands of concurrent users, in order to open new uses in conferences, competitions, teaching and live entertainment.

The underlying network structure is really important to achieving good performance. codemp needs a binary stream to quickly beam operations back and forth.

gRPC provides this, encapsulating primitives in a convenient way, and also provides request/response procedures.

We eventually plan to experiment with Laminar and Cap'n Proto for faster cursor and operation streams, but we will probably retain an http-based approach for workspace management and authentication.