Architektur und Protokoll v1

Speicherung

Das Datenbankschema besteht aus header, state und checkpoints. Abgesehen von Formatmetadaten, Salt und Zeilenfolgenummern sind die Werte authentifizierter Chiffretext. Auch Journale enthalten Chiffretext. Es gibt keinen dauerhaften FTS-Index im Klartext. Autorisierte gewöhnliche Erinnerungen werden in überlappende, Unicode-sichere Abschnitte aufgeteilt und mit Jieba tokenisiert, bevor sie in einen SQLite-FTS5-Index im Arbeitsspeicher gelangen. Der Cache wird anhand der Richtlinie, Revision und des Quarantänestatus des Tresors identifiziert und zwischen Abfragen wiederverwendet; Bearbeitungen, Synchronisierung und Richtlinienänderungen machen ihn ungültig, und das Sperren leert ihn. Temporäre SQLite-Daten werden bewusst nur im Arbeitsspeicher gehalten. Vektoren werden normalisiert und ausschließlich im Arbeitsspeicher zwischengespeichert; weder Klartextindizes noch Embeddings gelangen in Sicherungs- oder Synchronisierungsdaten.

Der aus dem Passwort abgeleitete Schlüssel umhüllt einen zufälligen Hauptschlüssel; dieser verschlüsselt den Zustand und lokale Checkpoints. Jede Berechtigungsepoche hat einen Tresorschlüssel, und jede Revision hat einen zufälligen Datenschlüssel, der unter ihrem Epochenschlüssel umhüllt wird. Inhalte werden serialisiert und in einzeln authentifizierte Abschnitte von 256 KiB aufgeteilt, deren Position und Gesamtzahl in die zugehörigen Daten eingebunden sind. Die Revisionssignatur umfasst die Asset-ID, Vorgänger, den Richtlinienkopf, die Tombstone-Markierung, den Chiffretext und das Gerätezertifikat.

Änderungen werden auf einem geklonten Zustand vorbereitet und zusammen mit dem verschlüsselten Zustand und Checkpoint in einer SQLite-Transaktion mit synchronous=FULL festgeschrieben. Lese- und Ausführungsabsichten werden vor der Auslieferung festgeschrieben. Ein Datenträgerfehler verhindert daher die Auslieferung; ein Absturz nach dem Festschreiben der Absicht kann ein unbekanntes Ergebnis hinterlassen.

Eine exklusive Betriebssystemsperre erlaubt einen kooperierenden lokalen Schreiber. Die Initialisierung erstellt eine vollständige Datenbank im selben Verzeichnis, schließt und synchronisiert sie und veröffentlicht sie anschließend, ohne ein vorhandenes Ziel zu überschreiben. Eine unterbrochene Vorbereitung verhindert keinen erneuten Versuch. Jedes Gerät benötigt seinen eigenen lokalen Speicher; das Kopieren laufender SQLite-Dateien über einen Cloud-Synchronisierungsclient bietet keine geräteübergreifende Transaktionssicherheit.

Identitäten und Transport

Ed25519-Benutzerschlüssel zertifizieren Ed25519-Signaturschlüssel und X25519-Austauschschlüssel der Geräte. Zertifikate allein reichen nicht aus: Jede Tresorrichtlinie autorisiert Geräte ausdrücklich. Geräteschlüssel sind unabhängig, auch bei Geräten desselben Benutzers. Die anfängliche Signierbefugnis des Benutzers wird genehmigten persönlichen Geräten in einem authentifizierten, für den Empfänger verschlüsselten Paket übermittelt; diese Befugnis kann die Geräte-Zulassungsliste eines Tresors nach dem Widerruf eines Geräts nicht umgehen.

Eine Hülle enthält eine Formatversion, den Geräteschlüssel des Absenders, den Austauschschlüssel des Empfängers, einen kurzlebigen öffentlichen X25519-Schlüssel, AEAD-Nutzdaten und eine Ed25519-Signatur. HKDF leitet den Transportschlüssel ab. Empfängeridentität und kurzlebiger Schlüssel werden authentifiziert. Das beitretende Gerät verwendet eine ablaufende signierte Anfrage und bindet sich ausdrücklich an den öffentlichen Schlüssel des genehmigenden Geräts; Anfragen werden erst nach erfolgreichem Festschreiben verbraucht.

