← DemosShared system demo

The Village Hall

A bingo night, running on the phones in the room.

One phone leads the evening. The phones that sell cards and call balls attach to it directly, over whatever Wi-Fi the hall already has. The players' phones attach too.

Nothing else takes part. There is no server to reach, no database to query and no account to create — not as a simplification for a demo, but because a journaled program does not need them.

No server·No database·No account

The question

What does an application still need from the outside world, when everyone using it is already in the same room?

The topology

Everything that takes part is in the room.

THE HALL — ONE WI-FI, NO UPLINK REQUIREDSellsat the doorCallsthe ballsORGANIZERDirectorholds the journalof the eveningPlaysown journalPlaysown journalPlaysown journalPlaysown journalreplicates the whole journaltold each ballNO SERVER · NO DATABASE · NO ACCOUNT

Ncubo.Puppeteer 2.0.1-beta.10000 · .NET MAUI on Android

What is running

Three programs, and only one of them knows there are phones.

The game

BingoEngine

The card, the balls, the figures in play, the round, and the correction when a ball is keyed wrong. It knows nothing about phones.

239tests, green
The evening

Village

The elder who governs the festival, the merchants who sell at the door, the villagers who buy, the prizes promised and the pleas to undo a sale. The part a hall recognizes and a game engine has no business knowing.

193tests, green
The staging

The app

A .NET MAUI application for Android. It hosts the actors, holds the journal, draws the screens and carries messages between handsets.

1binary, four roles

Neither domain project references Puppeteer. Both compile against the base class library and nothing else, so the substrate enters at the application and never reaches the rules.

01Where the authority sits

No server. The room is the network.

The organizer's phone promotes itself to Director. Every other phone attaches to it directly: no broker in the middle, no address that resolves outside the building.

The handshake is a QR code on the organizer's screen. It carries six lines, and they are the whole of what one phone needs to know about another.

Once a phone is through the door it receives the entire history from entry zero, and arrives current without replaying a decision of its own. It does not recompute the evening. It receives it.

The address
where that phone answers, on the hall's own network
The fingerprint
of a certificate the phone signed for itself the first time it was opened, and keeps
Who invites
the identity of the journal doing the inviting
Three channels
coordination, replication and commands — separate addresses for separate traffic

cloud and microservice ecosystems become libraries the program invokes rather than habitats the program inhabits

Paper 07 · After the Substrate
02Where the evening is kept

No database. A folder on each handset.

Every phone in the room keeps its own journal, and a journal is a directory in the application's private storage. There is no schema to migrate, no connection string, no engine to install and nothing to be reachable.

This is what makes the operational questions collapse into one another. Backing up the evening is copying the folder. Handing it to another phone is sending the same entries. Coming back after the signal dropped is replaying what arrived late.

In the substrate's own laboratories an entry encodes to between 33 and 96.7 bytes, against 118 to 910.7 for the same operation written out in full — and compressing the written-out form afterwards closes the gap only to fourfold, because the saving is in how the operation is named rather than in how the bytes are packed. Those are measurements of Puppeteer, not of this evening. What they say about the hall is that a night of bingo is a small file.

For a journaled program, deployment is replay, replication is sharing history, backup is copying the program, and offline operation is delayed replay.

Paper 05 · The Journal as Substrate
03What never has to travel

The card is not stored. It is derived.

The number printed on the paper card is not a key into a table of cards. It is the card. Twenty-four numbers fall out of it by a keyed hash, the same way on every handset, so a phone that has never heard of that card can draw it correctly the moment someone reads the number aloud.

Nothing about a card is transmitted, stored or synchronized. A seller hands over a printed card and the buyer's phone already agrees with it.

Cardface Of(CardNumber number)
    stream  = HMACSHA256("bingo75.cardface.v1", number)
    columns = five bands drawn from that stream
The version string is part of the key, so a future change to the layout is a different name rather than a silent change to every card ever printed.
04What travels instead

The players are told verbs, not state.

When a ball is called, no phone receives a board. Each one receives the fact that a ball came out, and applies it to its own journal — the same operation the organizer performed, performed again locally.

A phone that closes and reopens does not ask anyone what it missed, because the marks were never only in memory. And a ball carries the round it belongs to: keying the wrong number twice in one evening is two corrections, not a repetition of the first.

ListenAs(role)
    .Told("Bolita").With<int>("numero")
        .Command("game.RegisterDraw(@numero);")
    .Told("Correccion").With<int>("malo").With<int>("bueno")
        .Command("game.CorrectDraw(@malo, @bueno);")
There is no switch over message types. What arrives is bound to the operation it names, and the operation is the same one the rules already had.

Recording cross-actor messages as program operations preserves continuity edge by edge, without orchestration.

Paper 04 · Preserving Semantic Continuity Across Actors
The four equivalences

The operations did not go away. They stopped being machinery.

Deploymentisreplay

A new version opens an evening that was created by the old one. The rules gained a constructor rather than changing one, because the journal re-runs what it already wrote.

Replicationissharing history

A phone that joins the hall receives the journal from entry zero and is current, without writing a line of its own.

Backupiscopying the program

The evening is a folder in the app's private storage. Copying it is the backup.

Offline operationisdelayed replay

What could not be delivered waits in an outbox and is applied when the phone is reachable again.

None of the four was built for this application. They are properties of the substrate it is written on, and this is what they look like when the substrate is a phone in a parish hall rather than a datacenter.

What this does not claim

The boundary of the demonstration.

A system is credible in proportion to what it declines to assert. Four things this page is not saying:

  • The byte figures quoted are the substrate's, measured in the published laboratories of Paper 05 — not measurements of this application.
  • This is not a resilience result. No phone was killed and no partition induced to produce it.
  • The 432 green tests cover the two domain projects: the rules of the game and the rules of the evening.
  • Everyone is on one network. That is not a limitation working around the absence of a server — it is the claim. The hall is the network.
What the demo shows

The substrate does not remove the operations.

It removes the machinery that used to perform them.

The evening remains one coherent history.

Every phone holds the part of it that is its own.

Nothing outside the room is required for either.

Follow it further.

The app

Velada, on Android

The evening as the hall uses it: one application, and the phone decides whether it leads, sells, calls or plays.

Coming to Google Play
The basis

The Journal as Substrate

The paper that states the four equivalences, with the laboratories that measure them.

Read the paper
The mechanism

The Stage Manager

Five cases on the two mechanisms this evening is built from: one character standing on several machines, and two characters speaking.

See the series