Anytwo keeps the protocol and replaces everything above it; Anytype stays and goes MIT; moving is a hard migration with a bridge.

Anytype is a local-first knowledge tool. Seven years old. In September 2026 its makers announced Anytwo. Not a release. A rebuild, from the ground up.

Why? Legacy. A six-year-old editor built on its own block graph. One large middleware layer that blocked fixes and bred regressions.

Anytwo keeps the protocol, which has carried millions of spaces. It replaces everything above it with a clean stack. Anytype itself stays, and moves from source-available to open source under MIT.

A new editor. A new database. A rebuilt file node. And an agent, with an off switch.

There is no backwards compatibility. Moving is a hard migration, with a bridge the team is still building. Testers started in September. A first public release is planned for the end of the year.

This series is about what sits under Anytwo. The protocol. The data model. The local server. The agent.

Check yourself. What did Anytwo keep from Anytype, and what did it replace?

Five layers with one job each: database, protocol, record CRDT, local server, clients and agent. Product logic stays above the API.

Old Anytype had one middleware. Storage, sync, data model, API, all in one. Change one thing and you touched everything.

Anytwo is five layers. At the bottom, any-store. An embedded document database. Queries, indexes, full-text and vector search. No idea that sync exists.

Above it, any-sync. The protocol. Spaces, guest lists, signed and encrypted change graphs, the network.

Then the SDK. It turns encrypted changes into rows you can query. This is where the merge rules live, and where encryption happens.

Then any. A local server on your own machine. Its API is plain JSON over HTTP.

On top, the clients. The app, the command line, and the agent runtime. They all speak to the same local door.

One rule holds it together. Product logic stays above the API. Everything below is product-agnostic.

Check yourself. Which layer decides what is inside an encrypted change?

A space is one access list plus every object under it, replicated on every member's devices with no master copy.

The unit of sharing is a space. Think of a room. By the door hangs a guest list.

Inside are objects. Pages, chats, types. Every object in the room is shared with everyone on the list.

The room has a header. Signed once, at creation. The space id is made from it, and it can never change.

The guest list is a chain of signed slips. Who was invited. Who joined. Who was removed.

A space lives on every device of every member. There is no master copy. The guest list and the objects are all there is.

Check yourself. Where does a space live?

An account is a key pair derived from a phrase: the public key is your name, the private key signs every envelope and slip, the phrase restores any device, and there is no recovery flow.

Before the envelopes, the keys. An account starts as a phrase. Twelve words, shown once.

From the phrase come two keys. A public key. That is your name on the network. A private key. Only your devices hold it.

The private key signs everything you write. Every envelope. Every slip on a guest list.

Anyone with your public key can check the signature. Nobody can forge it.

Type the phrase on a second device, and it has the same keys. That is how a new phone becomes you.

There is no reset and no recovery flow. Lose the phrase and every key made from it, and the data is gone, by design.

Check yourself. What happens if you lose the phrase and every device?

A change is a signed, encrypted envelope named by its hash that names the heads it was built on. Forks close when the next change names both tips; hash order makes every device read the same sequence.

Every edit becomes a change. Picture a sealed envelope. Signed by whoever wrote it. Encrypted inside. It is named by its hash.

Each envelope names the envelopes it was written after. That makes a chain. The first envelope is the root.

Two devices edit at once, offline. Each writes an envelope after the same one. The chain forks.

The next envelope names both tips. That merges the two histories. No server decides anything. Which value wins inside is a later rule.

The tips nothing points at yet are called heads. One head means settled. Two heads means a fork is waiting.

To read the object, start at a head and follow the pointers back. Where two orders are possible, sort by hash. Every device gets the same order.

Check yourself. Two devices edit the same object offline. What closes the fork?

Two peers with the same heads for every object hold the same data, so sync compares heads over hashed ranges and fetches only what differs; local writes stream at once.

Two peers want to know if they hold the same data. They do not compare the data.

They compare heads. For every object, the ids of its tips. Same heads everywhere means same data everywhere.

