Remote-Daemon (HTTP/WebSocket und Relay-RPC)

Memories kann dasselbe in Frames verpackte service::Request-Protokoll über folgende Transportwege bereitstellen:

1. Lokales IPC (Standard; durch Betriebssystembenutzer authentifiziert; Frames mit Längenpräfix)
2. HTTP + WebSocket (optionaler Listener; Tokenauthentifizierung; dieselben binären JSON-Frames wie Relay-RPC)
3. WSS-Relay-RPC (/v1/rpc/{room}/{slot})

Direkte und über Relay hergestellte Remote-Verbindungen verwenden dasselbe Übertragungsschema: binäre WebSocket-Frames mit AuthFrame, gefolgt von Version-1-Wire (service::Request). Tresorsynchronisierung verwendet weiterhin /v1/channel. Die WebUI zeigt weiterhin ausschließlich Status an.

Sicherheitsregeln

• Listener-Token: --listen-token / MEMORIES_LISTEN_TOKEN, oder beim Aktivieren eines HTTP-/Relay-Hosts erzeugt und einmal ausgegeben. Speichern Sie das Token niemals in TOML.
• Das Token wird beim Sperren des Speichers gelöscht.
• Remote-Aufrufer verwenden stabile Rechteerhöhungsnamensräume ws:remote / relay:remote (getrennt von cli:{pid}). Entsperren und sudo über einen Remote-Transport erhöhen die Rechte dieses Namensraums, sodass nachfolgende einmalige Verbindungen die Rechteerhöhung während des Inaktivitätsfensters behalten (dieselben Regeln wie lokal: 5 Minuten inaktiv / höchstens 15 Minuten).
• Desktop-HTTP-/Relay-Hosts bieten nach Entsperren/sudo den vollständigen handle_client-Funktionsumfang (Tresor, Karte, Erinnerung, Datei, Zugangsdaten, Synchronisierung, MCP-Berechtigung, Backup, Proxy-Bindung auf dem Host, Remote-Sitzungen, Run, CryptoJob usw.) mit denselben Rechteerhöhungsprüfungen wie beim lokalen IPC.
• HTTP-Listener verwenden standardmäßig Loopback; außerhalb von Loopback ist --allow-non-loopback erforderlich.
• Unverschlüsseltes HTTP/WS benötigt keine Zertifikate (Standard für direktes LAN).
• Optionales TLS: --tls-cert / --tls-key (PEM) aktivieren HTTPS/WSS auf demselben Listener. Eine https://-Listener-URL erfordert diese Optionen.
• Ein Relay außerhalb der Vertrauensgrenze muss wss:// mit einer Raum-ID aus 43 Zeichen und einem Token verwenden.
• Jeder Inhaber des Listener-Tokens genießt für diesen Transportnamensraum dasselbe Vertrauen wie ein lokaler Client mit erhöhten Rechten. Behandeln Sie das Token wie ein Passwort; bevorzugen Sie Loopback oder einen authentifizierten Netzwerkpfad.

Verbleibende Risiken

• Tokendiebstahl ⇒ vollständige Fernsteuerung eines entsperrten Desktop-Daemons mit erhöhten Rechten.
• HTTP außerhalb von Loopback macht die Frame-API im Netzwerk zugänglich; verwenden Sie beim Binden außerhalb von Loopback --tls-cert / --tls-key, einen Reverse-Proxy, VPN oder eine Firewall.
• Relay-RPC (/v1/rpc/{room}/{slot}) ist authentifiziert, aber nicht Ende-zu-Ende-verschlüsselt: Seine JSON-Frames auf Anwendungsebene enthalten das gemeinsame Listener-Token, gefolgt von Anfragen und Antworten. Der Relay-Betreiber oder TLS-Terminator kann Token und RPC-Nutzdaten lesen. WSS schützt jede Verbindung zum Relay, nicht vor dem Relay selbst; verwenden Sie für den Remote-Daemon-Zugriff ein vertrauenswürdiges Relay.
• Tresor-Peer-Synchronisierung (/v1/channel) ist getrennt und überträgt Ende-zu-Ende-verschlüsselte Nutzdaten. Bei diesem Kanal sehen Relay-Betreiber Geheimtextlängen und Zeitpunkte, keinen Asset-Klartext.
• Hostseitige Proxy-Listener binden weiterhin Loopback auf dem Daemon-Rechner; Remote-Clients können sie mit erhöhten Rechten starten und anschließend nur erreichen, wenn sie auch auf dessen Host-Loopback zugreifen können (typischerweise über einen separaten Tunnel).

