The #2 gap in alknet-call: discovers the remote peer's External operations via services/list + services/schema and registers them in the connection's Layer 2 overlay as FromCall-provenance leaves with forwarding handlers. The discovery mechanism was already implemented in registry/discovery.rs; from_call is the client-side consumer of that API. src/client/from_call.rs: - from_call(connection, FromCallConfig) -> Result<Vec<HandlerRegistration>, AdapterError>. Calls services/list then services/schema for each op, rebuilds OperationSpec from the schema JSON (parsing op_type, visibility, error_schemas, access_control), constructs a forwarding handler that calls the remote op via CallConnection::call(), and returns FromCall-provenance bundles (composition_authority: None, scoped_env: None, empty capabilities, remote_safe: false per ADR-028 §4). - FromCallConfig { namespace_prefix: Option<String>, operation_filter: Option<HashSet<String>> } with builder methods. - v1 defaults (two-way doors recorded in client-and-adapters.md): - error-on-collision (DC-3/OQ-28): applying the (possibly empty) prefix produces a name already seen -> AdapterError::Conflict, not silent overwrite. - auto-on-reconnect (DC-2/OQ-27): the overlay is per-connection (Layer 2, ADR-024), so re-import on reconnect is naturally scoped; the assembly layer calls from_call immediately after connect(). - Forwarding handler captures an Arc<CallConnection> and, on invocation, calls the remote op and returns its ResponseEnvelope. The parent_request_id participates in the cross-node abort cascade (ADR-016 §6) — if the parent is aborted, the cascade reaches this handler which sends call.aborted to the remote node; cross-node abort is transparent. - Trust is transitive (recorded in spec): a from_call-imported op executes the remote node's code; scoped_env bounds which ops are reachable, not what they do. OperationContext.internal is now pub (was pub(crate)) so downstream consumers (assembly layer, integration tests) can construct contexts for overlay-env dispatch. Tests (207 lib + 2 integration): - Unit: rebuild_spec name/prefix/op_type/visibility/error_schemas/acl; unknown op_type -> SchemaParse; missing op_type -> SchemaParse; FromCallConfig builder; from_call against a mock connection returns DiscoveryFailed (no transport); FromCall provenance + leaf fields + remote_safe false. - Integration (tests/two_node_call.rs): from_call over a real QUIC loopback — CallClient connects, from_call discovers server/echo, registers the bundle in the overlay, and the forwarding handler round-trips an input through the overlay env to the remote op and back. clippy + fmt + test all green. Refs: tasks/call/client/from-call.md Refs: docs/architecture/decisions/017-call-protocol-client-and-adapter-contract.md §3, §6 Refs: docs/architecture/crates/call/client-and-adapters.md §from_call
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.