astrid_uplink/lib.rs
1//! Shared uplink client library.
2//!
3//! The Astrid kernel exposes a Unix-domain socket protected by a
4//! 256-bit token at `~/.astrid/run/system.token`. Anything with
5//! filesystem-level read access to that token can authenticate to the
6//! daemon and publish/subscribe IPC messages. Today there are two
7//! uplinks:
8//!
9//! * **CLI** (`astrid` binary) — long-lived interactive operator
10//! sessions plus short-lived admin verbs.
11//! * **HTTP gateway** (`astrid-gateway`) — fronts the same admin IPC
12//! surface for browser dashboards behind ed25519-signed bearer
13//! tokens; resolves the HTTP principal and stamps it on every
14//! outbound message.
15//!
16//! Both consumers share the framing, handshake, and admin
17//! request/response correlation logic that lives in this crate.
18//! `SocketClient` is the transport (length-prefixed JSON, handshake,
19//! frame readers). `AdminClient` wraps it with the
20//! `astrid.v1.admin.<suffix>` → `astrid.v1.admin.response.<suffix>`
21//! request/response pattern.
22//!
23//! Trust shape: every consumer passes the caller `PrincipalId`
24//! explicitly. There is no global "active agent" lookup in this crate
25//! — the CLI resolves its operator context, the gateway resolves the
26//! verified bearer principal, and both stamp `IpcMessage.principal`
27//! before calling [`SocketClient::send_message`].
28
29pub mod admin_client;
30pub mod kernel_client;
31pub mod socket_client;
32
33pub use admin_client::{AdminClient, into_result, request_topic, response_topic, topic_suffix};
34pub use kernel_client::KernelClient;
35pub use socket_client::{SocketClient, proxy_socket_path, readiness_path, token_path};