Die erste Veröffentlichung verwendet Anfrage-/Genehmigungszeichenfolgen und Dateien anstelle des QR-Scannens per Kamera. Fingerabdrücke sind vollständige SHA-256-Hashes; verkürzte Werte in Listen dürfen niemals als alleinige Genehmigungsprüfung dienen.

Richtlinien und Zusammenführung

Tresorrichtlinien sind signierte lineare Historien mit Mitgliedschaft, Rolle, Geräte-Zulassungsliste, monoton wachsender Menge widerrufener Geräte und Epoche. Rollenprüfungen verwenden die vorherige Richtlinie. Gewöhnliche Benutzer dürfen ein weiteres Gerät für ihre eigene Identität autorisieren, ohne die Mitgliedschaft zu ändern. Ein Admin darf die Mitgliedschaft von Admin, Editor und Reader ändern und das Gerät eines Mitglieds autorisieren. Ein Admin darf keinen Owner hinzufügen, entfernen oder ändern, keine Geräte widerrufen und kein Eigentum übertragen. Owner dürfen dies. Eine Eigentumsübertragung behält genau einen Owner bei.

Asset-Historien bilden einen inhaltsadressierten DAG, den alle bearbeitbaren Arten gemeinsam nutzen (Erinnerung, Karte — einschließlich Wissen, Brain, Persona und Metadaten geschützter Karten —, Datei und Zugangsdaten). Jedes Speichern fügt eine signierte Revision hinzu; es gibt keinen separaten Historien-Speicher nur für das Wiki und keine automatische Bereinigung. history listet Revisionen mit Autor und Zusammenfassung auf; diff liefert eine vereinheitlichte Textprojektion (Titel, strukturierte Metadaten, Textkörper) zwischen zwei Revisionen oder gegenüber dem aktuellen HEAD. Dateivergleiche lassen binäre Nutzdaten aus; geheime Inhalte von Zugangsdaten bleiben über Lesen/Vergleichen unzugänglich. Mehrere unverbrauchte Revisionen eines Assets sind Konflikte; eine Auflösungsrevision benennt alle sichtbaren Vorgänger. Ein Tombstone entfernt das Asset aus aktuellen Ansichten, ohne die Historie zu löschen.

Die Synchronisierung validiert vollständige Richtlinien-, Revisions- und Audit-Historien vor der Zusammenführung in einen Kandidatenzustand. Unbekannte Schreibvorgänge aus abgelösten Epochen werden unter Quarantäne gestellt. Lokale Offline-Schreibvorgänge, die in einem eingehenden neueren Richtliniensnapshot fehlen, werden ebenfalls unter Quarantäne gestellt. Quarantäne kann nur lokal überprüft und erneut angewendet werden; ein nicht vertrauenswürdiges eingehendes Feld kann sie nicht aufheben.

Richtlinienverzweigungen erfordern eine Owner-Signatur über den ausgewählten Kopf und die gesamte verworfene Richtlinienkette. Der Unterzeichner muss auf beiden Zweigen Owner sein. Verworfene Richtlinien bleiben für historische Revisionen und Revisionen unter Quarantäne überprüfbar. Eine erfolgreiche Auflösung führt die ausgewählte Richtlinie fort und rotiert ihren Schlüssel. Konkurrierende oder inkompatible Auflösungen werden sicher abgewiesen.

Lokale API

service::Request ist die gemeinsame typisierte Operationsschnittstelle, serialisiert mit dem Diskriminator op in Snake Case. Unbekannte Felder auf oberster Ebene werden abgewiesen. Lokales IPC verwendet JSON-Frames mit vorangestellter 32-Bit-Länge in Big Endian (Version-1-Wrapper Wire). Optionales HTTP-/WebSocket-Listening und Relay-RPC verwenden nach der Token-Authentifizierung dieselbe binäre WebSocket-JSON-Rahmung (AuthFrame, dann Wire). MCP-Fähigkeiten werden vor der Weiterleitung separat geprüft. RunBound wird wie RemoteExec weitergeleitet: run_bound_prepare autorisiert und entschlüsselt unter der Servicesperre, der IPC-Thread führt das Programm ohne Sperre aus, und run_bound_finish protokolliert das Ergebnis. Ausführungsbindungen liegen im gerätelokalen State.run_bindings, nicht in einem Tresor.

