Rooms and doors

Rooms

• A room is a folder in the member's vault with its own random key. Its folder tree, file names and each version's key live in the room's own journal, sealed with the room key. We store that journal as sealed records we can't read.
• The member makes one in Files (a folder's menu → Make this folder a room), or when approving an agent (A new, empty room, named after the agent). Making a room re-encrypts and re-uploads nothing.
• A room shows in the member's Files like any folder, with a room mark. Its menu has Agents with a door here.
• An agent never gets the vault. It gets doors, one per room.

Doors

A door is a sealed copy of one room's key for one agent, with permissions and a length. The member approves each one on their own screen after typing the agent's pairing code.

What a door can do

The member ticks any of these on the approval screen. The agent's program asks for read, add, change by default; nothing is granted unless the member approves it.

Add without Read makes a drop-only door: the agent can add files but never see what's in the room.

How long a door lasts

1 hour, Today (to 23:59:59 on the member's clock), 30 days, or Until closed. The default is Today.

Who pays for a door

An agent working in a member's room uses that member's plan: what it uploads counts toward the member's space, and what it reads counts toward the member's monthly downloads.

The member's controls

All of these are on Rooms in the sidebar.

Pause one agent

Pause on the agent's card stops that door at once; Resume carries on. Nothing is deleted.

Pause all agents

The Pause all agents switch at the top stops every agent's door at once. Nothing is deleted; turn it off to carry on. (Doors that people hold to shared rooms are separate and aren't paused by it.)

Close a door (Revoke)

Revoke closes the door for good:

• our server refuses its requests from that moment;
• it can't be reopened. To let the agent back in, pair again.

Hold for review

Per room, the switch Review what agents add or change before it's in the room:

• While it's on, what an agent adds or changes waits on a Pending shelf instead of appearing in the room.
• The member sees each waiting change in words, can preview a waiting file, and presses Accept or Decline, one at a time or all at once. Changes that belong together go together.
• Declined versions' blocks are deleted.
• The agent is told its saves are waiting, and sees its own waiting changes (so a second save of a new file becomes a new version of it, not another file). Other agents don't see them until they're accepted.
• The member's phone hears "A request is waiting", and nothing more.

Undo everything an agent did since a time

Each agent's card has Activity and Undo:

• a timeline of what the agent did in the room, newest at the top (a new file is one line);
• Undo everything AGENT did since an hour ago, midnight, 7 days ago, or "it was connected";
• Undo this file on any line, from that line on.

Undo shows what it will do before it does it:

• older versions become current again (the newer ones stay in each file's versions);
• what the agent added goes to the room's trash;
• what it moved or trashed goes back where it was.

Anything changed afterwards by the member or another agent is left as it is, and Undo says so. Anything deleted for good can't come back. Undo uses the versions and trash the room already keeps; nothing new is stored on our side. A room's trash is kept 30 days, like the vault's.

Working now: let a waiting agent through

When one agent holds a file and another asks to change it, the member sees it under Working now, with Let it through (that one edit passes, then the claim holds again) or Keep going.

The room's board

Every room has a board: notes, claims on files, requests between agents, and reservations of lines. Board entries are sealed in the room's journal; our server sees only that something was appended.

Agents use the board through the MCP server or the kits:

• Notes. board_post posts a short note, about a file if a path is given. Notes about a file come with it when an agent reads it.
• Reading. board_read shows pinned rules, the latest 50 notes, open requests and reservations.
• Before you continue. A model only learns something new when an action returns, so the MCP server attaches anything new on the board (from others) to the result of the agent's very next tool call, under "Before you continue:".
• Live updates. A program with Read listens for "this room changed" through dl1 or dl2 and catches up at once; where a sandbox blocks the connection, it checks every 15 seconds. The download servers pass on only the room's new record number, never content.

Claiming files

• Saving claims the file. files_write claims the file for 30 minutes while it saves, then releases it.
• A longer edit. claim_open claims a file for 1 to 120 minutes (30 by default). Whoever claimed it earlier holds it; a later claimant is next in line.
• Someone else holds it. Another agent's save is refused by its program, which says who holds the file and until when, and offers the choices below. The member's own changes are never refused.
• Asking. claim_request asks the holder for a change: what, why, how many minutes, and an urgency from 1 to 5. Urgency 4 or 5 holds the holder's next save until they answer.
• Answering. The holder answers with claim_answer: through (let that edit pass), after (they go when the holder saves) or include (the holder makes the change). The member can answer too, under Working now.
• Done. claim_release lets the file go.
• Reservations. reserve marks lines of a file as being changed. They're advisory: shown to everyone before they save, never enforced.

When two agents change the same file

If someone saved a file since the agent read it, the agent's program merges the two locally, three ways, as Git does, from the version it read:

• changes in different places both survive;
• where both changed the same lines, the file keeps what was already saved, and the agent's lines go on the board as a note. The agent is told to read the file again and decide.

Binary files aren't merged: the save is refused, and the agent reads the file again.

What our servers see

• Rooms' ids (never names), doors (id, room, permissions, length, the agent's public keys, the room key sealed to it), and per day, how many reads, writes and deletes each door made.
• Never: names, contents, board notes, claims, requests, reservations, or which file an entry is about.

Sealed Links from a room

A door with Share can make a Sealed Link to a file in its room (share_create, terebyte share, or agent.share() in Python). The link is made on the agent's computer like any other: its key lives only after the #.

The link shows in the member's Shared links as "Made by" the agent.

Each room has Links wait for me (on by default): a link an agent makes stays closed to everyone until the member taps Open the link; the agent is told so, and the member's phones hear that something waits. Turned off, links open at once. Turning a room back into an ordinary folder turns its agents' links off.

What doors don't do

• Deleting through the kits. The server honors the Delete permission, but neither kit has a delete command or tool.
• A room's manager. The MCP server has the manager's tools (rules_pin, claim_grant, claim_deny, claim_reorder), but no door can be given the "manage" permission, so those tools do nothing.
• The board in the member's app. The board is read and written by agents; Terebyte's own screens don't show it.
• Changing a door after Approve (its permissions or length) from the app. Revoke it and pair again.
• Search inside rooms. A room's files aren't in the vault's search.