Why Safebox Web?
Local-first approach
People need a usable place to work with portable keys, records, funds, and evidence. Most people do not want to operate directly through scripts, raw relay events, or wallet internals.
Safebox Web takes a local-first approach: people and communities should have a dependable path to their important funds, records, and evidence without giving up the convenience of connected services. Public infrastructure can help with reach, synchronization, and payments, while the state needed for continuity remains portable to infrastructure the user or community can run.
Local-first does not mean disconnected by default or isolated from the wider network. It means a device, provider, relay, or application can change without becoming the end of the user's wallet or records. This principle frames the rest of Safebox: connected when useful, locally dependable when circumstances change.
The app is not the authority
Safebox Web provides the human workflows:
- creating and connecting a wallet;
- reviewing balances and proof health;
- receiving and sending value;
- storing and reading private records;
- attaching protected original records;
- sharing or presenting records by QR; and
- claiming handles and using Lightning address flows.
The authority remains in the user's Acorn. The web app should be replaceable.
Practical continuity
For most people, the starting point is ordinary: they open Safebox Web through a web-connected service, check a balance, receive value, store a record, or present evidence. The experience should feel familiar and convenient.
The important difference is underneath. The app should not be the only place the wallet can live. If a hosted service is unavailable, a provider changes terms, or the wider internet is down, the same Acorn-controlled state should have a local continuity path.
In that situation, Safebox Web can fall back to local services:
- a local Acorn execution environment for keys, funds, records, and recovery;
- a local Spurline relay for signed events and wallet state;
- a local Grove service for protected original records and larger blobs; and
- later, nearby community infrastructure or mesh transport when wider connectivity is unavailable.
When the large providers go offline
Local-first becomes most important when the services people normally depend on are not available. A cloud application, public relay, Lightning provider, mint, DNS service, or even the wider internet can fail independently. Safebox is being designed so that the disappearance of one of those providers does not automatically make the community's own application, records, or previously issued funds disappear with it.
Mainstay is the in-development application intended to become that local-first provider. Running on a Lockbox or other community-controlled infrastructure, it can bring the familiar Safebox workflows close to the people using them. A local Mainstay deployment can use local Acorn execution, a local Spurline relay, and local Grove storage instead of waiting for a distant application provider to recover.
Payments can degrade deliberately instead of failing invisibly. Acorns can hold ecash that was issued while its mint was reachable. During an outage, Mainstay can help participants exchange that existing ecash through available local infrastructure and preserve the signed transfer events. The recipient can immediately see that funds have arrived, but Safebox keeps them pending rather than presenting them as mint-confirmed. When connectivity to the mint returns, Acorn checks the proofs, refreshes accepted value, and records the final result. Invalid or already-spent proofs do not become confirmed funds.
This is continuity, not the invention of a new source of money. A disconnected Mainstay cannot obtain authoritative proof state from an unavailable mint, complete a real Lightning settlement, or remove the credit risk of the issuer. It can preserve local operation, evidence of what was exchanged, and a clear queue of work to reconcile later. Communities can therefore choose how much provisional risk to accept during an emergency without confusing provisional receipt with final settlement.
Payment continuity follows the same pattern. In ordinary connected use, Safebox Web can use mints, Lightning, and direct Safebox-to-Safebox ecash transfers. It now also demonstrates Continuity Payments between Safebox addresses using previously issued ecash. The recipient sees the same simple result whether the sender had full connectivity or not: received value is pending until it can be finalized with the mint.
This creates a useful distinction on the wallet screen:
- Confirmed is mint-confirmed and spendable.
- Pending has been received and preserved but still awaits finalization.
The user can finalize pending transactions from the transaction page. When the mint is unavailable, those transactions remain pending and the confirmed balance stays unchanged. Connectivity can return later without hiding what was received or overstating what is final.
This is more than a display preference. A relay can establish that a signed transfer is available, while a mint determines proof spend state and Acorn checks whether the proof itself conforms to the protocol. Safebox Web presents those stages without pretending that one service answers every question.
Safebox Web proves this experience today. Mainstay is the future unified application that will carry it across keys, records, and payments. Lockbox is the hardware-first form of the local fallback: a small local home for Mainstay, Acorn, Spurline, Grove, and related services people may normally reach through a web-connected service.
The long-term goal remains simple:
Lockbox preserves local authority, continuity, and evidence.
Safebox Web is the app a person can use now. Acorn is the portable wallet and record state underneath it. Spurline preserves local relay events. Grove preserves encrypted blob availability. Mainstay will bring those pieces into one unified application, and Lockbox will provide the appliance that keeps them available locally when continuity matters.