glm-5.2
19d010cf73
Synthesizes the multi-thread discussion that surfaced during the peer-graph routing research (ADR-029) and OQ-33/34 resolution. Three separate threads (peer identity, filesystem POC, old storage spec) converged on the same question: where does persistent state live in the alknet crate graph, and what's the shared infrastructure for it. Key commitments documented: - SQLite + honker is the foundation (pattern, not a crate — ~20 lines per consumer). The metagraph is one tool built on it, for graph-shaped problems. Direct tables are another tool, for table-shaped problems. - IdentityProvider is the auth repo trait (already exists in core, make the pattern explicit). Adapters implement it (Config, SQLite, future Redis/remote/automerge). PeerStore is adapter-internal, not core. - Per-node ACL, no 'trusted' flag. Each node authorizes its direct callers via AccessControl::check(identity). No global ACL, no replication. The hub authorizes the user; the spoke authorizes the hub. Same mechanism. - Forwarded-for identity as metadata, not authority. The from_call handler includes the original caller's identity in the call payload; the spoke's ACL authorizes the hub (direct caller), never the forwarded_for. The ACL check signature prevents misuse. - The ACL check stays table-shaped (flat scope match); the delegation graph (future) produces effective scopes at resolution time. They compose at the IdentityProvider boundary. - The hub proxy tangle: ACL (authorize), bucket routing (operation input), peer routing (PeerRef) are three separate layers. Bucket-level authorization is handler logic, not protocol logic. What the old spec had that's dropped: multi-tenant (each tenant gets own setup), secrets module (replaced by vault), metagraph-as-foundation (demoted to tool), single storage crate (split by concern), accounts/orgs (deferred — v1 is a peers table). Reference: kepal (/workspace/keypal) — TypeScript repo-pattern example (Storage interface + adapters) that alknet's IdentityProvider follows.
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.