Choose a shape

Start here. Every DAI application is one of four shapes, and the shape is decided before a single table is written. It decides which tables are shared, whether there is a session, and which of the constraints apply to you.

It comes first because it cannot be fixed afterward by editing a table. The first chess application written for DAI was never asked this question: it marked its tables shared and then stored the board in one of them, which is wrong the moment two copies merge. Why nothing derived is stored shows that application beside the correct one.

The two questions

1. Will anybody but the person who made this change its data — someone else, or the same person on another device, with both copies' changes kept?
   • Yes: It is passable or session. Ask the next question.
   • No: It is solo. If you are sending it out for other people to read, it is broadcast — which today is built exactly as solo.
2. Is it a closed group of a known size, where a copy forwarded to somebody else must not let them take part?
   • Yes: Session.
   • No: Passable.

The four shapes

Solo

One person, one document.

• Declare: No replicated tables.
• What the runtime does: Ordinary SQLite. Whole copies replace each other when the file is saved; nothing merges.
• For example: a packing list, a habit tracker, a recipe box.
• In the repository: examples/packing-list

Passable

One person across their own devices, or a document handed around where every copy's changes are kept.

• Declare: Tables marked -- dai:replicated, and no session profile.
• What the runtime does: Rows are appended, never changed in place, and copies merge by union. There is no roster: anyone holding a copy participates.
• For example: a shared receipt tracker, a household inventory, a trip plan two people edit.
• In the repository: examples/receipts

Session

A closed group admitted by invite — today, two people: the creator and one invitee.

• Declare: Tables marked -- dai:replicated, plus the profile line -- dai:profile session max_parties=N.
• What the runtime does: Everything in passable, plus seats: the creator mints its own and one open seat, an invitee binds the open one, and only members' rows are read. A forwarded copy cannot join. There is no way yet to seat a third person, so a group larger than two cannot be a session.
• For example: a game by message, a two-party agreement, anything turn-based.
• In the repository: examples/tic-tac-toe

Broadcast

One publisher writes; recipients read.

• Declare: Nothing. Mechanically it is solo.
• What the runtime does: None yet. The separation between publisher and reader is a convention the application keeps, not something the runtime enforces: the confidentiality tier that makes it real is not implemented. A recipient's copy is an ordinary solo document they can write to.
• For example: a statement, a report, a reference tool.

What the runtime actually knows

The runtime tells apart three configurations, not four: no replicated tables, replicated tables, and replicated tables with a session profile. Solo and broadcast are the same thing to it today. The difference between a publisher and the people reading their document is a promise the application makes, and nothing enforces it until the confidentiality levels exist — so a broadcast application is built exactly as a solo one, and says nothing it cannot back.

Then

• Solo — Your first app walks through one.
• Passable — Share a table, and the receipts application in Examples.
• Session — Your first two-player app, then Run a session.
• Broadcast — build it as solo, and read SHAPE-BROADCAST-CONVENTION.