Netzwerktransporte dürfen token-authentifizierte gerahmte Requests übertragen. Tokens stammen ausschließlich aus Flags/Umgebungsvariablen (niemals TOML), werden in konstanter Zeit verglichen und beim Sperren des Speichers gelöscht. Entfernte Aufrufer verwenden stabile Namensräume für erhöhte Rechte (ws:remote / relay:remote), die keine lokale cli:{pid}-Rechteerhöhung erben; Entsperren und sudo über eine entfernte Verbindung erhöhen die Rechte dieses Namensraums, sodass einmalige CLI-Verbindungen die erhöhten Rechte behalten. Desktop-HTTP-/Relay-Hosts leiten die vollständige handle_client-Schnittstelle weiter (mit denselben Rechteprüfungen wie lokales IPC). Mobile FFI und Share behalten die plattformspezifische Sperrliste bei und führen auf dem Telefon keine ausschließlich für Desktops vorgesehenen Funktionen ein. HTTP-Listening verwendet standardmäßig Loopback; Bindungen außerhalb von Loopback erfordern --allow-non-loopback und eine Warnung. Einfaches HTTP/WS benötigt keine Zertifikate; --tls-cert / --tls-key aktivieren HTTPS/WSS. Relay-RPC verwendet außerhalb der Vertrauensgrenze WSS mit einer Raum-ID hoher Entropie plus Token; die Tresorsynchronisierung behält /v1/channel bei. Die WebUI bietet eine schreibgeschützte Statusprojektion und einen eingeschränkten Editor für gewöhnliche Karten und ist kein Request-Transport. Siehe entfernter Daemon und SECURITY.md.

Optionale Autorisierungs-Center ([[centers]] in der Konfiguration) verbieten lokales Selbst-Bootstrapping und die lokale Ausstellung von MCP-Grants; Aufnahme und Grants werden als vom Center signierte Tickets mit ausdrücklichen Geltungsbereichen verteilt (allow_all / read / write / read_write / read_write_delete). Siehe Center.

Der optionale gehostete Center-Modus (--data DIR) besitzt einen separaten verschlüsselten Store im Daemon-Format unter DIR/store/, der mit einem vom Betreiber verwahrten Serverpasswort geöffnet wird. Sein HTTP-Inhalts-RPC verwendet einen geschlossenen Grant-Dispatcher pro Tresor in Service; operationslokale Rechteerhöhung umfasst geschützte/private Inhalte und Anhänge, ohne die MCP-Autorisierung des Daemons zu ändern. Dies ist serverseitige Verschlüsselung, keine Ende-zu-Ende-Verschlüsselung auf Clientseite. Separate Admin-HTTP-Routen verwalten gehostetes Sperren/Entsperren und dauerhafte benannte Grants in DIR/members.json, das nur für den Eigentümer zugänglich ist. Signierte Entsperrtickets autorisieren ausschließlich das lokale Entsperren des Geräts per Passwort; Geräteschlüssel gelangen niemals zu einem Center, das nur Tickets verwaltet. Ein einzelner [[centers]]-Eintrag mit mode = "saas" lässt das Inhalts-RPC des Daemons dieses gehostete Backend und dessen Bearer aus der Umgebung verwenden, ohne parallelen lokalen Inhaltspfad oder Erhöhung von MCP-Fähigkeiten. Geräte-/Admin-Steuerungen gehören nicht zur Grant-Inhaltsschnittstelle. Siehe gehosteter Center-Tresor für Grenzen und Migration.

Die mobile ABI wird in crates/ffi/memories.h deklariert. Handles sind numerische Registry-IDs, keine rohen Rust-Zeiger. Jede zurückgegebene Zeichenfolge muss genau einmal mit memories_free freigegeben werden. Ungültiges JSON erzeugt einen allgemeinen Fehler, ohne die Eingabe wiederzugeben. memories_lock_all erhöht beim Wechsel in den Hintergrund eine globale Sperrgeneration und unterdrückt verspätete Antworten laufender Anfragen. Die Registry speichert referenzgezählte Servicesperren pro Handle; Netzwerkarbeit hält weder Registry- noch Schreibsperre. Ein beschäftigtes Handle wendet eine ausstehende Sperre vor seiner nächsten Anfrage an. Mobile schließt Prozessausführung und die Erstellung von MCP-Grants aus.

