Documentation

DOC / 09 / STATE

Hyphae verified sync

Append and replay durable history through signed attestations, fixed snapshots, authority policy, and consuming verification types.

In this guideHyphae verified sync
Getting startedProject structureCLI referenceDeveloper loopRouting and pagesRust viewsEvents and foldsSchemas and snapshotsHyphae verified syncTyped contentBrowser runtimeDOM ownershipAdaptive assetsArtifact trustErrors and diagnosticsBuild and deployCrates and APILicensing and policy

Hyphae is optional durability

Static PliegoRS sites require no database. Applications that need shared durable history can use Hyphae through pliego-hyphae protocol v2. The crate defines and verifies the client boundary; it is not the Hyphae service implementation.

Verify every append

An append request binds stream identity, ordered local events, idempotency identity, and expected cursor. The response remains untrusted until its page attestation and every receipt signature resolve through the same accepted authority policy.

Replay inside a fixed snapshot

The first pull discovers a terminal snapshot cursor. Every continuation is bound to that exact head; pages cannot regress, fork at the same position, advance beyond the snapshot, change completion, or omit the attestation even when no events are returned.

text
Latest(after) -> VerifiedPage(snapshot=S, next=A)
Exact(S, after=A) -> VerifiedPage(snapshot=S, next=S, complete=true)

Consume verified state

Verification returns consuming typestate: unverified responses cannot expose admitted application events, and verified pages can be applied only against the stream, cursor, snapshot, and authority that produced them. Persisted evidence must be replayed through the same checks.