19. Handlers run on every device, the same way
A clerk runs while an envelope is applied, on every device, from inputs every device has, so stamps and refusals need no server; the writer refuses before the envelope exists, readers drop the bad edit and apply the rest; there is no rollback.

19. Handlers run on every device, the same way

A clerk runs while an envelope is applied, on every device, from inputs every device has, so stamps and refusals need no server; the writer refuses before the envelope exists, readers drop the bad edit and apply the rest; there is no rollback.

It is how validation and derived fields work without a central authority.

A hosted backend stamps fields for you. Created at. Created by. There is no server here. So who stamps them?

A handler does. Think of a clerk. Every dataset has one. It runs while an envelope is applied, on every device, identically.

It reads only what every device has. The envelope's author. Its time. The record's previous state. From that it derives the stamp. Same input everywhere, same stamp everywhere.

A clerk can also refuse. Author-only edits. A required field. On the writing device, the envelope is refused before it exists. On every other device, the bad edit is dropped and the rest applies.

There is no rollback. An envelope in the chain is signed and named by its hash. Others may have built on it. Correction is another envelope.

Nothing a clerk decides may depend on this device alone. Then every device reaches the same rows, in any order.

Check yourself. What may a clerk read when it decides a stamp?

Do you like what you are reading? Subscribe to receive updates.

Unsubscribe anytime