Die Flutter-Modusauswahl (mobile/lib/app_mode.dart) leitet Standalone an die lokale Bibliothek und Center/SaaS an HostedCenterPage weiter. Hier bedeutet Center einen selbst gehosteten Server mit gehosteter Speicherung; SaaS wählt den festen Endpunkt https://memories.ivjn.us. Beide verwenden dieselben Rust-FFI-Operationen hosted_* und HostedClient; die Auswahl verändert weder das Daemon-TOML, noch nimmt sie ein ticketverwaltetes Gerät auf oder verschiebt Daten zwischen Speichern.

Der gewählte Modus ist eine nicht geheime Einstellung. Center und SaaS speichern jeweils ein URL-/Token-Profil im sicheren Plattformspeicher. Ein Wechsel sperrt den lokalen Service, beendet die Freigabe und gibt die gehostete Seite/Sitzung frei. Der Wechsel in den Hintergrund leert gehostete Inhalte und macht verspätete Antworten ungültig; die erneute Verbindung bei Rückkehr erfolgt ausdrücklich. Siehe mobile Konfiguration für Profilschlüssel und Upgrade-Verhalten sowie die mobile Anleitung für Benutzerschritte.

Desktop-Tray und Statusprojektion

Request::DesktopStatus liefert eine typisierte Projektion des Initialisierungs-/Sperrzustands, der Bibliotheks- und Verbindungsanzahl, konfigurierter Anbieterarten und der Synchronisierungswarteschlangen. Sie läuft vor der Weiterleitung entsperrter Operationen und klont oder schreibt weder den verschlüsselten Zustand fest, berührt keine Inaktivitäts-/Rechteerhöhungstimer und legt keine Kennungen, Kontozusammenfassungen, Inhalte oder Zugangsdaten offen. Antworten im gesperrten Zustand enthalten keine Details. Die bestehende MCP-Zulassungsliste verweigert diese Anfrage.

Die CLI-Bibliothek beherbergt das lokale Dashboard und das Windows-/macOS-Tray. Sowohl memories tray als auch der eigenständige Starter memories-tray verwenden eine native Ereignisschleife im Hauptthread. HTTP-Server und begrenzter Worker für Statusabfragen laufen separat, sodass ein beschäftigter Daemon weder Tray noch Browser blockieren kann. Die Abfrage ruft die benachbarte CLI über das normale, vom Betriebssystem authentifizierte IPC auf, mit Frist und Bereinigung des Kindprozesses. Die HTTP-Schnittstelle liefert eingebettete Ressourcen, die feste Statusprojektion und eine ausdrücklich begrenzte Zulassungsliste zur Bearbeitung gewöhnlicher Karten/Typen. Sie kann weder entsperren, Rechte erhöhen, Geheimnisse offenlegen noch beliebige Serviceanfragen weiterleiten. Siehe SECURITY.md für ihre Token- und Browser-Origin-Grenze sowie Desktop-Nutzung.

Retrieval und Modellorchestrierung

search::Cache besitzt höchstens zwei Tresorindizes, jeweils begrenzt auf 10,000 Abschnitte, 16 MiB Quelltext/Metadaten und 32 MiB Vektoren. Vor der Indexierung schließt er private Inhalte, Zugangsdaten, Dateien, gelöschte Inhalte, Inhalte unter Quarantäne und Konfliktinhalte aus. BM25 gewichtet Titel/Textkörper/Metadaten mit 5/1/2. Die Vektorsuche verwendet Kosinusähnlichkeit; die hybride Suche kombiniert beide Ranglisten mittels Reciprocal-Rank Fusion. Die standardmäßige Neubewertung verstärkt Abfragedeckung und exakte Phrasenübereinstimmungen innerhalb einer begrenzten Kandidatenmenge. Ein konfigurierter Modellendpunkt kann eine gelernte Neubewertung durchführen.

Retrieve, RagIndex, RagStatus und RagAsk behalten Tresorautorisierung und MCP-Grant-Geltungsbereiche bei. IPC führt Modellarbeit außerhalb des Service-Mutex aus und überprüft Entsperrgeneration, Grant-Gültigkeit, Zugriff und Quellrevisionsstempel vor/nach externer Arbeit und vor der Auslieferung erneut. Signierte Absichten gehen Inferenz/Export voraus; Erfolg/Fehlschlag und ausgelieferte Quell-IDs werden ohne Prompts oder Schlüssel protokolliert. Quell-Asset-/Revisionsreferenzen verwenden die gemeinsame Kurz-ID-Projektion; Abschnittshashes und Zitatmarkierungen wie [S1] sind keine Asset-IDs.

