Dependency Candidates

External dependencies mentioned while the server evolved but not yet approved. This page records candidates and open questions; it is not a selection decision. Per AGENTS.md, adding a crate requires human agreement first.

CandidateServesStatusOpen question
nanoidShort IDs for Invite CodesNot adopted; invite codes themselves are unimplementedIs a short ID worth one more dependency, given its collision odds
tower-governor + governorRate limiting (GCRA)A hand-rolled fixed window + login-failure lock already covers the featureWould GCRA's smoothness justify replacing the current implementation
qdrantPersonal memory / RAGNot adopted; rig-core already supports several vector backendsSelf-hosted or embedded, and who carries the operational cost
wasmtimePlugin systemNot adoptedWASI P2 ABI stability and per-plugin runtime cost
rumqttcMQTT gateway / device-to-device callsNot adopted; WebSocket is the only transport todayAdd MQTT as a second transport, or stay WebSocket-only
rodioMusic playbackNot adoptedPlayback on the server or the device, and how server playback coexists with TTS output
tokio-cron-schedulerTimer / reminder / alarmNot adoptedIs in-memory single-node scheduling enough, and must jobs survive a restart
csm.rs (AGPL-3.0)Conversational prosody TTSNot adoptedAGPL compatibility with this project's licence is unassessed
voirs-emotionEmotion-adaptive toneNot adopted; sherpa-onnx already ships SER modelsIt overlaps the existing SER work; is only a mapping layer missing
webrtc-rsWebRTC real-time audio/videoNot adoptedAdd it as a third transport, and who deploys ICE/TURN
aec3Server-side echo cancellationNot adopted; AEC currently runs on the deviceWith AEC already on the device, what does a second pass buy
polyvoiceSpeaker diarizationNot adopted; sherpa-onnx has speaker capabilities tooIt overlaps; maybe only the model list needs extending
web_socket_channelFlutter App WebSocketNot adopted; App-side WS is not wired in yetHas the Flutter transport choice been made

These are not new dependencies, only capability extensions of ones already present, so they need no approval here:

Existing dependencyCapabilities it can extend to
sherpa-onnxPiper/VITS models (multilingual TTS), ECAPA-TDNN/WeSpeaker (voiceprint), speaker embeddings (voice cloning), SER (emotion)
rig-coreVector-store backends (RAG / memory), Agent/Chain/Router (orchestration)
rmcpTool market, per-agent tool filtering, remote MCP

Layered turn detection and VAD tuning mentioned LiveKit v1-mini and OpenAI's configuration pattern; those are model/configuration references rather than crates, and whether they become Layer 2/3 is still open. See Roadmap Session / Listener.