glm-5.2
7dda6eec68
Drops irpc from alknet-vault entirely. The vault's dispatch is now direct method calls on VaultServiceHandle — no VaultProtocol enum, no VaultMessage, no VaultServiceActor, no mpsc channel, no Service trait, no RemoteService trait, no postcard serialization. The vault is local-only by construction. The core security argument: irpc made the vault remote-capable by default (RemoteService generated unless no_rpc is passed). The IrohProtocol handler forwards all messages without auth. The docs framed 'register an ALPN' as a server-setup change. This is the default-insecure anti-pattern — security should be opt-in, not opt-out. ADR-025 inverts the default: local-only is the only mode, and remote access requires building a separate vault-server crate (a visible architectural act, not a flag flip). The actor path was already dead code — service.md said 'prefer VaultServiceHandle directly — no channel, no serialization.' The actor existed only to make irpc's Service trait work, which existed only to make RemoteService work, which was the footgun. VaultServiceHandle's Arc<RwLock> provides concurrent reads and exclusive writes — better throughput than the actor's sequential processing. DerivedKey serialization simplifies: always redact on serialize (for logging safety), reject '[REDACTED]' on deserialize with an error. No 'postcard preserves bytes' path. This resolves review #002 W8 (silent corruption on JSON-deserialized DerivedKey). Resolves: - OQ-21: remote vault access — resolved (not deferred). Not a vault crate feature; if needed, a separate vault-server crate with its own ADR. - C7: vault-server-crate question decided — not created now, not precluded. - C8: operation access policy table dissolved — all operations local-only by default; if a vault-server crate exposes some remotely, that crate defines the policy. - W8: DerivedKey JSON deserialization — resolved (reject redacted payloads). Amends ADR-005 (irpc remains for alknet-call, not for alknet-vault), ADR-018 (vault is even more standalone — zero RPC framework deps), ADR-019 (vault is the only layer, not just the only direct-caller layer), ADR-008 (vault integration point unchanged, but now local-only by construction).
Alknet
Status: Pre-alpha — This project is undergoing a major architectural pivot to an ALPN-as-service model. The previous implementation has been archived and a greenfield rebuild is in progress.
A self-hostable networking toolkit built on QUIC+TLS with ALPN-based protocol dispatch. Each protocol handler (SSH, SFTP, Git, HTTP, DNS, messaging, call protocol) registers an ALPN string on a shared endpoint. The ALPN negotiation during the TLS/QUIC handshake routes connections to the correct handler before any application bytes are read.
Core Insight
A service IS an ALPN. One endpoint, one port, many protocols — dispatched by the TLS handshake, not by application-level peeking or separate listeners.
Crates
| Crate | Status | Description |
|---|---|---|
alknet-vault |
stable | Local key vault: BIP39/SLIP-0010/AES-GCM key derivation and encryption |
alknet-core |
planned | ProtocolHandler trait, ALPN router, auth/identity, config |
alknet-ssh |
planned | SSH handler (russh), SOCKS5, port forwarding |
alknet-call |
planned | JSON-RPC call protocol (EventEnvelope framing) |
alknet-fs |
planned | Content-addressed file storage (iroh-blobs backend) |
alknet-sftp |
planned | SFTP handler (russh-sftp protocol core) |
alknet-git |
planned | Git smart protocol handler (gix) |
alknet-http |
planned | HTTP handler (axum, REST API, MCP) |
alknet-dns |
planned | DNS handler (hickory-proto, pkarr) |
alknet-msg |
planned | E2E encrypted messaging, mixnet support |
alknet |
planned | CLI binary (assembles and registers handlers) |
Documentation
- ALPN-as-service architecture — pivot proposal
- Cleanup plan — greenfield transition plan
- SDD process — spec-driven development process
- Research references — iroh, russh, russh-sftp deep dives
Reference implementation (previous architecture) is preserved at /workspace/@alkdev/alknet-main/.
License
Licensed under either of
- Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.