A head-sync round is a diff. The list is hashed in ranges. Both sides compare range hashes. Only the ranges that differ get opened.

That finds the objects that are new, changed, or missing. Then only those envelopes are fetched.

Local writes do not wait for a round. A new envelope is streamed at once, to the post office and to peers on the same network.

The round is the catch-up. About every thirty seconds, and on demand. A device gone for a month comes back with nothing but heads to compare.

Check yourself. What does a head-sync round send when nothing changed?

An envelope's outside is cleartext that nodes verify: previous ids, author and time, key id, signature. The inside is sealed with the read key. So every query runs on a device.

Look at one envelope again. The outside is readable. The inside is not.

Outside: which envelopes came before. Who wrote it, and when. Which key encrypts it. And the signature.

Inside: the edits themselves. Sealed with the space's read key. Only members hold that key.

A sync node is a post office. A strict one: a real post office does not check signatures. It checks the signature, checks the author is on the list, checks the pointers resolve. It never holds the key. The inside is opaque to it.

So a node knows that a space exists. Which keys are members. The shape and size of the chains. It never knows a name, a field, or a message.

One consequence. A node cannot run a query. Every query runs on a device. The network is a relay for sealed mail.

Check yourself. Name two things a sync node can see and two it cannot.

Sync nodes, file nodes, consensus nodes and a coordinator each have one job, and a node runs the same code as a device.

The infrastructure has four kinds of node. Each has one job.

Sync nodes store and relay spaces. Guest lists and envelopes. All sealed. Several nodes hold each space.

File nodes store encrypted file blocks.

Consensus nodes validate the guest list.

The coordinator keeps the configuration. Which nodes exist. Which spaces exist. Where invites are stored.

A node runs the same code as a device. Every node is just another peer. One that happens to be always on.

Check yourself. Which node validates the guest list?

A device fetches the node list from the coordinator and then computes which nodes hold a space by hashing the header's replication key onto a ring; every device gets the same answer and resharding is the same computation.

Which sync nodes hold your space? A device asks the coordinator for one thing: the current list of nodes.

Then it computes the answer itself. The space header carries a replication key.

Hash that key onto a ring of the nodes. The nodes it lands on are the ones that hold the space.

Every device runs the same function and gets the same nodes. Nothing is negotiated. Nothing is assigned.

Add a node, and the configuration changes. Spaces move between nodes to match. Every device computes the new answer the same way.

Check yourself. What does a device ask the coordinator for, and what does it compute itself?

Envelopes travel by sync nodes, by the local network, or by global peer-to-peer through relays that store nothing; a device can bridge; a space can sync with no node in the path.

An envelope can reach another device three ways. The first is through the sync nodes. The post office.

The second is the local network. Devices on one Wi-Fi find each other and exchange envelopes directly. No server.

The third is global peer to peer, new with the rebuild. Two devices anywhere connect through a relay, until they find a direct path. The relay forwards encrypted traffic and stores nothing. A device announces only an endpoint id and its relay. Never an address.

A device with two roads bridges for one with one. Your laptop can carry your phone's changes to the network, and bring the network's back.

All three roads carry the same envelopes. A space can be fully synced with no sync node in the path.

Check yourself. Can a space be fully synced with no sync node in the path?

The guest list is a chain that may never fork; a consensus node accepts the first slip that extends it and rejects the other, so changing membership needs the network.

The guest list is a chain. Each slip names the slip before it. Unlike objects, this chain may never fork.

Three of the slips. An invite. A request to join, signed with a key that came with the invite. An accept, which carries the read key, sealed for the newcomer.

Two admins change the list at the same time. Both slips point at the same previous slip. Now there are two lists.

That is why there is a referee. The consensus node. It accepts the first slip that extends the chain. The other is rejected.

So changing membership needs the network. Every other write works offline. This one does not.

Check yourself. Why can an ACL change not be made offline?

Removal rotates the read key: a new key is sealed to each remaining member, later envelopes use it, the removed member keeps what was delivered, and old keys are carried under new ones.

