Skip to content

Radical Rewrite of Architecture

Most digital systems start with an application, an account, or a platform database. Safebox starts with records.

That starting point is one contribution to a broader conversation. Timothy Bouma's essay The Niels Bohr Moment for Digital Architecture: suggests that the next generation of digital systems may benefit from a better vocabulary before it needs another diagram. The familiar language of users, applications, databases, APIs, identity, authentication, and authorization still matters, but it no longer explains everything our systems are being asked to do.

Digital records now replace paper documents. Software acts for organizations. AI agents exercise delegated authority. Digital assets behave like property. Legal rights can be represented entirely electronically. Once systems start making decisions, exercising authority, and creating legal consequences, it is reasonable to ask whether a database row and an audit log are enough of an explanation.

The useful questions become:

identity     -> who is participating?
intent       -> what are they trying to accomplish?
control      -> who can act on this object now?
recognition  -> what effect does a community or institution give the event?
evidence     -> why should anyone else believe it?

Safebox does not claim to finish that theory. It is an early working product direction that takes those questions seriously and leaves room for many other contributions.

There is also a historical prompt for the records-first turn. In The Medieval Innovation We've Misunderstood, Bouma suggests that credentials were not originally just portable identity tokens. Medieval letters, charters, writs, seals, and bills of exchange can be understood as portable records: they carried authority, event history, permission, status, and proof across distance.

The opportunity is to widen the question again. Alongside "who are you?", a records-first system can ask:

what happened?
who authorized it?
what changed hands?
what powers were granted?
what evidence travels with the record?
who can verify it away from the original issuer?

Safebox starts there: with portable records that can carry private control, public evidence, and viewpoint-dependent recognition. Identity remains important; it just does not have to carry every architectural responsibility by itself.

That shift is more than a storage choice. It changes what the app is allowed to be. Safebox Web is not the authority for the user's records, identity, funds, or evidence. It is an app that helps a person use portable records controlled by their own key, preserved through relays and blob stores, and connected to signed public evidence when needed.

In plain language:

wallet app     -> the thing a person uses
keys           -> what gives the person control
funds          -> value the person can hold or transfer
records        -> information and evidence the person needs to preserve
credentials    -> one important kind of record
OpenETR        -> signed evidence about exact transferable records

OpenETR is an experimental records-first framework for electronic transferable records. It anchors evidence to exact artifact digests and signed control events so a verifier can inspect what happened to a record without depending on the original application database.

The rewrite is not that credentials disappear. It is that credentials can be understood as a specialized kind of record, while leaving space for other record types with different lifecycles.

It is also not a claim that the world needs one new master architecture. The point is to experiment with separating concerns that are often collapsed into one product, one identity system, one credential format, or one platform database.

Records first

A records-first architecture treats a record as the object that must survive application changes, infrastructure outages, migrations, and changes in who is asked to recognize it.

In Safebox, a record can have several layers:

  • a private record controlled by the user's Acorn key;
  • an encrypted Original Record stored through Grove or another Blossom server;
  • relay-backed metadata and recovery state;
  • transferable ecash proofs associated with the Acorn; and
  • OpenETR evidence describing the origin and control history of an exact artifact.

The app becomes replaceable. The record remains portable.

Beyond conventional verifiable credentials

Verifiable credentials are often presented as issuer-to-holder-to-verifier messages. That model is useful, but many real-world records are not just static claims about a subject. They move. They are amended. They are controlled, transferred, encumbered, redeemed, revoked, replaced, or recognized differently by different parties.

OpenETR generalizes this by anchoring evidence to the exact object and its control graph:

artifact bytes -> object digest -> signed origin event -> signed control events

That turns verification into more than checking whether one issuer signed one credential. A verifier can ask:

  • Do these exact bytes match the object being evaluated?
  • Which key originated the object?
  • What signed events followed?
  • Who appears to control it now?
  • Are there competing histories or unresolved branches?
  • Which issuers, controllers, or attestors does this verifier recognize?

This is one way to extend the credential idea into transferable records and evidence graphs.

What a wallet needs to preserve

A wallet is the app or environment a person uses. It is not the whole thing that must survive.

People and communities need continuity for the resources inside and around the wallet:

  • keys that can recover authority;
  • funds that can be spent or reconciled;
  • records that can be read, moved, presented, and verified;
  • evidence about where a record came from and what happened to it; and
  • recognition rules that say who gives that evidence effect.

Safebox Web is a wallet app for those resources. It should be useful and trustworthy, but it should not be the only place those resources can live.

OpenETR in Safebox

Safebox Web can connect a private Acorn record to OpenETR without making the private record public.

Acorn protects the user's key and private record. Grove can store encrypted original bytes. Spurline or other Nostr relays can preserve events. OpenETR adds signed public evidence about an exact artifact: its digest, origin, and control history.

The boundary matters:

Acorn preserves private control.
Grove preserves encrypted bytes.
Spurline preserves local relay events.
OpenETR preserves signed object evidence.
Safebox Web helps the user operate the workflow.

Evidence is not recognition

A signature proves that a key signed an event. It does not automatically prove that a government, school, employer, community, or counterparty recognizes the event.

Safebox keeps those questions separate:

  • OpenETR preserves signed evidence.
  • Acorn controls private records and value.
  • Nostr and other social or institutional inputs can help identify recognized actors.
  • A verifier policy decides what effect to give the evidence.

That distinction is the heart of the rewrite. The system does not need one central database to decide what every record means. Different verifiers can recognize the same evidence under different rules.

Why this matters

A records-first architecture supports continuity across apps, devices, organizations, and communities. It can work with hosted services when they are available and local services when continuity matters most.

It also makes room for use cases that are awkward in ordinary app-centric systems:

  • private records with public proof of origin;
  • transferable records with signed control history;
  • community recognition during limited connectivity;
  • Continuity Payments: in-kind local payment clearing using transferable proofs, with finality deferred until mint reconciliation;
  • evidence that remains useful after the original application disappears; and
  • verifier policies that can explain why evidence is or is not recognized.

Safebox Web is one working app in that architecture and the practical foundation for Mainstay, the future unified application. Lockbox is the hardware-first appliance intended to run Mainstay and its supporting services locally:

Lockbox preserves local authority, continuity, and evidence.