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

Why it matters. It sets the frame: what is new, what was kept, and why.

Context assumed. Anytype is a local-first knowledge tool.

Metaphor. None; a news unit. The visual is the two icons and the stack.

Misconception. Anytwo is Anytype's next version, or Anytype is being discontinued.

Visual language. Two app icons; a tangle behind the old one; a clean stack behind the new one; a bridge.

Target length. 75 to 95 seconds.

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

Script:

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. (Screen: two app icons: Anytype, then Anytwo beside it.)

Why? Legacy. A six-year-old editor built on its own block graph. One large middleware layer that blocked fixes and bred regressions. (Screen: the old app with a tangle of wires behind it.)

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. (Screen: the tangle replaced by a clean stack; Anytype icon stays with an open padlock.)

A new editor. A new database. A rebuilt file node. And an agent, with an off switch. (Screen: four items: editor, database, file node, 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. (Screen: a gap between the two icons; a bridge sketched across.)

This series is about what sits under Anytwo. The protocol. The data model. The local server. The agent. (Screen: the stack, with four regions marked.)

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

Why it matters. Knowing which layer owns a behaviour says where its guarantee comes from.

Context assumed. Unit 1.

Metaphor. A stack of boxes. Breaks: nothing.

Misconception. The database and the sync are one thing.

Visual language. Five boxes stacking; a line under the top layer.

Target length. 70 to 90 seconds.

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

Script:

Old Anytype had one middleware. Storage, sync, data model, API, all in one. Change one thing and you touched everything. (Screen: one tall box labelled middleware.)

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. (Screen: layer one: any-store.)

Above it, any-sync. The protocol. Spaces, guest lists, signed and encrypted change graphs, the network. (Screen: layer two: any-sync.)

Then the SDK. It turns encrypted changes into rows you can query. This is where the merge rules live, and where encryption happens. (Screen: layer three: the SDK.)

Then any. A local server on your own machine. Its API is plain JSON over HTTP. (Screen: layer four: any, a local server at 127.0.0.1.)

On top, the clients. The app, the command line, and the agent runtime. They all speak to the same local door. (Screen: layer five: clients and the agent runtime.)

One rule holds it together. Product logic stays above the API. Everything below is product-agnostic. (Screen: the stack with a line under the top layer.)

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

Why it matters. Every later guarantee about sharing and offline work rests on this shape.

Context assumed. Unit 2.

Metaphor. A room with a guest list by the door. Breaks: a room has one location; said at beat 5.

Misconception. A space is a folder on a server.

Visual language. Room, door, list, shelves, header card, three devices.

Target length. 55 to 70 seconds.

Check question. Where does a space live?

Script:

The unit of sharing is a space. Think of a room. By the door hangs a guest list. (Screen: a room with a door; a list pinned by the door.)

Inside are objects. Pages, chats, types. Every object in the room is shared with everyone on the list. (Screen: shelves of objects inside the room.)

The room has a header. Signed once, at creation. The space id is made from it, and it can never change. (Screen: a sealed header card on the door.)

The guest list is a chain of signed slips. Who was invited. Who joined. Who was removed. (Screen: the guest list as a chain of signed slips.)

A space lives on every device of every member. There is no master copy. The guest list and the objects are all there is. (Screen: one room on three devices.)

Idea. 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.

Why it matters. Every signature, every seal and every restore in the series depends on it.

Context assumed. Unit 3.

Metaphor. A key cut from a phrase. Breaks: nothing.

Misconception. An account is a username on a server.

Visual language. A twelve-word phrase; two keys; a signed envelope and slip; a post office checking; a second device.

Target length. 60 to 75 seconds.

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

Script:

Before the envelopes, the keys. An account starts as a phrase. Twelve words, shown once. (Screen: a recovery phrase of twelve words.)

From the phrase come two keys. A public key. That is your name on the network. A private key. Only your devices hold it. (Screen: the phrase becomes two keys: public and private.)

The private key signs everything you write. Every envelope. Every slip on a guest list. (Screen: the private key signs an envelope and a slip.)

Anyone with your public key can check the signature. Nobody can forge it. (Screen: a post office checks a signature against the public key.)

Type the phrase on a second device, and it has the same keys. That is how a new phone becomes you. (Screen: the same phrase typed on a second device; the same keys.)

There is no reset and no recovery flow. Lose the phrase and every key made from it, and the data is gone, by design. (Screen: the phrase with a warning: no recovery.)

Idea. 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.

Why it matters. This is the structure that lets devices merge histories without a server.

Context assumed. Unit 4.

Metaphor. Envelopes on a string. Breaks: a string is linear; the fork is drawn as two strings tied back together.

Misconception. A conflict needs someone to resolve it. Addressed at beat 4, with the caveat that which value wins is a later rule.

Visual language. Envelopes, string, fork, tips.

Target length. 70 to 85 seconds.

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

Script:

Every edit becomes a change. Picture a sealed envelope. Signed by whoever wrote it. Encrypted inside. It is named by its hash. (Screen: one sealed envelope with a stamp.)

Each envelope names the envelopes it was written after. That makes a chain. The first envelope is the root. (Screen: envelopes on a string; each points at the one before.)

Two devices edit at once, offline. Each writes an envelope after the same one. The chain forks. (Screen: the string forks into two.)

The next envelope names both tips. That merges the two histories. No server decides anything. Which value wins inside is a later rule. (Screen: a new envelope points at both tips; the fork closes.)

The tips nothing points at yet are called heads. One head means settled. Two heads means a fork is waiting. (Screen: two tips highlighted; the word heads.)

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. (Screen: envelopes sorted into one line by their hash.)

Idea. 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.

Why it matters. It is why a device can be gone for a month and resync cheaply.

Context assumed. Unit 5.

Metaphor. Comparing the tips, not reading the letters. Breaks: nothing.

Misconception. Sync means sending the document.

Visual language. Two peers; lists of object and head ids; hashed ranges; one range opened; a clock.

Target length. 65 to 80 seconds.

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

Script:

Two peers want to know if they hold the same data. They do not compare the data. (Screen: two peers, each with many chains.)

They compare heads. For every object, the ids of its tips. Same heads everywhere means same data everywhere. (Screen: each peer lists object id and head ids.)

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. (Screen: the lists hashed into ranges; one range differs.)

That finds the objects that are new, changed, or missing. Then only those envelopes are fetched. (Screen: one object found missing; its envelopes 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. (Screen: a fresh envelope streamed to a post office and a nearby peer.)

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. (Screen: a clock; a round every thirty seconds.)

Idea. 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.

Why it matters. It is the exact privacy claim: what an operator with the disks can and cannot learn.

Context assumed. Unit 5.

Metaphor. A post office that reads the envelope and never the letter. Breaks: a real post office does not check signatures, said at beat 4.

Misconception. End-to-end encrypted means the server knows nothing.

Visual language. One envelope split outside and inside; a post office; a query stopped at its door.

Target length. 70 to 85 seconds.

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

Script:

Look at one envelope again. The outside is readable. The inside is not. (Screen: an envelope: writing on the outside, sealed contents inside.)

Outside: which envelopes came before. Who wrote it, and when. Which key encrypts it. And the signature. (Screen: outside fields: previous envelopes, author and time, key id, signature.)

Inside: the edits themselves. Sealed with the space's read key. Only members hold that key. (Screen: inside field: the edits, sealed.)

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. (Screen: a post office checks the outside, cannot open the inside.)

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. (Screen: what nodes see: ids, shape, sizes, member keys.)

One consequence. A node cannot run a query. Every query runs on a device. The network is a relay for sealed mail. (Screen: a query stopped at the post office door.)

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

Why it matters. It names the pieces the next units refer to.

Context assumed. Unit 7.

Metaphor. Four buildings. Breaks: nothing.

Misconception. The network is one server.

Visual language. Post office, file store, referee, directory; a device beside a post office.

Target length. 55 to 70 seconds.

Check question. Which node validates the guest list?

Script:

The infrastructure has four kinds of node. Each has one job. (Screen: four buildings in a row.)

Sync nodes store and relay spaces. Guest lists and envelopes. All sealed. Several nodes hold each space. (Screen: sync node: shelves of sealed envelopes.)

File nodes store encrypted file blocks. (Screen: file node: sealed boxes.)

Consensus nodes validate the guest list. (Screen: consensus node: a referee with a stamp.)

The coordinator keeps the configuration. Which nodes exist. Which spaces exist. Where invites are stored. (Screen: coordinator: a directory and a map.)

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

Idea. 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.

Why it matters. It explains how a device finds its nodes without being told.

Context assumed. Unit 8.

Metaphor. A ring of post offices. Breaks: the real scheme hashes spaces to partitions and partitions to nodes; one ring stands for both.

Misconception. A central server assigns storage.

Visual language. A directory handing out a list; a header with a replication key; a ring; two nodes lit.

Target length. 55 to 70 seconds.

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

Script:

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

Then it computes the answer itself. The space header carries a replication key. (Screen: the space header with a replication key.)

Hash that key onto a ring of the nodes. The nodes it lands on are the ones that hold the space. (Screen: the key hashed onto a ring of nodes; two light up.)

Every device runs the same function and gets the same nodes. Nothing is negotiated. Nothing is assigned. (Screen: three devices compute the same two nodes.)

Add a node, and the configuration changes. Spaces move between nodes to match. Every device computes the new answer the same way. (Screen: a new node joins the ring; spaces move.)

Idea. 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.

Why it matters. Global p2p is new with the rebuild and removes the need to share a network.

Context assumed. Units 6 and 9.

Metaphor. Three roads to one house. Breaks: nothing.

Misconception. Peer-to-peer means the same Wi-Fi.

Visual language. Laptop, phone, post office, relay, three roads converging.

Target length. 65 to 80 seconds.

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

Script:

An envelope can reach another device three ways. The first is through the sync nodes. The post office. (Screen: a laptop, a phone, and a post office in between.)

The second is the local network. Devices on one Wi-Fi find each other and exchange envelopes directly. No server. (Screen: laptop and phone on one Wi-Fi, a direct line.)

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. (Screen: two devices far apart; a relay in the middle; then a direct line.)

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. (Screen: a phone with no internet; the laptop bridges.)

All three roads carry the same envelopes. A space can be fully synced with no sync node in the path. (Screen: all three roads converge on the same chain.)

Idea. 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.

Why it matters. It is the one place the local-first rule bends, and the reason is structural.

Context assumed. Units 3 and 8.

Metaphor. Slips on the guest list; a referee with a stamp. Breaks: nothing.

Misconception. The ACL merges like everything else.

Visual language. Chain of slips; three slip kinds; a fork; the stamp; an offline laptop.

Target length. 60 to 75 seconds.

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

Script:

The guest list is a chain. Each slip names the slip before it. Unlike objects, this chain may never fork. (Screen: the guest list as a chain of slips, each pointing at the previous.)

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. (Screen: an invite slip; a join slip; an accept slip.)

Two admins change the list at the same time. Both slips point at the same previous slip. Now there are two lists. (Screen: two admins add two slips at once; a fork.)

That is why there is a referee. The consensus node. It accepts the first slip that extends the chain. The other is rejected. (Screen: the referee stamps one, rejects the other.)

So changing membership needs the network. Every other write works offline. This one does not. (Screen: a laptop offline; a membership change bounced.)

Idea. 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.

Why it matters. It is what removal guarantees, and what it cannot.

Context assumed. Units 4 and 11.

Metaphor. Changing the lock, not taking back the key. Breaks: nothing.

Misconception. Removing someone takes away what they have.

Visual language. One key held by members; a crossed-off name; sealed copies; an old envelope still open; the old key carried forward.

Target length. 65 to 80 seconds.

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

Script:

Every member holds the same read key. It opens every envelope in the space. (Screen: one key held by three members.)

Now remove a member. Crossing them off the list is not enough. They still hold the key. (Screen: one member crossed off the list.)

So removal rotates the key. A new read key is made. A copy is sealed for each remaining member, with their public key. (Screen: a new key issued; sealed copies to each remaining member.)

Every envelope written from now on uses the new key. The removed member cannot open any of them. (Screen: a new envelope sealed with the new key; the old member cannot open it.)

What they already received stays readable to them. Encryption is forward-looking. It cannot take back what was delivered. (Screen: old envelopes still open for the removed member.)

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. (Screen: the old key carried forward, sealed under the new one.)

Idea. 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.

Why it matters. It is the trick behind the private space and one-to-one spaces.

Context assumed. Unit 3.

Metaphor. The same recipe gives the same cake, said at beat 3. Breaks: a recipe can be varied; a function cannot.

Misconception. Agreement on an id needs a message.

Visual language. Two headers side by side; three devices computing the same id; a no-delete mark.

Target length. 60 to 75 seconds.

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

Script:

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

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. (Screen: a header with no timestamp and no seed.)

The same recipe gives the same cake. Every device follows the recipe and lands on the same id. With zero messages. (Screen: three devices compute the same id with no messages between them.)

That is how a second device finds the account's own space before it has talked to anyone. That space is the next idea. (Screen: an example: the account's own space, coming next.)

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. (Screen: a computed id with a no-delete mark.)

Idea. 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.

Why it matters. It is how multi-device works with no server that can read your devices.

Context assumed. Units 4 and 13.

Metaphor. A small locked room beside the shared rooms. Breaks: nothing.

Misconception. Your account lives on a server.

Visual language. A locked room; its contents; a one-name list; a new phone restoring.

Target length. 65 to 80 seconds.

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

Script:

Every account has one more space. Private, and owner-only. The tech space. (Screen: a small locked room beside the shared rooms.)

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

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. (Screen: inside: the list of spaces, devices, profile, settings.)

Its guest list has one member, and the network refuses any further slip. There is no such thing as a shared account. (Screen: a guest list with one name and no invite slot.)

Restore a new phone from your phrase. It computes this space, pulls it first, and immediately knows every space to join. (Screen: a new phone restores from the phrase and pulls this space first.)

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. (Screen: the same chain mechanism, no special sync.)

Idea. 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.

Why it matters. It is the substrate for direct messages and any two-party state.

Context assumed. Units 13 and 11.

Metaphor. Two people who can each work out the same secret alone. Breaks: nothing.

Misconception. A direct message needs an invitation on the guest list.

Visual language. Two people with key pairs; a secret on both sides; a header; a two-name list; a pending badge.

Target length. 70 to 85 seconds.

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

Script:

Two accounts. Alice and Bob. Each has a public key and a private key. (Screen: two people, each with a key pair.)

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. (Screen: a shared secret computed on both sides.)

From that secret, both compute a space. Its id. Its guest list. Its read key. A one-to-one space, with exactly two writers. (Screen: a space header derived from the secret.)

The list is fixed. Two writers, forever. No invite slip. No accept. No referee needed. (Screen: the guest list with two names.)

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. (Screen: a pending badge on Bob's side.)

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. (Screen: a direct message thread between the two.)

Idea. 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.

Why it matters. It bridges the protocol to the data model.

Context assumed. Unit 5.

Metaphor. Opening the envelope. Breaks: nothing.

Misconception. A change is a new copy of the document.

Visual language. An opened envelope; small edits; a record id from a hash; a table.

Target length. 65 to 80 seconds.

Check question. What travels between devices?

Script:

Open an envelope. What is inside is not a document. It is a batch of edits. (Screen: an envelope opened; inside, a list of small edits.)

Set this field to this value. Unset that one. Add to this set. Increment this counter. Delete this record. (Screen: one edit: set title to Draft 2.)

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. (Screen: edits keyed by path, grouped by record, in one dataset.)

Devices exchange edits. Nobody sends rows. Rows are what you get by applying the edits. (Screen: two devices exchange envelopes, never whole documents.)

A new record needs no id from you. It gets one from the envelope's hash. Unique everywhere, with no coordination. (Screen: a record with an empty id gets one from the envelope's hash.)

Apply every envelope, and you have a table of rows. (Screen: the table of rows, built from envelopes.)

Idea. 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.

Why it matters. It is the exact merge rule, and the design rule that follows.

Context assumed. Unit 16, chain order from unit 5.

Metaphor. A sticker on each field. Breaks: nothing.

Misconception. Conflicts are resolved by time.

Visual language. A record with stickers; an incoming edit compared; two devices, two fields; two devices, one field.

Target length. 70 to 85 seconds.

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

Script:

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. (Screen: one record with fields and a sticker on each field.)

An incoming edit is a comparison. Later in the chain than the sticker? Write it, and replace the sticker. Earlier? Drop it. (Screen: an incoming edit compared with the sticker.)

Later means later in chain order. Not later by the clock. Two clocks are never compared. (Screen: versions ordered by the chain, not by clocks.)

Alice sets the title. Bob sets the tags. Both offline. Different fields. Different stickers. Both survive, on both devices. (Screen: device A sets title, device B sets tags; both survive.)

Both set the title. Chain order picks one. The other is gone, everywhere, and nobody is told. (Screen: both set the title; one wins silently.)

Fields that people edit at the same time should be different fields. Write the one path you changed. Never the whole record. (Screen: a record designed so concurrent edits hit different fields.)

Idea. 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.

Why it matters. It says what you can and cannot model.

Context assumed. Unit 17.

Metaphor. A counter, a set, a tombstone. Breaks: nothing.

Misconception. You can enforce a balance that never goes negative.

Visual language. A counter on two devices; two tags added; a tombstone; a bounced edit.

Target length. 60 to 75 seconds.

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

Script:

Not every edit is last-writer-wins. An increment is a counter. Two offline increments both apply. (Screen: a counter incremented on two devices; both land.)

Add-to-set and pull are set operations. Two concurrent adds both land. (Screen: two devices each add a tag; the set has both.)

Delete is different. Delete wins absolutely. A deleted record leaves a tombstone, and the tombstone is sticky. (Screen: a delete stamps a tombstone over the record.)

Any later edit to that record is dropped. The local writer is told. Nobody else needs to be. (Screen: a later edit bounces off the tombstone.)

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. (Screen: a balance must stay above zero; two decrements both apply.)

A write never fails because someone else wrote first. In exchange, every rule must be a commutative operation or a per-field overwrite. (Screen: the trade as a title.)

Idea. 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.

Why it matters. It is how validation and derived fields work without a central authority.

Context assumed. Unit 16.

Metaphor. The same clerk on every device, said at beat 2. Breaks: nothing.

Misconception. Validation needs a server.

Visual language. A server stamping; a clerk on each device; a dropped edit; no rollback arrow.

Target length. 70 to 85 seconds.

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

Script:

A hosted backend stamps fields for you. Created at. Created by. There is no server here. So who stamps them? (Screen: a server stamping created-at on a row.)

A handler does. Think of a clerk. Every dataset has one. It runs while an envelope is applied, on every device, identically. (Screen: every device runs the same handler inside apply.)

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. (Screen: the clerk reads the envelope's author and time and writes the stamp.)

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. (Screen: an edit by the wrong author dropped, the rest applied.)

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. (Screen: no rollback arrow; a new envelope instead.)

Nothing a clerk decides may depend on this device alone. Then every device reaches the same rows, in any order. (Screen: the rule as a title.)

Idea. 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.

Why it matters. It is why there are no migrations.

Context assumed. Unit 19.

Metaphor. Throw away the table, open the envelopes again. Breaks: nothing.

Misconception. Changing the data shape needs a migration.

Visual language. A table beside a chain; a rule change; wiped rows; replay; many devices.

Target length. 65 to 80 seconds.

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

Script:

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. (Screen: a table of rows beside a chain of envelopes.)

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. (Screen: a clerk's rules change.)

Here there is no script. Wipe the rows. Replay the chain. The rows come back in the new shape. (Screen: rows wiped; the chain replayed.)

It happens per object, when the object is opened. A background sweep catches the rest. Interrupt it, and it starts again. (Screen: one object rebuilt when opened; a slow sweep for the rest.)

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. (Screen: many devices, no maintenance window.)

Idea. 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.

Why it matters. It is the surface every client, script and agent uses, and the honest edge of the privacy story.

Context assumed. Unit 2.

Metaphor. One door. Breaks: nothing.

Misconception. The app opens the database file itself.

Visual language. A server at loopback; a dashed machine boundary; query and subscribe; a write reply.

Target length. 60 to 75 seconds.

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

Script:

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. (Screen: a local server at 127.0.0.1 with one 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. (Screen: a request to the loopback address.)

Every dataset is read the same two ways. Query, or subscribe. Same filter. Same sort. Same stream. (Screen: two read endpoints: query and subscribe.)

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. (Screen: a write returns version, change id, record ids.)

One read path. One write shape. Strict bodies. A local-first system has as many copies as devices. Consistent behaviour keeps the copies consistent. (Screen: the same answer on every device.)

Idea. 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.

Why it matters. It is the rebuilt file node and verifiable backup status.

Context assumed. Unit 7.

Metaphor. The courier signs for the parcel. Breaks: nothing.

Misconception. The file node reads your files.

Visual language. A file attached; a tiny file inside an envelope; a chunked tree; a receipt; a row flipping to durable.

Target length. 65 to 80 seconds.

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

Script:

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

Under four kilobytes, the bytes ride inside the change itself. Durable by construction. They never reach a file node. (Screen: a tiny file riding inside an envelope.)

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

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. (Screen: bytes go straight to storage; the node signs a receipt.)

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. (Screen: the receipt is a synced field; the row flips to durable.)

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. (Screen: readable: root hash, size, receipt; one sealed box for the rest.)

Idea. 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.

Why it matters. It is where "agent-native" becomes a concrete design rule, and it is the format the migration bridge speaks.

Context assumed. Unit 21.

Metaphor. A form a stranger can fill in and read back, said at beat 5. Breaks: nothing.

Misconception. An export format is for humans or for machines, not both.

Visual language. An old nested export; a flat list; Markdown in text; a named value; a form; one format, three doors.

Target length. 65 to 80 seconds.

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

Script:

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. (Screen: Anytype 0.57, September 2026; an old export beside it.)

The new format is flat. Blocks in reading order. Nesting is an indent number. (Screen: a flat list of blocks with an indent number.)

Formatting lives inside the text, as Markdown. Models cannot keep offset bookkeeping. They can write bold stars. (Screen: formatting inside the text as markdown.)

Options and types are names, not ids. Only objects keep ids. Status: In progress. Not an option id someone must fetch first. (Screen: a status value as a name, not an id.)

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. (Screen: a form a stranger can fill in; a seven-billion-parameter model.)

One shape serves export, import, and the API. Learn to read an export, and you can read what a tool just wrote. (Screen: one format for export, import and the API.)

Idea. 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.

Why it matters. It is why the agent moves between devices and why "did it run" is a query.

Context assumed. Units 21 and 14.

Metaphor. A space as the agent's whole desk. Breaks: nothing.

Misconception. The agent is a process with its own state.

Visual language. A room holding chat, memory, triggers, programs; an empty process; a trigger record; three devices, one elected.

Target length. 60 to 75 seconds.

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

Script:

The agent is called bao. Its runtime is anyrt. Its chat, its memory, its schedule, and its own code are objects in a space. (Screen: a space holding chat, memory, triggers, and the agent's own code.)

The process holds nothing. Stop it on one device, start it on another, and it picks up the same conversation. (Screen: the agent process with no state of its own.)

Its programs live in the space too. Edit one, and the next conversation uses it. No restart. The agent can write programs for itself. (Screen: a program deployed to the space; edit it, no restart.)

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. (Screen: a trigger record: cron, program, args.)

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. (Screen: three devices; one elected to answer.)

Idea. 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.

Why it matters. It is the architecture behind "an agent you can audit", and its honest limit.

Context assumed. Units 24 and 21.

Metaphor. A figure in a glass box with one door, said at beat 1. Breaks: the box confines the code, not the door, said at beat 5.

Misconception. The agent's code can do anything on your machine.

Visual language. A glass box; one tool; the door; a log; a replay; the door opening onto the server.

Target length. 60 to 75 seconds.

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

Script:

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. (Screen: a glass box with one door; a small figure inside.)

The model has one tool. It writes code. Changing ten documents is one cell, not ten calls. (Screen: one tool: write a cell of code.)

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. (Screen: every side effect passes through the one door and is logged.)

That log replays a run bit-exact. Why did bao do that? Replay it and watch. (Screen: a run replayed from its log, bit for bit.)

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. (Screen: the door opens onto the whole account.)

Idea. 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.

Why it matters. It states the policy and the honest state of play.

Context assumed. Unit 25.

Metaphor. A switch and a picker. Breaks: nothing.

Misconception. The agent means your notes go to a model provider.

Visual language. An off switch; a model picker; a space list; a laptop with a local model; an alpha badge; the quoted line.

Target length. 75 to 90 seconds.

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

Script:

Anytwo has an AI off switch. Turn it off and the rest of the stack is unchanged. (Screen: a switch labelled AI, set to off.)

Turn it on and you choose the model. A local model on your own machine. A private provider. A cloud provider. (Screen: a model picker: local, private provider, cloud.)

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. (Screen: a space list; the agent invited to one.)

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. (Screen: a laptop running a local model; one dashed line to a relay.)

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. (Screen: the alpha badge; a note about review.)

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. (Screen: the team's line, quoted.)