Every member holds the same read key. It opens every envelope in the space.

Now remove a member. Crossing them off the list is not enough. They still hold the key.

So removal rotates the key. A new read key is made. A copy is sealed for each remaining member, with their public key.

Every envelope written from now on uses the new key. The removed member cannot open any of them.

What they already received stays readable to them. Encryption is forward-looking. It cannot take back what was delivered.

And the old key is carried forward, sealed under the new one. A newcomer gets the newest key, and through it, every key before. They can read the whole history.

Check yourself. After removal, which envelopes can the removed member still read?

Leave out everything that varies and an id becomes a pure function of its inputs, so every device lands on it with no messages. The price is permanence.

Most ids are minted. A new space signs a header with a timestamp and a random seed. The hash is the id. Unique, unguessable.

Some ids are computed instead. Leave out everything that varies. The time. The random seed. For some objects, even the signature. Now the id is a pure function of its inputs.

The same recipe gives the same cake. Every device follows the recipe and lands on the same id. With zero messages.

That is how a second device finds the account's own space before it has talked to anyone. That space is the next idea.

The price is permanence. A computed object cannot be deleted. Delete it, follow the recipe again, and you get the same id with a fresh history.

Check yourself. Why can a computed object not be deleted?

Every account has a computed, owner-only tech space holding the space list, devices, profile and settings; it syncs by the same rules and a new device pulls it first.

Every account has one more space. Private, and owner-only. The tech space.

Its id is computed from the account's public key. Every device of the account finds it without asking anyone.

It holds everything that is about the account, not about a shared space. The list of spaces you are in. Your devices. Your profile. Your settings.

Its guest list has one member, and the network refuses any further slip. There is no such thing as a shared account.

Restore a new phone from your phrase. It computes this space, pulls it first, and immediately knows every space to join.

It syncs by the same rules as everything else. There is no separate preferences sync, and no server that can read which devices are yours.

Check yourself. What does a freshly restored phone pull first, and why?

Two accounts each compute the same secret alone, and from it the same space id, guest list and read key: a one-to-one space with two writers, no invite slip, no referee. Approval is a local gate.

Two accounts. Alice and Bob. Each has a public key and a private key.

From her private key and his public key, Alice computes a secret. From his private key and her public key, Bob computes the same one. Each works it out alone. Nothing is sent.

From that secret, both compute a space. Its id. Its guest list. Its read key. A one-to-one space, with exactly two writers.

The list is fixed. Two writers, forever. No invite slip. No accept. No referee needed.

Bob only has to be told. His device will not download the space until he says yes. Approval is a local gate, not a list operation.

This is the substrate for direct messages, and for any two-party shared state. Any two identities already share a space. They only have to open it.

Check yourself. What stops Bob's device from downloading a one-to-one space Alice computed?

Inside an envelope is a batch of per-record, per-path edits on one dataset of one object; devices exchange edits, never rows; a new record's id comes from the envelope's hash.

Open an envelope. What is inside is not a document. It is a batch of edits.

Set this field to this value. Unset that one. Add to this set. Increment this counter. Delete this record.

An object keeps its records in named datasets. A chat has its messages. A page has its blocks. Each edit names a record and a path inside it. One envelope touches one dataset of one object. It may touch many records.

Devices exchange edits. Nobody sends rows. Rows are what you get by applying the edits.

A new record needs no id from you. It gets one from the envelope's hash. Unique everywhere, with no coordination.

Apply every envelope, and you have a table of rows.

Check yourself. What travels between devices?

Each field carries this device's position number for the last envelope that wrote it; an incoming edit applies only if later in chain order; different fields both survive, the same field picks one winner silently.

Every field in a row carries a sticker. The sticker is this device's position number for the last envelope that wrote the field. Two devices write different numbers, but agree on the order.

An incoming edit is a comparison. Later in the chain than the sticker? Write it, and replace the sticker. Earlier? Drop it.

