Skip to main content

Web UI Notes

These notes describe the current Notary flow in the web app.

Main Flow Areas​

The core web notary experience centers on:

  • the dashboard
  • the create-proof dialog
  • the proof detail view
  • source and status labels
  • local browser proof storage
  • editor-history proof actions

Dashboard Flow​

The dashboard does four important things:

  1. loads proofs
  2. loads usage
  3. keeps the selected proof id in the route
  4. reselects the most recent proof after create

That means the page is built around a list-and-detail pattern, not a modal-only flow.

Create-Proof Flow​

The current create flow uses four dialog steps:

  1. proof type
  2. project
  3. storage
  4. file

Modes​

The dialog currently supports:

  • cloud
  • local

If proof quota is unavailable, the UI steers the user toward local mode.

Project metadata​

The create flow can attach:

  • projectId
  • projectName
  • sourcePath
  • taskId when tied to a task-backed project

Local Proof Path​

Important behavior details:

  • prefers IndexedDB-backed key and proof stores
  • falls back to in-memory stores when needed
  • uses a worker when available for local proof work
  • talks to notary endpoints with CSRF-aware fetch helpers
  • can later upgrade a stored local proof into an Attest receipt

In this web surface, "local proof" specifically means a browser-local proof. That is narrower than the broader product model, where Local Proofs can also be created on desktop.

The local proof database name is separate from the editor history notary database.

Local proof to Attest flow​

The current sequence is:

  1. load the saved local proof
  2. build the Attest init payload from the local proof
  3. POST /notary/attest/init
  4. build the Attest completion payload
  5. POST /notary/attest/complete
  6. fetch GET /notary/proofs/{proofId}/receipt
  7. save the returned receipt into the local record

That means the UI is preserving the original local proof lineage while adding the server-issued receipt and cloud proofId.

Remote Proof Path​

The cloud create sequence is:

  1. request upload URL
  2. upload bytes
  3. create proof with uploadId

The slice also handles:

  • proof listing
  • usage loading
  • proof detail loading
  • local proof attestation
  • bundle download
  • receipt download
  • anchor requests

For direct cloud proofs, the web app supports remote creation through /notary/proofs. That is separate from the local-proof Attest upgrade path.

Source and Status Labels​

For documentation, treat the broader product model as:

  • Local Proofs
  • Cloud Proof
  • Attest
  • Anchors

The labels below are the current labels for this specific web surface.

Source labels​

Current source labels:

  • Local browser proof
  • Local proof attest
  • Cloud proof

The web app also recognizes a text source kind.

Status labels​

Current friendly labels include:

  • Local proof
  • Attested
  • Verified
  • Awaiting device proof
  • Anchor queued
  • Anchoring
  • Anchored
  • Needs attention

Detail View and Downloads​

It currently supports download actions for:

  • local proof JSON
  • local proof capsule
  • receipt
  • remote bundle
  • stored original bytes
  • anchor artifact

The detail view also summarizes storage posture. That summary changes based on:

  • local proof with or without backup bytes
  • RECEIPT_ONLY
  • STORE_TREE
  • STORE_BYTES

The detail view also makes the Attest intent explicit:

  • local proofs can show Add cloud attest
  • the action text says the proof can be upgraded without re-uploading the file
  • attested local proofs can expose receipt download from the locally stored record

Editor History Integration​

Notary also appears inside section editor history.

The current editor-history model supports:

  • local snapshot proofs
  • later cloud attests
  • compare-plus-proof views
  • export of stored proof capsules That means notary in the web app is not limited to the standalone /notary screen.