HTTP/WebSocket-Host und -Client

# Host (prints a token once if --listen-token is omitted)
memories daemon --listen http://127.0.0.1:7900
# or HTTPS URL when TLS is configured:
memories daemon --listen https://127.0.0.1:8443 \
  --tls-cert certs/daemon-tls.crt --tls-key certs/daemon-tls.key --listen-token "$TOKEN"

# Client (another shell / machine that can reach the listener)
export MEMORIES_DAEMON=http://127.0.0.1:7900
export MEMORIES_DAEMON_TOKEN="$TOKEN"
memories status
memories unlock
memories sudo
memories vault list

Der direkte RPC-Pfad ist /v1/rpc (WebSocket-Upgrade). Optionen: --daemon, --daemon-token (dieselbe Bedeutung wie die Umgebungsvariablen).

TLS-Vertrauen des Clients

Zertifikats- und Hostnamenprüfung sind standardmäßig aktiviert. Die globale Option --ca-file PATH fügt alle Zertifikate aus einem PEM-CA-Bündel dem normalen Vertrauensspeicher hinzu. Vertrauen Sie bei einem selbstsignierten Daemon seinem Zertifikat ausdrücklich (seine alternativen DNS-/IP-Namen müssen weiterhin mit der URL übereinstimmen):

memories --daemon https://localhost:8443 --daemon-token "$TOKEN" \
  --ca-file certs/daemon-tls.crt status

# Equivalent CA setting, also usable with relay and HTTPS clients:
export MEMORIES_CA_FILE=certs/daemon-tls.crt
memories --daemon https://localhost:8443 --daemon-token "$TOKEN" status

# DANGEROUS: development only; prefer --ca-file instead.
memories --daemon https://localhost:8443 --daemon-token "$TOKEN" --insecure status

--insecure deaktiviert die Zertifikatsketten- und Hostnamenprüfung. Die TLS-Verschlüsselung bleibt aktiviert, aber ein Angreifer kann den Server imitieren und Daemon-Token, Zugangsdaten oder Anfrage-/Antwortdaten lesen. Verwenden Sie dies niemals in Produktion oder in einem nicht vertrauenswürdigen Netzwerk. Die Option ist nur für die CLI verfügbar (keine Umgebungsvariable MEMORIES_INSECURE). Eine ausdrücklich angegebene CA-Datei muss auch mit --insecure lesbar sein und gültige PEM-Zertifikate enthalten; ungültige Dateien führen vor dem Verbinden zum Fehler. Dateien werden einmal beim Start geladen; starten Sie den Prozess nach Änderungen des Bündels neu.

Beide Optionen gelten für ausgehende Verbindungen des aktuellen Prozesses: direkte Daemon-Verbindungen über HTTPS/WSS, Relay-RPC-Host/-Client, Tresorsynchronisierungs-Relay-Clients, Cloud-OAuth und Drive-HTTP, RAG-API-/Modelldownload-HTTP, mit Zugangsdaten authentifiziertes HTTPS, Automatisierungs-Webhooks und Datenbank-TLS-Sitzungen/-Proxys. Für Operationen, die ein Daemon ausführt, übergeben Sie die Optionen beim Starten dieses Daemons; Clientoptionen werden nicht über RPC gesendet und können die Upstream-TLS-Richtlinie des Daemons nicht ändern:

