CardanoWall Desktop: A Local Mail Client for Proofs of Existence

CardanoWall Desktop is an open-source desktop client for Label 309 — a way to keep your Proof of Existence records, identities, and sealed inbox on your own machine instead of in a browser tab. It feels like a mail client: an Inbox of sealed records addressed to you, a Sent view of everything you published, a Compose flow for new proofs, a local Explorer over the public on-chain record set, Contacts for receive addresses, and local identity management.

This article describes how it works, so you can decide whether it fits how you work.

The point is not just "a desktop app." The point is three properties a browser cannot fully give you: it is offline-first, it is vendor-neutral, and it is built so your private keys never leave the device.

What problem does the desktop app solve?

The web app is the easiest place to start. The desktop app is for people who want local ownership.

A browser is a fine place to create a quick proof, publish a record, or run an account-based workflow. Some people and companies need more than that:

a local, encrypted identity vault;
offline access to records they have already synced;
locally cached encrypted files;
a private inbox discovered by local decryption, not server-side routing;
a searchable local mirror of the public record set;
large-file workflows that stream instead of loading whole files into memory;
the ability to point at a self-hosted gateway;
fewer assumptions baked around any one hosted vendor.

CardanoWall Desktop is built for those people. It brings the Label 309 model onto your own machine and treats "offline" as a normal state, not an error.

Is CardanoWall Desktop a Cardano wallet?

No. It is not a wallet, and it is designed so you never confuse the two.

It does not custody ADA. It does not hold a wallet recovery phrase. It does not build or submit Cardano transactions, and it holds no chain or storage keys.

Publishing still goes through a Label 309 gateway, which owns the publish pipeline: pricing, upload, Cardano transaction building and submission, confirmation, reorg handling, indexing, and balance accounting. The desktop app is a client. It holds your Label 309 identities locally, prepares records, signs when you choose to sign, encrypts sealed payloads, decrypts incoming sealed records, verifies proofs, and talks to whichever gateway you configure. If you want the same separation from a script or a terminal, the open-source command-line tool does the same job headlessly.

Why is the desktop app open source?

Because software that handles identities, signatures, encrypted files, and long-term proofs should be inspectable.

If a tool touches your keys and your evidence, you should be able to read how it works, a security team should be able to audit it, developers should be able to build on it, and operators should be able to point it at their own infrastructure. The proof format is open, the gateway is open, and the desktop client is open too — under the same Apache-2.0 licence as the rest of the Label 309 code. A standard is only as usable as the tools around it, and those tools should not turn you into a captive customer.

What does "offline-first" mean here?

Offline-first means the local app stays useful when the network is unavailable, because a local database — not the network — is the source of truth for what you see.

The app keeps local state: synced records, inbox matches, sent records, contacts, identities, cached ciphertext, and (only if you opt in) cached decrypted files. When you are offline, you can still:

browse records you have already synced;
read your inbox;
decrypt cached sealed files;
verify cached records;
search your local data;
draft a proof to publish later.

Offline does not mean every action completes. Publishing a new proof still needs a gateway and a network connection. Fetching a ciphertext you never cached still needs storage access. But data you already synced does not vanish because the Wi-Fi dropped. (For the cases where offline is the whole point — air-gapped hashing and signing — see offline proofs.)

How does the desktop Inbox work?

The Inbox is a local view of sealed records your identities can open — and the server never learns which records are yours.

A gateway exposes a public stream of every Label 309 record. The desktop app syncs that stream into a local mirror. For each of your identities, it tries locally to open the sealed key slots using that identity's receive keys. If a slot opens, the record appears in that identity's Inbox.

This is deliberately not a server-side mailbox. The gateway's feed is recipient-blind: it carries no per-recipient field, so it cannot tell who a sealed record is for. Your client discovers that on its own, by trial-decryption. That is exactly why a local client fits sealed Proof of Existence so well — the same machine that holds your identity keys is the one place the inbox can be assembled.

What does the Sent view track?

The Sent view tracks the records you publish, through their whole lifecycle — and it verifies the result instead of trusting it.

A proof is not finished the moment you click submit. It moves through stages: drafted, quoted, uploading, publishing, submitted, confirming, confirmed — or failed and auto-refunded if the publish cannot complete. The desktop app keeps that lifecycle visible locally. It can show which gateway was used, which identity signed the record, whether the record was sealed, which recipients were selected, when the transaction confirmed, and whether the local verifier agrees that the on-chain record matches what the app prepared.

That last part is the important one. "Confirmed" should not mean "the gateway said so." The gateway builds and submits the transaction, so it is not something to take on faith — a buggy or hostile gateway could report a different transaction or misstate confirmation. So once a transaction hash exists, the app fetches the on-chain record and byte-compares it against the exact record it published before marking anything confirmed. This is standalone verification applied to your own outbox.