Later means later in chain order. Not later by the clock. Two clocks are never compared.

Alice sets the title. Bob sets the tags. Both offline. Different fields. Different stickers. Both survive, on both devices.

Both set the title. Chain order picks one. The other is gone, everywhere, and nobody is told.

Fields that people edit at the same time should be different fields. Write the one path you changed. Never the whole record.

Check yourself. Alice sets the title and Bob sets the tags, both offline. What do both devices end with?

Increment, add-to-set and pull compose; delete leaves a sticky tombstone; a write never fails because of another writer, and in exchange no rule can span concurrent writers.

Not every edit is last-writer-wins. An increment is a counter. Two offline increments both apply.

Add-to-set and pull are set operations. Two concurrent adds both land.

Delete is different. Delete wins absolutely. A deleted record leaves a tombstone, and the tombstone is sticky.

Any later edit to that record is dropped. The local writer is told. Nobody else needs to be.

What you cannot have is a rule across writers. A balance that must stay above zero cannot be enforced by two devices offline. Model it as a counter, or accept that both decrements land.

A write never fails because someone else wrote first. In exchange, every rule must be a commutative operation or a per-field overwrite.

Check yourself. Two devices decrement a counter offline. What happens?

A clerk runs while an envelope is applied, on every device, from inputs every device has, so stamps and refusals need no server; the writer refuses before the envelope exists, readers drop the bad edit and apply the rest; there is no rollback.

A hosted backend stamps fields for you. Created at. Created by. There is no server here. So who stamps them?

A handler does. Think of a clerk. Every dataset has one. It runs while an envelope is applied, on every device, identically.

It reads only what every device has. The envelope's author. Its time. The record's previous state. From that it derives the stamp. Same input everywhere, same stamp everywhere.

A clerk can also refuse. Author-only edits. A required field. On the writing device, the envelope is refused before it exists. On every other device, the bad edit is dropped and the rest applies.

There is no rollback. An envelope in the chain is signed and named by its hash. Others may have built on it. Correction is another envelope.

Nothing a clerk decides may depend on this device alone. Then every device reaches the same rows, in any order.

Check yourself. What may a clerk read when it decides a stamp?

Rows are the result of replaying a chain through the current clerks; when the rules change, rows are wiped and the chain replayed, per object, with a sweep; no migration script can be correct on every copy.

The rows in the database are not the source of truth. The chains are. Every row is the result of replaying a chain through the current clerks.

Now a clerk's rules change. A date is stored differently. A derived field gets a new shape. In a hosted system, that is a migration script.

Here there is no script. Wipe the rows. Replay the chain. The rows come back in the new shape.

It happens per object, when the object is opened. A background sweep catches the rest. Interrupt it, and it starts again.

Why? A hosted backend migrates one table, once, under a window. There are as many copies here as there are devices, and no window in which nobody writes. The only migration that is correct on every copy is the one apply already does.

Check yourself. What happens to an object's rows when its clerk's rules change?

Everything above the SDK talks to one HTTP server on loopback; the machine is the trust boundary, so every local process can call it; one read path, one write shape.

Everything above the SDK talks to one HTTP server, on your own machine. The app, the command line, a script, the agent. All through the same door.

It binds only to loopback. No TLS. No login. The trust boundary is the machine. Anyone with a shell on it, and every process on it, can call the door.

Every dataset is read the same two ways. Query, or subscribe. Same filter. Same sort. Same stream.

Every write returns one shape. A version, a change id, the record ids. Never the record. Read it back through a query, where everyone else's writes arrive too.

One read path. One write shape. Strict bodies. A local-first system has as many copies as devices. Consistent behaviour keeps the copies consistent.

Check yourself. What does a write return, and what does it never return?

Small files ride inside the change; large files are encrypted trees that go straight to storage, and the node signs a receipt that syncs as the one readable field. Name, type and key stay sealed.

A file is attached to an object. There are no standalone files. The attach returns before any network work.

Under four kilobytes, the bytes ride inside the change itself. Durable by construction. They never reach a file node.

