glm-5.2
fd83fc1685
Three simplifications to the channels spec, all flowing from the review: 1. Substrate simplification (ADR-071 revised): the 9-byte chunk header is used in ALL substrates — in-line (TCP+TLS, WebTransport), native (QUIC bidi streams), and multi-connection. The ChannelsAdapter reads headers off every bidi stream it accepts; the transport's native multiplexing is a performance optimization (independent flow-control windows), not a protocol change. One wire format, one code path, one handler experience. The channel_id in the header is the correlation key across substrates. 2. Stream_type decomposition (ADR-071 revised): every stream_type is unidirectional. Bidirectionality is two stream_types (write + read), not one 'bidirectional' stream_type. Grouped in threes: 0/1/2 = data write/read/err, 3/4/5 = control write/read/err, % 3 formula. This resolves the TTY control channel's 'not actually bidirectional' flaw — control is now 3 (write, client→server) + 4 (read, server→client), each with its own reassembly buffer and EOF. Channel 0 uses [0,1] (call frames bidirectional via 0=in, 1=out). TTY uses [0,1,2,3,4]. ADR-072, 073, 074, 077 updated for the new stream_type assignments. 3. Sub-crate decomposition (ADR-081 new): channels-core (pure multiplexer — wire format, demux/mux, ChannelBidiStreamSource, ChannelManager; depends on alknet-core only, no call dependency, ALPN-blind) / channels-call (channel 0 pre-negotiation + lifecycle op registrations; depends on channels-core + alknet-call) / channels-hub (relay) / channels-worker (ChannelClient). Isolates the call-protocol coupling from the pure multiplexer so the dependency graph is honest. ADR-077 (TTY inside channels) updated: TTY now uses 5 sub-streams [0,1,2,3,4] with control properly bidirectional via 3/4; amends ADR-052's stream_type assignments for direct mode too (direct alknet/tty now uses 0-4, not 0-3). Spec docs updated: channels-wire, channels-connection, channels-adapter, channel-operations, overview, README.
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.