rag::Runtime lädt native ONNX-Inferenz und die festgelegten EmbeddingGemma-Q4- Ressourcen bei Bedarf oder ruft eine konfigurierte Gemini-/kompatible Embedding-URL auf. Sie unterstützt außerdem konfigurierte Generierungs- und Neubewertungs-URLs, über Umgebungsvariablen referenzierte API-Schlüssel, Proxys und Wiederholungen. Native Modelldateien sind öffentliche Modelldaten; verschlüsselte Benutzerdatensätze werden niemals zu Modellgewichten. Abgerufener Text ist in Generierungs-Prompts nicht vertrauenswürdiges Material, und zurückgegebene Zitat-IDs werden gegen die ausgewählten Quellen validiert. Dies validiert Referenzen, nicht die sachliche Richtigkeit modellgenerierter Texte.

Mobile FFI erhält die verbesserte lexikalische Suche und unterstützt BM25 retrieve. Modellgestützte Operationen verwenden derzeit den konfigurierten Desktop-Daemon; diese Veröffentlichung ergänzt Flutter um keine Oberfläche für Modellkonfiguration oder Modellinferenz.

Kryptografische Desktop-Aufträge

jobs::Job beschreibt Werkzeuge, festgelegte Eingabedateien/-bäume, Zugangsdatenbindungen, geordnete Schritte, Bereinigung und einen neuen Ausgabepfad. Die crypto-Rezepte der CLI erstellen diesen Plan für S/MIME/OpenPGP und Android-/iOS-Signierung. Die Genehmigung wird geprüft, bevor Kurz-IDs aufgelöst werden, sodass ihr Hash genau die dem Aufrufer angezeigten Referenzen bindet. Der Service prüft lokale Rechteerhöhung und Tresorzugriff, löst ausschließlich Zugangsdaten-Assets auf, schreibt eine Ausführungsabsicht fest und ruft dann den gemeinsamen Core-Runner auf.

Der Runner prüft Werkzeuge erneut, kopiert und überprüft Eingaben, materialisiert Zugangsdaten in einem privaten Arbeitsverzeichnis, führt Befehle ohne Shell aus, unterdrückt deren Ausgabe und veröffentlicht nur ein erfolgreiches Artefakt. Die Platzhalterexpansion ersetzt ausschließlich Pfade und interpretiert Pfadinhalte nicht rekursiv. Die MCP-Zulassungsliste und die mobile FFI verweigern Prozessaufträge. Die bestehende run-Semantik bleibt unverändert.

Skills für KI-Clients

memories inject ist eine ausschließlich in der CLI verfügbare Installationsoperation. skills.rs bettet die versionierte crates/cli/skills/memories/SKILL.md in die ausführbare Datei ein und installiert sie in dokumentierten Erkennungsverzeichnissen von Codex, OpenCode oder Claude Code. Sie läuft vor der Erstellung des Datenverzeichnisses und öffnet niemals den Speicher oder ruft den Daemon auf. Benutzer- und Projektgeltungsbereiche teilen denselben Anweisungstext; Speicherpfade, Tresor-IDs, Grant-Tokens oder geheimes Material werden nicht darin eingesetzt.

Der Installer prüft alle Ziele vorab, bewahrt identische Dateien, erfordert --force bei abweichendem Inhalt, weist verlinkte Skill-Dateien/-Verzeichnisse ab und veröffentlicht jede Datei über eine synchronisierte temporäre Datei in ihrem Zielverzeichnis. Neue Dateien werden veröffentlicht, ohne eine gleichzeitig erstellte Datei zu überschreiben. Dies ist Atomarität pro Datei, keine clientübergreifende Transaktion. Vorhandene benachbarte Ressourcen und Clientkonfigurationen bleiben erhalten. Der Skill leitet gewöhnliche Suche, Retrieval mit Zitaten, konfigurierte Antworten und Schreibvorgänge über bestehende MCP- oder CLI-Schnittstellen; er fügt keine Autorisierungsfähigkeiten hinzu.

Cloud-Autorisierung

