any-sync: a sync protocol where providers hold bytes but not meaning

A protocol library, not a product you can install and use

The first thing to understand about any-sync is that the repository does not contain an application. It is a Go module, github.com/anyproto/any-sync, built on go 1.26.0, and the README describes it as a protocol layer for building private decentralized applications. The reference product is Anytype, and the protocol is offered separately so other teams can build on it. The top level of the tree shows where the weight sits: accountservice/ for accounts, acl/ for access control, commonspace/ for the shared space abstraction, consensus/, coordinator/, node/, nodeconf/, identityrepo/, nameservice/, net/ for transport, protobuf/ for the wire format, paymentservice/ and metric/ for the surrounding operations, plus app/, commonfile/, util/ and testutil/. The README points to sync.any.org for the protocol overview of entities and design, which tells you the specification lives outside the code.

Every space is an encrypted DAG reconciled with CRDT updates

The data model is the core of the design. Data in any-sync is stored as encrypted Directed Acyclic Graphs representing chats, pages or databases, and the end-to-end encrypted structure is what keeps an outside party from reading a channel's content. Conflicts are resolved without a consensus protocol. The project states that channels scale because of a Conflict-free Replicated Data Type mechanism with no gas cost, where every change in the DAGs is cryptographically signed, and each device independently applies and cryptographically verifies CRDT updates to reach a consistent final state. The motivation section explains why that choice: blockchains handle global consensus tasks such as identity, access control and payments well, but storing every encrypted message or document change on every node would be impractical, so the protocol adds a communication layer paired with a decentralized, strictly ordered list to get permissionless, zero-knowledge communication at scale. Key generation and derivation are visible in the dependencies, with anyproto/go-bip39, go-slip10, go-slip21 and go-chash alongside secp256k1 and edwards25519.

Four node types, four separate repositories

Running the protocol means running infrastructure, and the README is explicit that the pieces are implemented elsewhere. A sync node is responsible for storing spaces and objects, a file node stores files, a consensus node watches and validates ACL changes, and a coordinator node handles network configuration management. Each of those lives in its own repository: any-sync-node, any-sync-filenode, any-sync-consensusnode and any-sync-coordinator. Files are deliberately kept outside the DAG, with the README noting external storage such as IPFS, and the dependency list carries the relevant libraries in ipfs/boxo, ipfs/go-cid and ipfs/go-ipld-format alongside libp2p, quic-go, webtransport-go, yamux for multiplexing and iroh bindings. The separation is what lets a provider be replaced: a provider is only ever storing and delivering objects, and a channel survives the provider swapping underneath it.

The provider holds the ciphertext, so the trust model is narrow on purpose

The operational claims in the README come down to a specific asymmetry. Users can choose and switch providers at any time without losing access to data, and providers cannot read user information, block users or alter accounts, because their job is only to deliver sync and storage. That is a narrower claim than end-to-end encryption alone, and the difference matters: a provider that cannot read content can still observe metadata such as the set of object identifiers and the timing of updates. The protocol overview at sync.any.org is where the entities are defined, and the repository does not repeat the details of that model. For a team evaluating this, the acl/ and accountservice/ packages in the tree are the places to read, because access control records and account handling are where that asymmetry is either enforced or quietly broken.

Building it: protobuf generation, drpc transport and Go tests

The Makefile shows the developer loop, and it starts with code generation rather than compilation. The proto target runs protoc over the .proto files in commonspace/object/acl/aclrecordproto, commonspace/object/tree/treechangeproto and util/crypto/cryptoproto, producing Go, vtprotobuf and drpc bindings with a marshalling feature set of marshal, unmarshal and size. The generated plugins live under deps/ and are put on PATH by the Makefile, and GOPRIVATE is exported as github.com/anyproto so the internal modules resolve from the right place. The protocol transport is drpc from storj.io, with vtprotobuf supplying the codec, and the tree changes are where the CRDT updates are carried. The other targets are test, deps and mocks, and a pre-commit config plus a .githooks directory sit at the repository root, with the Makefile pointing git at .githooks so the hooks are installed. There is also a flake.nix and flake.lock, so a Nix toolchain is available for reproducing the environment.

Where any-sync is the wrong choice

Several practical limits follow from the architecture. First, there is no hosted option described. The README says a user is a participant in the network rather than a customer of a vendor, which means somebody has to run the sync node, the file node, the consensus node and the coordinator, and absorb that cost. Second, a space is permissionless but a space also has a coordinator, and the coordinator owns network configuration, so the decentralisation has a defined trust boundary rather than removing trusted parties entirely. Third, the local-first advantage is described as holding when peers are physically close, which means a real-time collaborative app with distant participants is not automatically the case the design favours. Fourth, files live outside the encrypted DAG, and the README names IPFS as one option, so a deployment has to make a second decision about file storage that the space model does not decide for you. Fifth, this is a protocol without a stable release history in the repository, since the project publishes no GitHub releases, so pinning a version for production means tracking commits rather than tags.

How a CRDT protocol differs from a blockchain-backed one

The README draws the line with blockchains directly, and that is the most useful comparison it offers. A blockchain keeps a global consensus ledger, which buys identity management, access control and payments, but it means every node holds the entire history, and putting every encrypted message or document change there would be impractical at communication scale. any-sync instead keeps a strictly ordered, decentralized list for the structural metadata and moves the actual content into per-device CRDTs that are signed and applied independently. The cost of that choice is that the ordering guarantee is not the same kind of guarantee a chain gives you. A second, more practical difference sits in the dependency list: any-sync already depends on any-store, the local object store, which the README positions as the counterpart for local-first storage, and the two are meant to be used together, with developers working against the local store while sync, communication and scaling are handled by the protocol.

Editorial conclusion

Adopt any-sync if you are building a collaborative app whose data must stay readable when a provider disappears, and you have the capacity to run the node types yourself. Do not reach for it to ship a product this quarter: the module holds protocol code rather than a finished application, the four node roles live in separate repositories, and the README does not document a hosted option. Before committing, check the identity and key handling in accountservice/ and acl/ against your own threat model, and confirm that the provider you plan to run really cannot read space content.

Frequently asked questions

Official sources

1. anyproto/any-sync on GitHub
2. Issues
3. License: MIT
4. Project website
5. README