Rebrand alknet-vault -> alkvault
Rename the crate from alknet-vault to alkvault across source and docs: - Cargo.toml: package name and lib name (alknet_vault -> alkvault) - src/ doc comments and doc-test use statements - tests/ use statements and one string literal Convert references to non-vault alknet ADRs (003, 005, 008, 010, 014, 064) that were broken local links into @alkdev/alknet: cross-repo references, matching the alktype sibling pattern. Local ADR/OQ references are now proper links. Rewrote monorepo path references (crates/alknet-vault/src/...) to the flat layout (src/...). Fixed sdd_process.md package name (@alkdev/storage -> @alkdev/alkvault). ADR/OQ renumbering is deferred to a subsequent pass per the alknet- origin numbering convention. Generic prose 'vault' and type names (VaultServiceHandle, VaultServiceError, etc.) are unchanged. Build, 108 tests, and clippy all pass clean.
This commit is contained in:
glm-5.2 committed
1 parent
8fd3428544
commit
110146870a
25 files changed
+191
-125
No files matched your search
@@ -6,12 +6,12 @@ Accepted
|
||||
|
||||
## Context
|
||||
|
||||
alknet-vault provides BIP39 mnemonic generation, SLIP-0010 Ed25519 HD key
|
||||
alkvault provides BIP39 mnemonic generation, SLIP-0010 Ed25519 HD key
|
||||
derivation, BIP-0032 secp256k1 derivation (feature-gated), and AES-256-GCM
|
||||
encryption. It holds the master seed — the root of trust for all derived keys
|
||||
and encrypted credentials in the alknet system.
|
||||
|
||||
The question is: what does alknet-vault depend on? The candidates:
|
||||
The question is: what does alkvault depend on? The candidates:
|
||||
|
||||
1. **Depend on alknet-core** for shared types (errors, maybe Identity). This
|
||||
pulls QUIC, quinn, iroh, rustls, and tokio runtime dependencies into the
|
||||
@@ -64,7 +64,7 @@ wraps the vault (see ADR-025, OQ-021).
|
||||
|
||||
## Decision
|
||||
|
||||
**alknet-vault has zero alknet crate dependencies.** It depends only on
|
||||
**alkvault has zero alknet crate dependencies.** It depends only on
|
||||
external crates (`bip39`, `ed25519-bip32`, `aes-gcm`, `sha2`, `hmac`,
|
||||
`secp256k1`, `serde`, `zeroize`, `thiserror`, `base64`, `rand`). ADR-025
|
||||
dropped `irpc`, `irpc-derive`, `postcard`, and `tokio` — the vault no longer
|
||||
@@ -75,18 +75,18 @@ dependency.
|
||||
The vault does not depend on:
|
||||
- `alknet-core` — no shared types, no `Identity`, no `AuthContext`
|
||||
- `alknet-call` — no `OperationSpec`, no `OperationContext`, no call protocol
|
||||
- `alknet-vault` does not implement `ProtocolHandler` — it has no ALPN (see
|
||||
- `alkvault` does not implement `ProtocolHandler` — it has no ALPN (see
|
||||
ADR-019)
|
||||
|
||||
Dependency flow is strictly one-directional:
|
||||
|
||||
```
|
||||
alknet-vault (standalone)
|
||||
alkvault (standalone)
|
||||
↑
|
||||
alknet (CLI binary) — the only crate that depends on alknet-vault
|
||||
alknet (CLI binary) — the only crate that depends on alkvault
|
||||
```
|
||||
|
||||
No handler crate depends on alknet-vault directly. Handlers receive derived
|
||||
No handler crate depends on alkvault directly. Handlers receive derived
|
||||
material through capabilities injected by the assembly layer (ADR-014). The
|
||||
CLI binary is the sole integration point (ADR-008, ADR-019).
|
||||
|
||||
@@ -200,14 +200,22 @@ makes the freeze explicit and enforceable by review.
|
||||
|
||||
## References
|
||||
|
||||
- ADR-003: Crate decomposition (alknet-vault is standalone)
|
||||
- ADR-005: irpc as call protocol foundation (superseded by ADR-064 — irpc
|
||||
was never integrated into alknet-call; the vault no longer uses irpc
|
||||
either — see ADR-025)
|
||||
- ADR-025: Vault local-only dispatch (dropped irpc from the vault; the
|
||||
vault uses direct method calls, no actor, no remote capability)
|
||||
- ADR-008: Vault integration point (CLI-embedded, assembly-layer only)
|
||||
- ADR-014: Secret material flow and capability injection
|
||||
- ADR-019: Vault assembly-layer-only access
|
||||
- [crates/vault/README.md](../README.md)
|
||||
- Implementation: `crates/alknet-vault/`
|
||||
- `@alkdev/alknet: ADR-003` — crate decomposition (alkvault is standalone)
|
||||
- `@alkdev/alknet: ADR-005` — irpc as call protocol foundation (superseded
|
||||
by ADR-064 — irpc was never integrated into alknet-call; the vault no
|
||||
longer uses irpc either — see ADR-025)
|
||||
- [ADR-025](025-vault-local-only-dispatch.md) — vault local-only dispatch
|
||||
(dropped irpc from the vault; the vault uses direct method calls, no
|
||||
actor, no remote capability)
|
||||
- `@alkdev/alknet: ADR-008` — vault integration point (CLI-embedded,
|
||||
assembly-layer only)
|
||||
- `@alkdev/alknet: ADR-014` — secret material flow and capability injection
|
||||
- [ADR-019](019-vault-assembly-layer-only.md) — vault assembly-layer-only
|
||||
access
|
||||
- [README.md](../README.md)
|
||||
- Implementation: `src/`
|
||||
|
||||
> Cross-repo references (`@alkdev/alknet: ...`) point to the parent
|
||||
> `@alkdev/alknet` workspace where this crate originated. The artifacts
|
||||
> are preserved there as historical context; they are not part of this
|
||||
> standalone repo.
|
||||
@@ -73,7 +73,7 @@ Handlers never:
|
||||
- Hold a `VaultServiceHandle` reference
|
||||
- Call `derive_*`, `encrypt`, or `decrypt` directly
|
||||
- Receive the master seed or mnemonic
|
||||
- Import `alknet_vault` as a dependency
|
||||
- Import `alkvault` as a dependency
|
||||
|
||||
Handlers receive secret material through `OperationContext.capabilities`
|
||||
(ADR-014). The `Capabilities` type holds non-serializable, zeroized secret
|
||||
@@ -135,7 +135,7 @@ that door; it simply does not open it.
|
||||
(ADR-025) — no remote dispatch capability exists in the vault crate. If
|
||||
remote vault access is needed in the future, it requires a separate
|
||||
vault-server crate that depends on both alknet-core (for auth) and
|
||||
alknet-vault (for the handle), with a heavily restricted mechanism
|
||||
alkvault (for the handle), with a heavily restricted mechanism
|
||||
(admin scope, mTLS-only, never expose the mnemonic over an
|
||||
unauthenticated channel) and its own ADR.
|
||||
|
||||
@@ -160,10 +160,17 @@ that door; it simply does not open it.
|
||||
|
||||
## References
|
||||
|
||||
- ADR-003: Crate decomposition (alknet-vault is standalone)
|
||||
- ADR-008: Vault integration point (CLI-embedded, capability source)
|
||||
- ADR-014: Secret material flow and capability injection (the injection
|
||||
mechanism this ADR relies on)
|
||||
- ADR-018: Vault as standalone crate (the independence this ADR preserves)
|
||||
- [crates/vault/service.md](../service.md)
|
||||
- [crates/vault/README.md](../README.md)
|
||||
- `@alkdev/alknet: ADR-003` — crate decomposition (alkvault is standalone)
|
||||
- `@alkdev/alknet: ADR-008` — vault integration point (CLI-embedded,
|
||||
capability source)
|
||||
- `@alkdev/alknet: ADR-014` — secret material flow and capability injection
|
||||
(the injection mechanism this ADR relies on)
|
||||
- [ADR-018](018-vault-standalone-crate.md) — vault as standalone crate
|
||||
(the independence this ADR preserves)
|
||||
- [service.md](../service.md)
|
||||
- [README.md](../README.md)
|
||||
|
||||
> Cross-repo references (`@alkdev/alknet: ...`) point to the parent
|
||||
> `@alkdev/alknet` workspace where this crate originated. The artifacts
|
||||
> are preserved there as historical context; they are not part of this
|
||||
> standalone repo.
|
||||
@@ -220,11 +220,20 @@ not another version index. See OQ-22 (key rotation) and ADR-018
|
||||
|
||||
## References
|
||||
|
||||
- ADR-018: Vault as standalone crate
|
||||
- ADR-019: Vault assembly-layer-only access
|
||||
- [ADR-018](018-vault-standalone-crate.md) — vault as standalone crate
|
||||
- [ADR-019](019-vault-assembly-layer-only.md) — vault assembly-layer-only
|
||||
access
|
||||
- [encryption.md](../encryption.md) — AES-256-GCM, EncryptedData
|
||||
- [mnemonic-derivation.md](../mnemonic-derivation.md) — SLIP-0010, PATHS::ENCRYPTION
|
||||
- OQ-20: Salt/KDF Phase B (resolved by this ADR)
|
||||
- OQ-22: Key rotation mechanism (still open — this ADR defines v2 but not the rotation workflow)
|
||||
- TypeScript predecessor: `/workspace/@alkdev/storage/src/graphs/crypto.ts`
|
||||
- TypeScript secret graph: `/workspace/@alkdev/storage/src/graphs/modules/secret-graph.ts`
|
||||
- [OQ-20](../questions/020-salt-kdf-and-encryption-key-derivation-method.md) —
|
||||
Salt/KDF Phase B (resolved by this ADR)
|
||||
- [OQ-22](../questions/022-key-rotation-mechanism.md) — key rotation
|
||||
mechanism (still open — this ADR defines v2 but not the rotation
|
||||
workflow)
|
||||
- TypeScript predecessor: `@alkdev/storage: src/graphs/crypto.ts`
|
||||
- TypeScript secret graph: `@alkdev/storage: src/graphs/modules/secret-graph.ts`
|
||||
|
||||
> Cross-repo references (`@alkdev/...: ...`) point to other packages in
|
||||
> the `@alkdev` org where this crate originated. The artifacts are
|
||||
> preserved there as historical context; they are not part of this
|
||||
> standalone repo.
|
||||
@@ -244,9 +244,10 @@ are expected.
|
||||
|
||||
## References
|
||||
|
||||
- ADR-020: HD derivation for encryption keys (this ADR builds on the
|
||||
version-indexed path scheme)
|
||||
- OQ-22: Key rotation mechanism (resolved by this ADR)
|
||||
- [ADR-020](020-hd-derivation-for-encryption-keys.md) — HD derivation for
|
||||
encryption keys (this ADR builds on the version-indexed path scheme)
|
||||
- [OQ-22](../questions/022-key-rotation-mechanism.md) — key rotation
|
||||
mechanism (resolved by this ADR)
|
||||
- [encryption.md](../encryption.md) — AES-256-GCM, EncryptedData
|
||||
- [service.md](../service.md) — encrypt, decrypt, rotate methods
|
||||
- [mnemonic-derivation.md](../mnemonic-derivation.md) —
|
||||
|
||||
@@ -6,7 +6,7 @@ Accepted
|
||||
|
||||
## Context
|
||||
|
||||
alknet-vault uses irpc for its internal dispatch. The `VaultProtocol` enum is
|
||||
alkvault uses irpc for its internal dispatch. The `VaultProtocol` enum is
|
||||
annotated with `#[rpc_requests(message = VaultMessage, no_spans)]`, which
|
||||
generates a `Service` trait impl (for in-process mpsc dispatch) and a
|
||||
`RemoteService` trait impl (for remote QUIC dispatch). The vault's
|
||||
@@ -103,7 +103,7 @@ which exists only to make `RemoteService` work, which is the footgun.
|
||||
|
||||
## Decision
|
||||
|
||||
### 1. alknet-vault drops irpc entirely
|
||||
### 1. alkvault drops irpc entirely
|
||||
|
||||
The vault's dispatch is direct method calls on `VaultServiceHandle`. No
|
||||
`VaultProtocol` enum, no `VaultMessage`, no `VaultServiceActor`, no mpsc
|
||||
@@ -121,7 +121,7 @@ The vault crate has no remote dispatch capability. There is no
|
||||
`RemoteService` trait, no remote handler, no wire format for vault messages.
|
||||
Enabling remote vault access is not a flag flip or a server-setup change —
|
||||
it requires *building a separate crate* that depends on both alknet-core
|
||||
(for auth) and alknet-vault (for the handle) and adds the remote transport
|
||||
(for auth) and alkvault (for the handle) and adds the remote transport
|
||||
+ auth-wrapping handler. That is a visible architectural act that shows up
|
||||
in code review, not a runtime config flip on a macro that was already
|
||||
generating the remote code.
|
||||
@@ -152,7 +152,7 @@ defines the wire representation.
|
||||
The vault-server-crate question (review #002 C7) is decided: *if* remote
|
||||
vault access is ever needed, it is a separate crate that depends on both
|
||||
alknet-core (for `IdentityProvider`, scopes, auth-wrapping) and
|
||||
alknet-vault (for `VaultServiceHandle`). The vault crate itself remains
|
||||
alkvault (for `VaultServiceHandle`). The vault crate itself remains
|
||||
local-only. This is a decision not to create the crate now, and not to
|
||||
preclude it. It is the path of least commitment, and it matches ADR-018's
|
||||
standalone-vault principle.
|
||||
@@ -311,26 +311,35 @@ version of ADR-018's intent.
|
||||
|
||||
## References
|
||||
|
||||
- ADR-005: irpc as call protocol foundation (this ADR amends the vault
|
||||
reference in ADR-005's Decision and Consequences; ~~irpc remains the
|
||||
foundation for alknet-*call*, just not for alknet-*vault*~~ — **this
|
||||
claim is itself superseded by [ADR-064](064-irpc-never-integrated-hand-rolled-framing.md)**,
|
||||
which records that irpc was never integrated into alknet-call either;
|
||||
neither the vault nor the call protocol uses irpc)
|
||||
- ADR-008: Vault integration point (the vault is a capability source
|
||||
accessed at assembly time — this ADR makes that the *only* mode)
|
||||
- ADR-014: Secret material flow and capability injection (`DerivedKey`
|
||||
never appears in call protocol payloads — the redacting `Serialize`
|
||||
is defense-in-depth for logging, not for wire transport)
|
||||
- ADR-018: Vault as standalone crate (this ADR strengthens the
|
||||
standalone principle: zero alknet crate dependencies *and* zero RPC
|
||||
framework dependencies)
|
||||
- ADR-019: Vault assembly-layer-only access (this ADR makes the vault
|
||||
local-only, not just assembly-layer-only-for-direct-calls)
|
||||
- OQ-21: Remote vault administration (resolved by this ADR — not a vault
|
||||
crate feature; if needed, a separate crate with its own ADR)
|
||||
- docs/reviews/002-pre-implementation-architecture-sanity-check.md
|
||||
- `@alkdev/alknet: ADR-005` — irpc as call protocol foundation (this ADR
|
||||
amends the vault reference in ADR-005's Decision and Consequences;
|
||||
~~irpc remains the foundation for alknet-*call*, just not for
|
||||
alkvault~~ — **this claim is itself superseded by
|
||||
`@alkdev/alknet: ADR-064`**, which records that irpc was never
|
||||
integrated into alknet-call either; neither the vault nor the call
|
||||
protocol uses irpc)
|
||||
- `@alkdev/alknet: ADR-008` — vault integration point (the vault is a
|
||||
capability source accessed at assembly time — this ADR makes that the
|
||||
*only* mode)
|
||||
- `@alkdev/alknet: ADR-014` — secret material flow and capability injection
|
||||
(`DerivedKey` never appears in call protocol payloads — the redacting
|
||||
`Serialize` is defense-in-depth for logging, not for wire transport)
|
||||
- [ADR-018](018-vault-standalone-crate.md) — vault as standalone crate
|
||||
(this ADR strengthens the standalone principle: zero alknet crate
|
||||
dependencies *and* zero RPC framework dependencies)
|
||||
- [ADR-019](019-vault-assembly-layer-only.md) — vault assembly-layer-only
|
||||
access (this ADR makes the vault local-only, not just
|
||||
assembly-layer-only-for-direct-calls)
|
||||
- [OQ-21](../questions/021-remote-vault-administration.md) — remote vault
|
||||
administration (resolved by this ADR — not a vault crate feature; if
|
||||
needed, a separate crate with its own ADR)
|
||||
- `@alkdev/alknet: docs/reviews/002-pre-implementation-architecture-sanity-check.md`
|
||||
(findings C7, C8, W8 — resolved or dissolved by this ADR)
|
||||
- irpc design patterns: `docs/research/references/iroh/irpc/09-design-patterns-and-examples.md`
|
||||
- `@alkdev/alknet: docs/research/references/iroh/irpc/09-design-patterns-and-examples.md`
|
||||
(Pattern 3: `no_rpc` flag — this ADR goes further by dropping irpc
|
||||
entirely, since the actor pattern is also unnecessary)
|
||||
entirely, since the actor pattern is also unnecessary)
|
||||
|
||||
> Cross-repo references (`@alkdev/alknet: ...`) point to the parent
|
||||
> `@alkdev/alknet` workspace where this crate originated. The artifacts
|
||||
> are preserved there as historical context; they are not part of this
|
||||
> standalone repo.
|
||||
@@ -165,15 +165,16 @@ and the v1→v2 migration from PBKDF2.
|
||||
|
||||
## References
|
||||
|
||||
- ADR-020: HD derivation for encryption keys (a special case of this ADR —
|
||||
covers the encryption key at `m/74'/2'/0'/0'` and the v1→v2 migration
|
||||
from PBKDF2)
|
||||
- ADR-010: ALPN router and endpoint (Ed25519 as the default curve for TLS
|
||||
raw key identity — the identity key at `m/74'/0'/0'/0'`)
|
||||
- ADR-018: Vault as standalone crate (the vault defines its own key types
|
||||
and derivation paths)
|
||||
- ADR-025: Vault local-only dispatch (the vault is local-only; the seed
|
||||
never crosses the network)
|
||||
- [ADR-020](020-hd-derivation-for-encryption-keys.md) — HD derivation for
|
||||
encryption keys (a special case of this ADR — covers the encryption key
|
||||
at `m/74'/2'/0'/0'` and the v1→v2 migration from PBKDF2)
|
||||
- `@alkdev/alknet: ADR-010` — ALPN router and endpoint (Ed25519 as the
|
||||
default curve for TLS raw key identity — the identity key at
|
||||
`m/74'/0'/0'/0'`)
|
||||
- [ADR-018](018-vault-standalone-crate.md) — vault as standalone crate
|
||||
(the vault defines its own key types and derivation paths)
|
||||
- [ADR-025](025-vault-local-only-dispatch.md) — vault local-only dispatch
|
||||
(the vault is local-only; the seed never crosses the network)
|
||||
- [mnemonic-derivation.md](../mnemonic-derivation.md) —
|
||||
BIP39, SLIP-0010, BIP-0032, derivation paths, PATHS module
|
||||
- [encryption.md](../encryption.md) — AES-256-GCM,
|
||||
@@ -182,4 +183,9 @@ and the v1→v2 migration from PBKDF2.
|
||||
- SLIP-0044: Registered coin types for BIP-0032 / SLIP-0010 (`74'` is
|
||||
unallocated)
|
||||
- BIP-0032: Hierarchical deterministic wallets (secp256k1)
|
||||
- BIP-39: Mnemonic code for generating deterministic keys
|
||||
- BIP-39: Mnemonic code for generating deterministic keys
|
||||
|
||||
> Cross-repo references (`@alkdev/alknet: ...`) point to the parent
|
||||
> `@alkdev/alknet` workspace where this crate originated. The artifacts
|
||||
> are preserved there as historical context; they are not part of this
|
||||
> standalone repo.
|
||||
Reference in new issue
Block a user