Die Desktop-CLI führt Browser-OAuth mit PKCE, einem Loopback-Callback und festen Anbieterendpunkten aus. CloudBegin erstellt unter sudo ein ablaufendes, an Aufrufer/Anbieter/Client gebundenes Ticket. Netzwerkanfragen laufen außerhalb des Daemons; CloudComplete prüft Ticket und aktuelle Autorisierung vor dem Festschreiben. Sperren, Abmelden und Neustarten machen ausstehende Tickets ungültig und verhindern, dass verspätete Ergebnisse die Anmeldung wiederherstellen.

State.cloud_accounts speichert Tokens verschlüsselt auf dem lokalen Gerät. Der Status liefert ausschließlich Kontometadaten; Sicherungen, Kopplung, Tresorsynchronisierung und MCP schließen die Tokens aus. Eine Anmeldung begründet keine Tresormitgliedschaft.

Cloud-Objektsynchronisierung

State.cloud_sync hält dauerhafte Ausgangs-/Eingangsbelege im selben verschlüsselten Zustandsblob. CloudSyncEnqueue schreibt die exakten serialisierten Hüllenbytes und einen signierten Deskriptor vor jeglicher Transport-E/A. Objekt-IDs sind SHA-256-Hashes dieser Bytes; Wiederholungen verwenden sie erneut. CloudSyncWork liefert Chiffretext und Listing-Cursor ohne OAuth-Tokens. sync::execute führt begrenzte put/get/list-Operationen ohne den Service-Mutex aus. CloudSyncAck prüft eine prozesslokale Sitzungsgeneration und schreibt dann Upload-Markierungen, entdeckte IDs, heruntergeladene Bytes und Tresorzusammenführungen gemeinsam fest. Deskriptoren, die vor ihren Objekten ankommen, bleiben ausstehend. Sperren, Entsperren und Abmelden erhöhen die Sitzung, sodass verspätete Bestätigungen keinen Import auslösen können. memories cloud sync fordert den Daemon auf, Tokens zu erneuern und über die Anwendungsordner von OneDrive oder Google Drive hoch- und herunterzuladen; diese HTTP-Arbeit läuft außerhalb der Schreibsperre. Tokens werden niemals über IPC zurückgegeben. Tests verwenden außerdem MemoryTransport und Loopback-Graph-/Drive-Testumgebungen. Abgeschlossene Warteschlangennutzdaten werden zu Hashbelegen und Veröffentlichungsstempeln pro Anbieter/Empfänger verdichtet. Belege bleiben lokal und löschen keine Cloud-Historie. Fehlende Objekte werden mit einer dauerhaft gespeicherten exponentiellen Verzögerung erneut angefordert; die Kapazität ausstehender Einträge begrenzt durch Rückstau die Auflistung. Anbieter-Worker arbeiten pro Konto seriell und verweigern Erneuerungs-/Importergebnisse aus einer ungültig gewordenen Sitzung. IPC-Weiterleitung verwendet höchstens 16 gleichzeitige Verbindungen.

Siehe Synchronisierungsentwurf und Autorisierungsanleitung.

Entfernte Sitzungen

