LOG // TAXBOX · TAURI · STS

Pair the desktop. Mount the vault.

A Tauri desktop client pairs to a TaxBox user, then mounts org-scoped storage with short-lived STS — same vault rules as the web, on a local drive path.

Project: TaxBox
Type: Field note
Audience: Builders · operators

DESKTOP_PAIRING STS JUICEFS TAURI

Flow

Desktop starts pairing → shows a short userCode, keeps deviceCode secret
Signed-in web approves the code
Desktop polls → one-shot deviceToken (~90 days)
List safes → request vault credentials → STS under orgs/{id}/; remount on a timer

What pairing is not

Pairing does not transfer workspace ownership or decide who pays (firm pool vs client pays). It only binds a device to a user. Billing and membership stay elsewhere.

Topology sketch

TaxBox Desktop (Tauri)
        │
        │  pairing/start · pairing/token · organizations · vault-credentials
        ▼
┌───────────────────┐
│  api-gateway      │  device token → x-user-* headers
└─────────┬─────────┘
          │
    ┌─────┴──────┐
    ▼            ▼
 auth-service   vault-service
 (pair + device) (STS / entitlement)
    │            │
    └──── Postgres + JuiceFS S3 ────┘
              prefix: orgs/{id}/

Design surface

Soft purple product UI (TaxBox operator surface)
Pairing code as a large, scannable artifact
Desktop “Z: drive” metaphor for mount success
Same identity headers as browser after pair (x-user-*)

Design bias

Accountants live in the filesystem. Pairing + STS keeps the same tenancy rules as the web vault while meeting them where they work — without turning every laptop into a long-lived secret store.

Takeaway

Device binds to user; STS mounts orgs/{id}/ under the same membership and entitlement checks as the browser. Secrets stay short-lived; ownership and billing stay off the pairing path.