glm-5.2
b5397f61aa
The previous draft was mixing two layers (transport leaf and stream_type multiplexing) and including side-topics (WsBidiStream home, etc.) that weren't load-bearing, which confused agents into conflating tokio::io:: join/split (ADR-092's layer, settled) with the demux/mux stream_type layer (this doc's layer, in progress). Rewrite to be focused: - Layering section upfront separates transport leaf (ADR-092, settled), multiplexing (this doc), and channel protocol (ADR-072/073, settled). The two questions that got conflated are explicitly separated. - Drop the ADR-092 recap (it's in the ADR, not this doc's concern). - Drop the 'five abstractions' table (ADR-092's framing, not this doc's). - Drop the WS open question (irrelevant to multiplexing). - Record that POC 1 (stderr split/recombine) is already answered by the existing POC evidence: per-stream_type independent demux/mux (verified in demux.rs:91-109, 161-181 and mux.rs:58-63, 152-177) means the 'unused write half' is an idle mpsc channel, not a wart. The mod-2 framing is trivially clean. No new POC needed. - The mod-2-vs-mod-3 question is settled by existing evidence; ADR-093 is ready to draft. - The one open question that benefits from a POC is POC 2 (TTY-direct-as-channels, for the format-convergence / retire-5-byte call). POC 3 (recursive composition) is low leverage, deferred. - The TTY control channel flaw is flagged as implementation-lag, not a design question (fix specified in ADR-077, subsumed by mod-4 instance framing). This drops the scope to what the doc is actually about: the stream_type convention and the TTY/channels convergence.
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.