Skip to content

Writing an app that runs in a container

This part of the documentation is about the code inside a .dai file — the application itself, not the tooling that builds one and not the host that opens it. If you are building a host, you want the host bridge.

Start with Choose a shape. Solo, passable, session or broadcast: the answer decides which tables are shared and which constraints apply, and it cannot be fixed afterward by editing a table.

For an AI: fetch /llms-full.txt — see For AI models.

Find what you came for

One document

ONE-DOCUMENT

One document, many rows

Model every separate instance — a game, a match, a list, a save slot — as a row in the application's own schema, with a local setting recording which one is showing. Never offer a "new file": nothing in a running application can create a second document.

Why. A document is one sealed file with one database, and no call creates, forks or duplicates one. A "New Game" button that promises a new file promises something that cannot happen.

Applies to every shape · not checked by anything · ONE-DOCUMENT in Constraints

Sharing

SHARE-THROUGH-HOST

Sharing is the host's

To let a person share, put a Share button in the application and call window.dai.requestShare(). Never build a share flow of your own with the browser's share API. For a shared document the host sends a link, which is also how an invite reaches the other party.

Why. The host builds the link, shows the card, and asks whether to include the person's data; a substitute flow would carry none of that, and for a shared document a file sent any other way carries no key and can never sync.

Applies to every shape · not checked by anything · SHARE-THROUGH-HOST in Constraints

Released under the MIT License. Dynamic Application Interface standard.