How are identities stored on the desktop?

Each identity is stored in a local, encrypted vault, and the secret seed never leaves the Rust core at the heart of the app.

Every Label 309 identity is rooted in one 32-byte Identity Seed. From that seed the app derives the identity's signing key and receive keys. The seed itself stays inside the local core: it is never sent to the webview that draws the interface, and it is never sent to any gateway. The interface only ever sees public projections — labels, fingerprints, public keys, receive addresses, and status. While the vault is unlocked, the seed lives in zeroizing memory and is wiped when you lock the app or it auto-locks on idle.

This split is the whole design: the seed is the portable backup and the thing worth protecting, so it is treated as the crown jewel. If you want the background on why a seed — not an account or a password — is the real identity, see your identity is a seed, and for the principle behind keeping it on-device, why keys never leave the device.

One honest limitation: keeping secrets in the local core defends against a malicious or buggy interface and against a stolen, locked vault file. It does not defeat a fully compromised operating system. While the app is unlocked, malware on the same machine could in principle read in-memory secrets — short unlock windows, auto-lock, and minimal dependencies reduce that exposure but cannot erase it, the same caveat any desktop wallet carries.

Can I use my own gateway?

Yes — and that is one of the main reasons the desktop app exists.

It works with any compatible Label 309 gateway. Point it at the official CardanoWall gateway for convenience, at a self-hosted gateway your company runs, or at a gateway behind someone else's product. The official one is at most a one-click convenience entry; it is never a default you did not choose. You supply the gateway's base URL and an account key, and the app probes the endpoint to confirm it speaks the standard before you rely on it.

The division is clean: the gateway owns the publish pipeline, the desktop owns the local client experience. That separation is what prevents lock-in. Your local app, your local identities, your local cache, and your standard records should not depend on one hosted interface.

What does the gateway see, and what does it never see?

A gateway sees what it needs to publish and run the service — and nothing that would let it read your sealed files or impersonate you.

It may see your account credential, price quotes, uploads, ciphertext, your balance, transaction status, public record bytes, and operational metadata. It does not see your Identity Seed, it does not see your recipient private keys, and it cannot decrypt your sealed files. The desktop app prepares and uses every secret locally; the gateway only publishes standard records and serves the public feed.

This does not mean a gateway can never misbehave. It can delay, fail, withhold a record, or misreport status. That is exactly why verification matters: a valid proof is checkable from the public on-chain record and a public Cardano explorer, not trusted because a gateway's interface says so.

What can I do with files when I am offline?

That depends on what you have synced and cached — and the app is honest about which files are safe to keep around.

Ciphertext can be cached freely, because it is already encrypted; re-opening a received file is then instant and works offline. Decrypted files are more sensitive, so any decrypted-file cache is opt-in, off by default, and itself encrypted. The default behaviour is to keep the ciphertext and decrypt on demand in memory.

A useful mental model:

public record metadata can be mirrored locally;
ciphertext can be cached for offline access;
decrypted files are handled carefully and only written to disk where you explicitly save them;
the Identity Seed stays protected in the vault;
verification runs locally for cached records and files.

That gives you the practical benefits of working offline without pretending decrypted files are risk-free. And a decrypted file is still just a file: once you save it, anyone you hand it to can read it. A sealed proof keeps content confidential to key holders; it does not make a recipient trustworthy.

Who is the desktop app for?

It is for people and organizations who work with proofs regularly enough that a browser tab stops being the right tool.

Good fits include:

legal and compliance teams receiving sealed evidence;
journalists and their sources handling confidential records;
companies publishing recurring compliance proofs;
developers and platform teams using Label 309 in automation;
AI teams preserving dataset and output commitments;
creators keeping signed proofs of original work;
auditors who need local access to evidence packages;
anyone who prefers self-hosted or vendor-neutral infrastructure.

If you only publish the occasional proof, the web app stays the simplest path, and the open-source command-line tool already lets you work without the website today. The desktop app is for sustained work.

What you get

It is a local-first product that behaves like serious evidence software, not a lightweight toy. What it gives you:

clear identity-backup prompts, so you never lose an identity by accident;
no wallet-seed confusion;
transparent verification states;
readable confirmation status;
careful, out-of-band receive-address handling;
local search across your records and opened files;
safe inline file preview;
multiple identities in one place;
contacts with checkable fingerprints;
a free choice of gateway;
honest error states instead of silent failures.

The standard gives you the proof model. The desktop app gives you the working environment around it. You can download it from the open-source code.

The short version

CardanoWall Desktop is the local client for Label 309. It syncs the public record set, holds your identities locally, discovers sealed inbox items by local trial-decryption, tracks the proofs you send (and verifies them on-chain), works offline with data you already synced, and connects to any compatible gateway.

The web app gives you convenience. The desktop app gives you local control.