feat(vault): VaultApi hub sync sub-client (ADR-052 D-4)#301
Closed
physercoe wants to merge 1 commit into
Closed
Conversation
Dart client for the zero-knowledge vault endpoints (hub store shipped in #299). Thin transport over the blind blob store — everything is opaque client-encrypted base64 (sealed by services/vault/vault_crypto.dart), the hub never sees plaintext. VaultApi (wired into the HubClient facade as `client.vault`): - pullVault / pushVault — pull the sealed bundle; push with optimistic concurrency (base_version; HubApiError 409 on stale -> pull, re-seal, retry). pullVault returns null on 404 so a fresh client knows to create. - getRecovery / setRecovery / deleteRecovery — the recovery envelope. - listDevices / putDevice / deleteDevice — per-device enrollment + wrapped keys. Mirrors the existing sub-client pattern (AttentionApi etc.); like its siblings it's a thin pass-through validated by flutter analyze + device testing (no live-server unit harness exists for sub-clients). Flutter SDK isn't available locally, so CI is the gate. Co-Authored-By: Claude Opus 4.8 <[email protected]>
Owner
Author
|
Landed directly on main (2df34c5) per the switch to working on main. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Dart HTTP client for the zero-knowledge vault endpoints (hub store in #299). Thin transport over the blind blob store — everything is opaque, client-encrypted base64 (sealed by
VaultCryptoin #300); the hub never sees plaintext.VaultApi(wired into theHubClientfacade asclient.vault)pullVault/pushVault— pull the sealed bundle; push with optimistic concurrency (base_version;HubApiError409 on stale → pull, re-seal, retry).pullVaultreturnsnullon 404 so a fresh client knows to create.getRecovery/setRecovery/deleteRecovery— the recovery envelope.listDevices/putDevice/deleteDevice— per-device enrollment + wrapped keys.Convention
Mirrors the existing sub-client pattern (
AttentionApietc.). Like its siblings it's a thin pass-through with no live-server unit test (none of the hub sub-clients have one — they're validated byflutter analyze+ device testing). Flutter SDK isn't available locally, so CI is the gate.Relationship to the other vault PRs
VaultCrypto(Dart). Produces the opaque strings this ships.This PR is independent of both at the code level (it moves opaque strings), so it compiles and merges on its own; end-to-end needs feat(hub): zero-knowledge SSH key-vault sync (ADR-052 D-4) + accept ADR-052 #299.
Follow-ups (not here)
DataPortServiceconnections+keys shape; retire the cleartext backup.🤖 Generated with Claude Code