Support keystore-based auth so users do not paste raw private keys

[SgtPooki]

Description

filecoin-pin only accepts wallet auth as PRIVATE_KEY=0x... env var. Users hand the CLI, server, and GitHub Action raw private keys. No encrypted-at-rest option, no policy gating, no OS keychain integration.

Impact

• CI users put raw keys in GitHub Actions secrets when an encrypted artifact would be safer.
• Local users with multiple wallets juggle env vars instead of named identities.
• Server daemon operators leave keys readable in process env / shell history.
• Blocks adoption from teams with key-handling policies.

Proposed avenues

Three tiers, additive. Resolver order: explicit flag → keystore → PRIVATE_KEY → devnet auto-resolve.

1. Encrypted Keystore v3 (port from synapse-sdk)

   • synapse-sdk PR #554 ships keystore in its example CLI (examples/cli/src/{client,commands/init,config}.ts). Port the pattern into src/core/keystore/.
   • CLI: keystore create|import|list|remove, --keystore <name> flag, KEYSTORE_PASSWORD env for non-interactive.
   • Storage: platform data dir under keystores/<name>.json.
   • Lowest integration risk, unblocks CI via KEYSTORE_PASSWORD secret + committed encrypted JSON.
   • Universal baseline (works in Node, browser-safe, all platforms).

2. OpenWallet Standard (openwallet.sh)

   • @open-wallet-standard/core + @open-wallet-standard/adapters (viem). In-process, policy-gated signing. Filecoin is a first-class chain.
   • CLI consumes a wallet ID; users manage wallets via ows CLI.
   • synapse-sdk is already viem-native and initializeSynapse() in src/core/synapse/index.ts already accepts a pre-built viem Account, so the OWS viem adapter slots in with no SDK plumbing changes.
   • Platform coverage: napi-rs prebuilt binaries published on npm for linux-x64-gnu, linux-arm64-gnu, darwin-x64, darwin-arm64. No win32-x64-msvc or musl/Alpine artifact on npm today. The Rust crate itself is cross-platform (winapi is in Cargo.lock), so a Windows prebuilt is feasible upstream — just not shipped yet. GitHub Action default runners install cleanly with no Rust toolchain.
   • Node-only (CJS loader uses fs / child_process). Tier 2 must stay out of browser exports; ship in CLI, server, and Action only.
   • Windows and Alpine users fall back to tier 1 until upstream publishes those prebuilts (or we vendor a build).

3. OS-native keychain wrapper

   • macOS Keychain / Windows Credential Manager / libsecret via keytar or @napi-rs/keyring.
   • Stores the keystore password (tier 1), not the raw key. Local-dev DX.

Out of scope

• Hardware wallets (Ledger/Trezor) — separate issue if requested.
• Devnet path keeps auto-resolving from devnet-info.json.

Next step

Land tier 1 first. Layer tier 2 on top as opt-in for supported platforms.

[Apha205]

@SgtPooki
@HavenCTO and I would like to take on OpenWallet Standard. Same problem hit us building Haven — our EthereumCryptoAdapter does env:VAR and 0x..., which is exactly what this issue wants to fix: https://github.com/Haven-hvn/haven-adapters/blob/main/src/ethereum/EthereumCryptoAdapter.ts

We already use filecoin-pin in other projects and need OWS ourselves. PR #458's wiring is solid; we can resolve conflicts, exercise real signing on Calibration, and get it merge-ready.
Curious how OWS's built-in policy model compares to something like Cedar — specifically around fine-grained per-operation signing rules. If OWS already covers that well, great. If there are gaps, Cedar might be worth layering on top. Happy to put together a comparison if useful.

Is outsourcing this to us on the table (grant or fundings etc)?