Multiplayer

A person is not a single Markdown file. A person is an author who contributes many documents, and often also an entity the graph holds facts about. Multiplayer is a shared space where everyone’s notes flow into one file map and one fact graph, with provenance and permissions on top.

The substrate: a shared space, not a git repo

An earlier design used a shared git repository as the multiplayer substrate. That is rejected: git is dev-facing and a poor fit for how agents continuously append and revise memory.

A shared memory in Bezial is a space - one object-store namespace with its own versioned storage and append-only audit log. Everyone in the space writes into it through the server-owned write path (serialized per file, last-writer-wins), and the derived graph merges their notes. This delivers the collaboration guarantees that mattered about git, without git:

Multiplayer need	How the space provides it
Concurrent edits	Server-owned writes, serialized per file, last-writer-wins
“Who added this fact?”	The append-only audit log: who / what / when / permission result / diff
History of the team’s memory	Per-object version history + the audit log
Roll back a bad ingest	Restore a prior object version (itself a new write)
Rebuild after a change	Re-extract only the touched sections

What a shared space adds

• Provenance on every fact. Each fact is stamped with its source document and author. Two people disagreeing becomes two attributed facts, and bi-temporal validity decides which is current without deleting either. Contradiction is scoped to the same author, so one person’s write can never archive another’s fact.
• Permissions. Visibility is private or space, plus an explicit read-grant list (see Permissions). Personal and shared memory live in one space, separated by scope, not by separate stores. recall() and both views filter per fact by the caller’s identity.
• Person as entity and as author. “Facts about Alice” (entity) and “facts Alice contributed” (author) are different queries. Keeping both lets an agent reason about people and about who taught it what.
• Conflict surfacing. When two authors assert contradictory facts, both are kept and attributed; surface the disagreement in the view rather than silently picking one.

Asynchronous by design

Multiplayer here is asynchronous: writes land in the space, the graph re-derives from the committed files, and every reader’s recall settles the relevant pending changes before answering. That covers teams and multi-agent setups cleanly, because the graph is a pure function of one ordered file history - it can be stale, never contradictory.

Real-time simultaneous editing of the same document at the same instant (a live CRDT-style sync layer) is explicitly out of scope: writes are serialized per file, and last-writer-wins is the settled model.

How it fits together

Everyone - people and agents alike - contributes documents into one space. Their notes interlink in the file map; their facts merge in the fact graph, each carrying who said it and who may see it. The audit log records every change, and permissions keep private memory private even as entities merge.