Der Desktop-Daemon besitzt SSH-, FTP-, TCP-, MySQL-, Redis- und PostgreSQL-Verbindungen. RemoteOpen validiert die Host-Zulassungsliste der Zugangsdaten, protokolliert eine Verbindungsabsicht und verbindet sich dann außerhalb der Schreibsperre. SSH authentifiziert sich mit Passwort-Zugangsdaten oder einem importierten privaten OpenSSH-Schlüssel, optional zusätzlich mit OpenSSH-Zertifikat-Zugangsdaten. CredentialGenerate erstellt SSH-Schlüssel und TLS-Zertifikate unter sudo; der private Schlüssel wird als Zugangsdaten gespeichert und niemals zurückgegeben. CredentialPublic leitet öffentliche SSH-Schlüssel oder PEM-Zertifikate aus diesem gespeicherten Material ab. Datenbanksitzungen aktivieren TLS standardmäßig und können optionale PEM-CA-Zugangsdaten (tls_ca) an den Vertrauensspeicher des Clients anhängen. Die Prüfung des Hostnamens ist erforderlich; Zertifikat-Pinning ist nicht implementiert. Jede Anweisung wird als Ticket vorgeschlagen, dessen Fingerabdruck Sitzung, Sequenz und kanonische Anweisung umfasst. RemoteApprove ist einmalig verwendbar und an den Aufrufer mit erhöhten Rechten gebunden; RemoteExec führt ausschließlich dieses Ticket auf der bestehenden Sitzung aus. Sperren, Ablauf der Inaktivitätsfrist und Abmelden verwerfen laufende Verbindungen und ausstehende Tickets. Dateioperationen verwenden FTP; SSH- und Datenbanksitzungen akzeptieren exec/query. ProxyStart bindet einen Loopback-Listener nach denselben Prüfungen der Zugangsdaten und Host-Zulassungsliste wie RemoteOpen. Lokale Clients verbinden sich ohne Geheimnisse; der Daemon hält die vorgelagerte SSH- oder Datenbankauthentifizierung. proxy.start protokolliert die Verbindungsabsicht vor dem Binden; proxy.stop protokolliert die Beendigungsabsicht. Der gebundene Socket wird direkt an Tokio übergeben, ohne Zeitfenster für Schließen/Neubinden. PostgreSQL SSLRequest und MySQL SSLRequest gehen dem TLS-Upgrade voraus; Redis verwendet direktes TLS. PostgreSQL SCRAM prüft sowohl Nonce als auch Serversignatur. MySQL unterstützt native und Caching-SHA-256-Authentifizierung, einschließlich Plugin-Wechseln; ein vollständiger Passwortaustausch erfordert TLS. Datenbank-Handshakes haben eine Frist von 30 Sekunden, Paketgrenzen von 64 KiB und eine Grenze von 16 Clients pro Listener. Der lokale Datenbankabschnitt ist unverschlüsselt, und Anmelde-/Datenbankstartfelder überschreiben nicht die konfigurierte vorgelagerte Identität. Lokale Clients autorisieren uneingeschränkte entfernte Anweisungen innerhalb der Berechtigungen dieses Kontos. Loopback bietet keine Authentifizierung pro Benutzer. Sperren, Ablauf der Tresor-Inaktivitätsfrist, ausdrückliches Beenden und Freigabe des Services brechen Listener und aktive Sitzungen ab. Proxys haben eine maximale Lebensdauer von 30 Minuten; Datenverkehr verlängert die Tresorentsperrung nicht. MCP kann keine Proxys verwalten. Der Service besitzt jeden Proxy-Worker und wartet beim Beenden/Sperren auf dessen Abschluss, sodass eine erfolgreiche Antwort nicht mit einer Verbindung kollidieren kann, die noch Anweisungen weiterleitet.

Ausführung von Konfigurationsdateien

memories file exec kombiniert die bestehende autorisierte Read-Anfrage mit CLI-lokaler Dateimaterialisierung und Prozessüberwachung. Es führt keine neue Serviceanfrage, Dateiart, Kryptografie oder Ausführungsberechtigung für Mobile/MCP ein. Der Daemon protokolliert die Dateiauslieferung über den bestehenden Lesepfad; anschließend führt die CLI den Kindprozess im Vordergrund aus, ohne die Servicesperre zu belegen. Die CLI besitzt den temporären Klartextsnapshot, bis der direkte Kindprozess endet; spätere Tresoränderungen oder Sperren verändern oder widerrufen diesen bereits ausgelieferten Snapshot nicht.

Wiederherstellung

Sicherungen enthalten den signierten lokalen Zustand und geheimes Wiederherstellungsmaterial unter einer unabhängigen Argon2id-/AEAD-Hülle. Die Wiederherstellung erzeugt neue Geräteschlüssel und unabhängige Tresor-IDs und bewahrt aktuelle Inhalte und Konfliktköpfe. Ursprüngliche signierte Historien bleiben in einem verschlüsselten schreibgeschützten Archiv erhalten. Die Wiederherstellung behauptet nicht, dass eine historische gemeinsame Mitgliedschaft noch aktuell ist. Rein gerätelokale Tresore, Cloud-Autorisierungen und Cloud-Ausgangs-/Eingangsbelege sind ausgeschlossen; jedes wiederhergestellte Gerät meldet sich separat bei Cloud-Anbietern an.

Karten und sichere Projektionen