memories --ca-file /path/internal-ca.pem daemon
# Development only: affects every outbound TLS connection in this daemon.
memories --insecure daemon

Serveroptionen --tls-cert / --tls-key und die Authentifizierung mit gemeinsamem Token bleiben unverändert. Datenbankoption --tls-ca CA_ID löst weiterhin PEM-Zugangsdaten im Tresor auf; deren Vertrauen wird mit dem --ca-file-Bündel des Daemons kombiniert. Keine der Optionen deaktiviert TLS oder die feste Bindung von SSH-Hostschlüsseln. Diese Optionen sind keine TOML-Einstellungen, werden nicht als Tresorgeheimnisse gespeichert und konfigurieren weder Mobile-/FFI-Aufrufer noch TLS-Clients in externen Programmen/Browsern oder durch Abhängigkeiten verwaltete Downloads außerhalb dieser HTTP-Builder.

Relay-RPC-Host und -Client

# Generate a room id (43 URL-safe characters)
memories sync room

# Host joins slot a
memories daemon \
  --relay-host wss://relay.example.com \
  --room "$ROOM" \
  --listen-token "$TOKEN"

# Client joins slot b
export MEMORIES_DAEMON_RELAY=wss://relay.example.com
export MEMORIES_DAEMON_ROOM="$ROOM"
export MEMORIES_DAEMON_TOKEN="$TOKEN"
memories status

Lokale Entwicklung kann ws://127.0.0.1:8787 mit memories-relay verwenden.

Für ein Relay mit privater CA können Host und Client die globalen Optionen verwenden:

memories --ca-file /path/relay-ca.pem daemon \
  --relay-host wss://relay.example.com --room "$ROOM" --listen-token "$TOKEN"
memories --ca-file /path/relay-ca.pem --daemon-relay wss://relay.example.com \
  --daemon-room "$ROOM" --daemon-token "$TOKEN" status

Mobile Freigabe (Host im Vordergrund)

Die Flutter-App kann eine Freigabesitzung starten, die Relay-RPC als Host (Slot a) beitritt, während sie entsperrt und im Vordergrund ist. Wechsel in den Hintergrund oder Sperren beendet die Sitzung. Mobil bleibt die FFI-Sperrliste erhalten (kein Run/CryptoJob/MCP-Berechtigungen/Remote-Sitzungen/Proxys; außerdem verweigert die Freigabe das Kopieren von Zugangsdatenklartext und Backup-Dumps). Telefone öffnen keinen HTTP-Listener. Siehe mobile/README.md.

Nur lokal / Plattformausnahmen

Persona-Automatisierungs-Webhook

Bei aktiviertem HTTP-Listener werden eingehende Automatisierungsauslöser hier akzeptiert:

POST /v1/persona/{vault}/{persona}/automation/trigger
Authorization: Bearer <persona world.automation.webhook_token>
Content-Type: application/json

{"hook":"HOOK_ID"}

Der Daemon muss entsperrt sein (wie bei anderen Schreib-RPCs). Das Listener-Token aktiviert die HTTP-Schnittstelle; das Automatisierungs-webhook_token (gesetzt über persona automation put --webhook-token) autorisiert den Hook. Ein Relay-Host erhält denselben Aufruf unter POST /v1/persona/{room}/{vault}/{persona}/automation/trigger auf dem Relay (derselbe Inhalt und Webhook-Bearer); das Raumsegment ist der einzige Pfadunterschied, und das Relay leitet einen bestehenden persona_automation_trigger-Übertragungsframe an den verbundenen Host weiter, statt ihn lokal zu bedienen oder ausgehend zu senden. Entsprechender CLI-Aufruf:

memories persona automation trigger VAULT PERSONA --id HOOK_ID \
  --source webhook --token "$WEBHOOK_TOKEN"