Superlink manual

What it is / interactive architecture

Superlink: Native communication platform for chat, calls, files, screens, and remote nodes

Superlink is a channel-centered Windows communication system combining messaging, voice and video calls, file transfer, screen sharing, remote control, relays, and headless node access. This diagram follows a channel from the local clients and daemon through discovery, encrypted peer sessions, reliable UDP transport, media, transfers, and current prototype evidence.

Open complete manual
Native communication platform for chat, calls, files, screens, and remote nodesREV 03
100%
SHAPE KEY
Native communication platform for chat, calls, files, screens, and remote nodesSuperlink is a channel-centered Windows communication system combining messaging, voice and video calls, file transfer, screen sharing, remote control, relays, and headless node access. This diagram follows a channel from the local clients and daemon through discovery, encrypted peer sessions, reliable UDP transport, media, transfers, and current prototype evidence. Every station and route can be selected for more information.Subscribed channels, active selection, and optional local secrets shape each client surface.R01 / saved scopeUser actions become structured request frames through the native WebView2 bridge.R02 / bridge commandThe named-pipe server validates and routes commands into daemon-owned state.R03 / local authorityThe daemon loads device, channel, transfer, control, headless, relay, voice, and logging policy at startup and reload.R04 / policy loadChannel presence and the node fingerprint are registered to obtain observed addresses and peer introductions.R05 / introduce peersIntroduced addresses seed peer creation and channel-token handshake attempts.R06 / peer coordinatesThe selected auto-join channel token authenticates nonce proofs and directional key derivation.R07 / channel tokenEstablished directional keys encrypt and authenticate transport payloads while headers remain associated data.R08 / protected packetReliable and realtime work enters prioritized queues under pacing and congestion limits.R09 / queued datagramsScheduled packets use direct peer addresses or the configured forwarding path.R10 / direct or relayCall toggles, camera state, share announcements, subscriptions, and keyframe requests control media activity.R11 / call + share intentVoice, camera, screen, and cursor payloads enter loss-tolerant or control lanes according to latency needs.R12 / realtime framesReceived frames are decoded, buffered, mixed, rendered, or displayed for the selected channel.R13 / peer playbackIPC and peer transfer commands create bounded send or receive state and file handles.R14 / file offerAligned file chunks move through the lowest-priority reliable lane and retain resume state.R15 / bulk chunksScreens UI requests view, control, release, cursor, and clipboard state through the daemon.R16 / control requestAn interactive-session helper performs screen or camera capture when service-session isolation requires it.R17 / session captureSession operations return structured results and audit events to daemon-owned state.R18 / input + clipboard resultA two-second listener and dialer exchange proves the transport demo receives messages on loopback.R19 / localhost soakOne-shot daemon startup and a temporary named-pipe CLI ping prove a narrow executable path.R20 / startup + IPC smokeSaved subscriptions, auto-join tokens, node fingerprint material, rendezvous targets, transfer roots, allowlists, and headless capability switches define local participation and consent.INN0101 / INPUTCHANNELS +DEVICE POLICYIN 00InputOUT 02Three local WebView2 clients expose channel chat and transfers, calls and cameras, and screenshare or control state through one framework-free interaction model.OUTN0202 / SURFACESCHAT + CALL +SCREENS WINDOWSWin32 WebView2 hostIN 01OutputOUT 03Versioned request, response, and pushed-event frames connect the UI and CLI to the daemon through a configurable local Windows named pipe.APIN0303 / LOCAL BOUNDARYNAMED PIPELEN + JSONIN 01BoundaryOUT 01The always-on daemon owns current configuration, channel state, peer sessions, transfers, voice, cameras, screens, control, clipboard, metrics, and event publication.FXN0404 / ORCHESTRATIONSUPERLINKDCHANNEL AUTHORITYHot-reload with restart require...IN 03ProcessOUT 04TTL-based UDP services record observed peer addresses, introduce channel members, and optionally forward addressed opaque packets when direct paths are unavailable.APIN0505 / NETWORK BOUNDARYRENDEZVOUS +RELAY SERVICESIn-memory presence mapIN 02BoundaryOUT 01Configured channel tokens authenticate exchanged nonces with HMAC-SHA256, derive directional keys through HKDF-SHA256, and protect payloads with AES-256-GCM.APIN0606 / TRUST BOUNDARYPSK HANDSHAKE+ AES-GCMIN 02BoundaryOUT 01Versioned headers, sequence ids, selective ACK bits, retransmission, adaptive RTO, fragmentation, reassembly, and replay tracking build peer sessions above UDP.FXN0707 / TRANSPORTRELIABLE UDPSESSION COREMTU-bounded datagramsIN 01ProcessOUT 02A token bucket, congestion window, AIMD adjustment, delay guard, and ordered lane queues protect voice and control latency from screen, chat, and bulk traffic.FXN0808 / SCHEDULINGPACER +PRIORITY LANESvoice > control > camera > scre...IN 03ProcessOUT 02Windows capture, Opus or PCM voice, jitter buffering, mixing, Media Foundation cameras, JPEG screens, keyframes, and cursor events feed the realtime lanes.FXN0909 / MEDIAVOICE + CAMERA+ SCREEN MEDIAIN 03ProcessOUT 01Bulk-lane offers and chunks update bounded inbox and outbox files with pause, resume, cancellation, chunk maps, root restrictions, and quota checks.DBN1010 / STATERESUMABLE FILEINBOX + OUTBOXAuto-accept defaults offIN 01State storeOUT 01The service and scheduled agent delegate capture, input, camera, and clipboard work to an interactive-session helper after explicit headless and peer policy checks.APIN1111 / PRIVILEGED BOUNDARYSESSION HELPER+ REMOTE CONTROLIN 01BoundaryOUT 02Fresh configuration attempts, one successful constrained Windows build, three CTest smoke lanes, and the open packaging roadmap define the current evidence boundary.QAN1212 / EVIDENCEBUILD + SMOKERELEASE GATES3/3 smoke tests passIN 02EvidenceOUT 00DHL-VISUAL-PROGRAM / SUPERLINK / REV 04VARIABLE NODES / DISTRIBUTED PORTS / INSPECTABLE CONTRACTS