Part of #457.
Description
The injectable-signer seam from #458 covers ordinary CLI commands only. Three surfaces still hardcode private-key handling and cannot use keystore, keychain, or any future backend:
- Pinning server: builds private-key/session-key configs directly (
src/filecoin-pinning-server.ts).
- Upload action: requires
walletPrivateKey and calls initializeSynapse({privateKey}) (upload-action/src/inputs.js, upload-action/src/upload.js).
- Session owner commands: require
PRIVATE_KEY and call privateKeyToAccount() directly (src/session/run-authorize.ts, src/session/run-revoke.ts; run-create.ts passes a raw key into createSessionKey()).
Route all three through the same auth resolution the CLI uses, so every backend added under #457 works everywhere without per-surface wiring.
This child is the prerequisite for the hosted-MCP and daemon deployment shapes: until it lands, only the CLI can consume session keys, keystore, or an injected viem Account, so anything like an MCP server on a VPS or a long-running filecoin-pin server is stuck on raw PRIVATE_KEY.
Acceptance criteria
- Pinning server consumes the shared auth resolution (or an equivalent shared config builder) instead of building private-key/session-key configs inline.
- Upload action auth flows through the same resolution (pairs with the session-key child's
sessionKey/walletAddress inputs).
session create|authorize|revoke accept an owner signer from any backend, not only PRIVATE_KEY; core session helpers take a viem Account where practical.- Library users keep the direct
initializeSynapse({account}) path unchanged.
Notes
The server is the surface with the worst exposure profile: a long-running daemon holds the decrypted key in memory for its lifetime, unlike one-shot CLI commands. Worth stating in the server docs when this lands. Depends on the keystore child for anything beyond parity with the existing auth modes; the refactor itself can land first.
Part of #457.
Description
The injectable-signer seam from #458 covers ordinary CLI commands only. Three surfaces still hardcode private-key handling and cannot use keystore, keychain, or any future backend:
src/filecoin-pinning-server.ts).walletPrivateKeyand callsinitializeSynapse({privateKey})(upload-action/src/inputs.js,upload-action/src/upload.js).PRIVATE_KEYand callprivateKeyToAccount()directly (src/session/run-authorize.ts,src/session/run-revoke.ts;run-create.tspasses a raw key intocreateSessionKey()).Route all three through the same auth resolution the CLI uses, so every backend added under #457 works everywhere without per-surface wiring.
This child is the prerequisite for the hosted-MCP and daemon deployment shapes: until it lands, only the CLI can consume session keys, keystore, or an injected viem
Account, so anything like an MCP server on a VPS or a long-runningfilecoin-pin serveris stuck on rawPRIVATE_KEY.Acceptance criteria
sessionKey/walletAddressinputs).session create|authorize|revokeaccept an owner signer from any backend, not onlyPRIVATE_KEY; core session helpers take a viemAccountwhere practical.initializeSynapse({account})path unchanged.Notes
The server is the surface with the worst exposure profile: a long-running daemon holds the decrypted key in memory for its lifetime, unlike one-shot CLI commands. Worth stating in the server docs when this lands. Depends on the keystore child for anything beyond parity with the existing auth modes; the refactor itself can land first.