Larger files are encrypted and chunked into a tree, each chunk named by its hash. Stored locally first. Backed up in the background.

In the old file node, bytes passed through the node. In the rebuilt one they go straight to storage. The node signs a receipt when the bytes are there.

The receipt is a readable field on the file's row, so it syncs. Every member sees the file flip to durable. Backup status is verifiable, not assumed.

This is the one field of yours a node can read: the root hash, the size, the receipt. The name, the type, and the key stay sealed for members.

Check yourself. How does another member learn that a file is backed up?

AnyBlock v2 shipped in Anytype 0.57 as the data bridge: flat blocks with an indent, Markdown in text, names instead of ids, so a small model guided by a grammar can write it and a stranger can read it. One shape serves export, import and the API.

One piece of the rebuild shipped in Anytype first, in version 0.57, as the bridge for your data. AnyBlock version two, and an API to go with it. Old exports mirrored the internals. Nested lists through block ids. Bold stored as character offsets.

The new format is flat. Blocks in reading order. Nesting is an indent number.

Formatting lives inside the text, as Markdown. Models cannot keep offset bookkeeping. They can write bold stars.

Options and types are names, not ids. Only objects keep ids. Status: In progress. Not an option id someone must fetch first.

Think of a form a stranger can fill in, and read back. The bar was set at the small end. Would a seven-billion-parameter model, guided by a grammar, emit this correctly? If not, the shape is wrong, not the model.

One shape serves export, import, and the API. Learn to read an export, and you can read what a tool just wrote.

Check yourself. Why are blocks flat with an indent instead of nested?

bao's chat, memory, programs and triggers are objects in a space, so the process holds nothing; editing a program is a deploy; schedules are records; devices elect who answers.

The agent is called bao. Its runtime is anyrt. Its chat, its memory, its schedule, and its own code are objects in a space.

The process holds nothing. Stop it on one device, start it on another, and it picks up the same conversation.

Its programs live in the space too. Edit one, and the next conversation uses it. No restart. The agent can write programs for itself.

A schedule is a record. Cron, or an event, or once. The agent sets a reminder by writing one. Did it run? That is a query.

With several devices online, an election picks the one that answers. The winner is computed from the device list in your private space. Nobody double-answers.

Check yourself. Stop the agent on one device and start it on another. What does it remember?

The agent's code runs in a sandbox with one tool and one logged door; every effect is checked, executed and logged, and the log replays bit-exact; the door opens onto everything the local server trusts.

The agent's code runs in a glass box. Python, compiled to run inside a sandbox. No sockets. No filesystem. A virtual clock. A budget of steps.

The model has one tool. It writes code. Changing ten documents is one cell, not ten calls.

The only way out of the box is a named effect. A query. A model call. A web request. Each one is checked, executed, and written to a log.

That log replays a run bit-exact. Why did bao do that? Replay it and watch.

The box confines the code. It does not shrink the door. The door opens onto the local server, and the server trusts every process on your machine.

Check yourself. What is the only way code in the box can reach the outside?

AI is optional and the model is yours; in the alpha the agent joined only invited spaces; the first alpha ran on a cloud model with reviewed conversations, which was the alpha, not the design; the team's bet is local models plus local-first.

Anytwo has an AI off switch. Turn it off and the rest of the stack is unchanged.

Turn it on and you choose the model. A local model on your own machine. A private provider. A cloud provider.

In the alpha, the agent joined only the spaces you invited it to, like any collaborator. What it can see in Anytwo is set by that invite, and by what your local server trusts.

One tester ran it with a local model on a GPU and local search. No content left the machine. Only sync traffic, which is sealed. The setup needed a config file, not yet a screen.

The first alpha, in May, ran on the team's own infrastructure, on a cloud model. Those conversations were reviewed by the team. That was the alpha, not the design.

The team's own words: local models on powerful devices, paired with local-first software, are the future. Everything in this series is built so that can be true.

Check yourself. What did the first alpha run on, and what does the design intend?