Kind::Card teilt die Autorisierung gewöhnlicher Erinnerungen; typisierte Metadaten werden innerhalb verschlüsselter Revisionen gespeichert. CardLink ergänzt gerichtete Kanten innerhalb desselben Tresors. Graphen projizieren nur aktuelle, eindeutige sichtbare Knoten und Kanten, deren beide Endpunkte sichtbar sind. Die Suche verwendet den oben beschriebenen begrenzten FTS5-Cache im Arbeitsspeicher und umfasst gewöhnliche Textkörper, Tags/Quellen und zugelassene Metadaten geschützter Karten. Geheime Inhalte von Zugangsdaten gelangen niemals in diesen Index. Suche/Liste/Graph legen eine sichere summary-Projektion offen; Kartenlesevorgänge behalten die undurchsichtige Zugangsdatenreferenz bei, lösen jedoch niemals deren Wert auf.

protected_card validiert eine Konto-/env-/Token-/TOTP-/HOTP-Eingabe (einschließlich Import einer otpauth-URI), schreibt Zugangsdaten und deren Karte in einen Kandidatenzustand und schreibt beide gemeinsam fest. Generisches put kann keine geschützten Referenzen anhängen oder ersetzen. Geheimnisoperationen lösen aktuelle Zugangsdatenrevisionen auf und überprüfen deren Art. otp_code implementiert RFC 6238 (TOTP) und RFC 4226 (HOTP), erhöht den HOTP-Zähler im selben Commit und protokolliert die Auslieferungsabsicht vor der Rückgabe eines Codes. Die Erstellung von HTTP-Headern markiert Bearer-/Cookie-Werte als sensibel; Weiterleitungen sind deaktiviert, und Antworten werden unterdrückt.

Erinnerungs- und Karteninhalte können außerdem eine secrets-Map von einem stabilen Label zu einer kanonischen Zugangsdaten-Asset-ID enthalten. protect_secret ersetzt exakte Übereinstimmungen im Textkörper durch {{secret:LABEL}} und erstellt die Zugangsdaten in derselben Transaktion. Generisches put verlangt unveränderte bestehende Zuordnungen und kann sie weder erfinden noch auf andere Ziele richten. CLI- und mobile Bearbeitungen übernehmen die bestehende Map. MCP card_write lässt die Map aus, sodass Aktualisierungen von Karten mit Geheimnisreferenzen an der Validierung scheitern. Die Clientprojektion verkürzt ausschließlich typisierte Zugangsdaten-IDs und belässt Textkörpermarkierungen stabil. Die Wiederherstellung aus Sicherungen bewahrt eindeutige Asset-IDs, sodass die Zuordnungen die Wiederherstellung überstehen. credential_copy löst ein Label, eine geschützte Karte oder direkt Zugangsdaten auf, erfordert lokale Rechteerhöhung und schreibt eine Audit-Absicht fest, bevor UTF-8-Klartext an den Zwischenablageclient zurückgegeben wird. MCP weist beide neuen Operationen ab. Keine generische Lese-, Such- oder Graphoperation löst ein Geheimnis auf. Signierte historische Textkörper bleiben durch die Ersetzung unverändert; siehe die Wiki- und Zwischenablagegrenzen in SECURITY.md.

Der Service liefert {"secret":"..."} ausschließlich an den autorisierten lokalen Aufrufer der Kopieroperation. Die CLI verarbeitet diese Antwort in clipboard.rs und liefert {"copied":true} in ihrer normalen Ausgabehülle erst nach erfolgreichem Schreiben in die Zwischenablage zurück. Mobile verwendet den Zwischenablagekanal von Flutter und prüft vor der Auslieferung seine Lebenszyklusgeneration. Das Audit protokolliert credential.copy mit delivery_intent, keinen Erfolgsbeleg der Betriebssystem-Zwischenablage. Siehe Nutzungsanleitung.

State.local_vaults markiert rein gerätelokale Tresore innerhalb des verschlüsselten lokalen Zustands. local_config protokolliert vom Client gesammelte Versions- und Verzeichnismetadaten in einem solchen Tresor. Die Gerätegenehmigung filtert diese Tresore heraus; direkter Mitgliedschaftsexport und Synchronisierung werden abgewiesen; store::backup entfernt sie aus seinem exportierten Snapshot. Eindeutige Asset-IDs überstehen die Wiederherstellung in einem neuen Tresor und bewahren Graph- sowie Karten-zu-Zugangsdaten-Referenzen, während ursprüngliche signierte Historien archiviert bleiben.