Memories

Memories / Dokumentation

Auf dieser Seite

Memories Technische Dokumentation

Dieser Text beschreibt die aktuell implementierte Speicherung, Vertrauensgrenzen, lokale Autorisierung, gehosteten Center, versiegelte Geheimnisse, Retrieval-Datenflüsse, Cloudobjektsynchronisierung und Desktopstatusgrenzen. Er beschreibt dasselbe Verhalten wie SECURITY.md, docs/architecture.md, docs/authorization.md und docs/center.md. Die Speicherformatversion ist 1. Dies ist Entwicklungssoftware; bestandene Tests entsprechen keiner unabhängigen Sicherheitsprüfung.

Speicherung und Vertrauensgrenzen

Die Tabellen der lokalen Datenbank heißen header, state und checkpoints. Abgesehen von Formatmetadaten, Salt und Zeilennummern sind alle Werte Chiffretext mit zugehörigen Daten. Auch das Journal enthält Chiffretext. Es gibt keinen persistenten Klartext-Volltextindex.

Die version im Formatheader muss 1 sein, sonst schlägt das Öffnen fehl. Das Benutzerpasswort wird mit Argon2id (Version 0x13, 64 MiB Speicher, 3 Iterationen, Parallelität 1) und einem 16-Byte-Salt zu einem 32-Byte-Schlüssel abgeleitet. Dieser Schlüssel umschließt einen zufälligen Hauptschlüssel mit memories/master/v1 als zugehörigen Daten. Der Hauptschlüssel verschlüsselt Zustand und lokale Checkpoints. Die symmetrische Verschlüsselung verwendet XChaCha20-Poly1305.

Jede Berechtigungsepoche hat einen eigenen Tresorschlüssel. Jede Revision hat einen zufälligen Datenschlüssel, den der Epochenschlüssel umschließt. Serialisierte Inhalte werden in separat authentifizierte 256-KiB-Blöcke zerlegt; Blockposition und Gesamtblockzahl fließen in die zugehörigen Daten ein. Revisionssignaturen decken Asset-ID, Elternversionen, Richtlinienkopf, Tombstone-Markierung, Chiffretext und Gerätezertifikat ab. Der Signaturalgorithmus ist Ed25519.

Änderungen werden zunächst auf einem geklonten Zustand vorbereitet; anschließend werden verschlüsselter Zustand und Checkpoints in derselben SQLite-Transaktion mit synchronous=FULL festgeschrieben. Lese- und Ausführungsabsichten werden vor der Auslieferung festgeschrieben. Datenträgerfehler verhindern daher die Auslieferung; ein Absturz nach dem Absichtscommit kann ein unbekanntes Ergebnis hinterlassen. Eine exklusive Betriebssystemsperre begrenzt dasselbe Datenverzeichnis auf einen kooperierenden Schreiber. Die Initialisierung schreibt zuerst die vollständige Datenbank in dasselbe Verzeichnis, schließt und synchronisiert sie und veröffentlicht sie dann am Ziel, ohne ein bestehendes Ziel zu überschreiben. Jedes Gerät verwendet seinen eigenen Speicher. Eine gerade verwendete SQLite-Datei durch einen Cloudlaufwerkclient synchronisieren zu lassen gewährleistet keine geräteübergreifende Transaktionssicherheit.

Der Ed25519-Schlüssel des Benutzers zertifiziert die Ed25519-Signatur- und X25519-Austauschschlüssel des Geräts. Das Zertifikat allein reicht nicht: Jede Tresorrichtlinie muss das Gerät ausdrücklich autorisieren. Die Geräteschlüssel verschiedener Geräte desselben Benutzers sind unabhängig. Die ursprüngliche Signaturbefugnis des Benutzers wird nur in authentifizierten, für den Empfänger verschlüsselten Genehmigungspaketen an genehmigte persönliche Geräte übertragen. Nach einem Gerätewiderruf kann der Benutzeridentitätsschlüssel die Geräte-Allowlist dieses Tresors nicht umgehen.

Transportumschläge enthalten Formatversion, sendenden Geräteschlüssel, Empfängeraustauschschlüssel, ephemeren öffentlichen X25519-Schlüssel, AEAD-Nutzlast und Ed25519-Signatur. Der Transportschlüssel wird mit HKDF abgeleitet. Empfängeridentität und ephemerer Schlüssel sind authentifiziert. Gerätebeitritt verwendet ablaufende signierte Anfragen und bindet den öffentlichen Schlüssel des genehmigenden Geräts ausdrücklich. Anfragen werden erst nach erfolgreichem Commit verbraucht. Der Genehmigungsfingerabdruck ist der vollständige SHA-256. Verkürzte Anzeigen in Listen reichen allein nicht als Genehmigungsgrundlage.

Richtlinien bilden eine signierte lineare Historie mit Mitgliedern, Rollen, Geräte-Allowlist, ausschließlich wachsender Widerrufsmenge und Epochen. Rollenprüfungen verwenden die vorherige Richtlinie. Gewöhnliche Benutzer können ein weiteres Gerät für ihre eigene Identität autorisieren, ohne die Mitgliedschaft zu ändern. Nur Admin oder Owner können Mitglieder einladen, Beitritte genehmigen und Geräte für Mitglieder autorisieren. Admin kann Admin-, Editor- und Reader-Mitglieder ändern, aber niemanden zu Owner machen, bestehende Owner ändern, Geräte widerrufen oder Eigentum übertragen. Owner kann dies. Eigentumsübertragung erhält genau einen Owner. Die Richtlinienvalidierung weist Änderungen von Admin an Owner-Mitgliedern oder der Widerrufsmenge zurück.

Die Asset-Historie ist ein inhaltsadressierter gerichteter azyklischer Graph. Hat ein Asset mehrere noch nicht verbrauchte Revisionen, liegt ein Konflikt vor. Auflösungsrevisionen müssen sämtliche sichtbaren Elternversionen benennen. Tombstones entfernen Assets aus der aktuellen Ansicht, löschen aber nicht die Historie.

Sicherungen speichern signierten lokalen Zustand und Wiederherstellungsmaterial unter einem unabhängigen Argon2id- und AEAD-Umschlag. Wiederherstellung erzeugt neue Geräteschlüssel und eine neue Tresor-ID, behält aktuelle Inhalte und Konfliktköpfe bei und legt die ursprüngliche signierte Historie in ein verschlüsseltes schreibgeschütztes Archiv. Sie behauptet nicht, dass alte geteilte Mitgliedschaften weiterhin gültig sind. Gerätespezifische Tresore, Cloudautorisierung und Cloud-Sende-/Empfangswarteschlangen sind nicht Teil der Sicherung.

Der vorgesehene Schutz umfasst folgende Fälle: Lesen oder Fälschen von Asset-Inhalten durch das Relay; Austausch der Gegenstellenidentität nach ausdrücklicher Fingerabdruckprüfung; Änderung authentifizierten Chiffretexts; Lesen einer kopierten Datenbank ohne lokales Passwort; gefälschte Schreibvorgänge durch Reader; Eigentumsänderungen durch Administratoren; erneute Autorisierung eines widerrufenen Geräts mit dem Benutzeridentitätsschlüssel; versehentliches Ausgeben von Zugangsdaten durch CLI oder MCP, Passwortannahme auf der Kommandozeile oder Übernahme erhöhter Terminalrechte durch MCP-Fähigkeiten; unbemerkte Änderungen signierter Revisionen oder Audits, Kettenlücken und Checkpoint-Verkürzung relativ zum verbleibenden Datenbankzustand.

Die folgenden Fälle liegen außerhalb der Grenzen und werden nicht als gelöst dargestellt:

  • Kompromittierte Endgeräte, Betriebssystemadministratoren, autorisierte bösartige Programme, Speicherinspektion, Keylogging und bewusstes Kopieren von Klartext durch Benutzer. Rust-eigene Schlüsselbuffer werden genullt. Für Betriebssystem-Swap, Absturzabbilder, Allokationen von Abhängigkeiten und durch Dart-Garbage-Collection verwaltete Strings besteht keine Löschgarantie. Desktopclients haben keinen Hardwareschlüsselspeicher.
  • Das Relay kann Verkehrsmetadaten beobachten, Verbindungen blockieren, Chiffretext selbst aufzeichnen, Widerrufe verzögern oder Geräte partitionieren. Der mitgelieferte Relayserver schreibt keine Assets, aber ein bösartiger Server lässt sich nicht zwingen, Verkehr nicht aufzuzeichnen. Das Relay puffert nicht für offline verfügbare Geräte.
  • Offlinewiderruf kann vergangenen Klartext, Schlüssel oder Sicherungen nicht löschen. Endgeräte, die einen Widerruf noch nicht erhalten haben, können alte lokale Kopien weiter verwenden.
  • Audit beweist signierte Inhalte und Kontinuität relativ zu einem bekannten Zustand, nicht dass ein kompromittiertes Gerät jeden Zugriff protokolliert hat. Wird die gesamte Datenbank samt lokaler Beweise durch eine ältere, intern konsistente Sicherung ersetzt, lässt sich dies ohne neueren Gegenstellen-Checkpoint oder externen Anker nicht erkennen. Es gibt keinen vertrauenswürdigen Zeitstempeldienst.
  • Andere Prozesse desselben Betriebssystembenutzers liegen innerhalb der lokalen Kontogrenze. IPC authentifiziert den Betriebssystembenutzer. Terminalrechteerhöhung verwendet zusätzlich die PID des Elternprozesses. Dies ist weder Isolation gegen bösartige Prozesse desselben Benutzers noch eine dauerhafte, von PID-Wiederverwendung unabhängige Sitzungsidentität.
  • Fingerabdrücke ausführbarer Dateien werden vor dem Start geprüft. Es gibt keine Betriebssystemsandbox, verpflichtende Codesignierung, atomare Ausführung über Dateihandles oder Begrenzung von Nachfahrenprozessen.
  • Zwischenablagekopien, exportierte Dateien und ausdrücklich zum Kopieren angeforderte Zugangsdaten verlassen den verschlüsselten Speicher auf Benutzeraktion. Kopierter Inhalt bleibt nach dem Sperren bestehen und kann vom Betriebssystemverlauf oder anderen Anwendungen behalten werden.

Lokale IPC und Autorisierung

service::Request ist die gemeinsame typisierte Operationsschnittstelle, unterschieden durch op in snake_case. Unbekannte Felder auf oberster Ebene werden zurückgewiesen. Lokale IPC verwendet JSON-Frames mit einem 32-Bit-Längenpräfix in Big Endian und einem Wrapper der Version 1; optionale HTTP/WebSocket-Listener und Relay-RPC verwenden gemeinsam binäre WebSocket-JSON-Frames mit Tokenauthentifizierung. Desktopfernzugriff stellt nach Entsperren/Rechteerhöhung dieselben Operationen wie lokale IPC bereit (ws:remote / relay:remote); mobile FFI/Share hat weiterhin plattformspezifische Sperrlisten. Details siehe docs/remote-daemon.md und SECURITY.md. Optionale Autorisierungszentren ([[centers]]) verhindern lokales Bootstrapping. Ticketmodus stellt Registrierungs-, MCP-Autorisierungs- und Entsperrtickets aus; gehosteter Modus speichert Inhalte im verschlüsselten Serverspeicher des Centers. Siehe unten sowie docs/center.md und docs/authorization.md.

Der Daemon bedient nur den aktuellen Betriebssystembenutzer. Windows verwendet Named Pipes, Linux und macOS Unix-Sockets. IPC akzeptiert höchstens 16 gleichzeitige Clients. Frame-Lesen über Windows-Named-Pipes ist weiterhin blockierend: Stockende Clients desselben Benutzers belegen diese Plätze, aber ein einzelner stockender Client oder Cloudtransfer blockiert nicht alle anderen Verbindungen. Unix-Frame-I/O hat Fristen. Dienstoperationen mit Schreibsperre, einschließlich der Ausführung vertrauenswürdiger Unterprozesse, bleiben seriell.

Gewöhnliches Entsperren verfällt nach 15 Minuten Inaktivität. sudo verwendet dasselbe lokale Passwort, gilt höchstens 15 Minuten, verfällt nach 5 Minuten Inaktivität und ist auf den Terminalelternprozess des Befehls begrenzt. Sperren oder Neustart löscht erhöhte Rechte. Versuche im vollständig gesperrten Zustand werden begrenzt, aber nicht in das persistente signierte Audit geschrieben. Im entsperrten Zustand mit verfügbarer lokaler Signaturidentität werden fehlgeschlagene Operationen auditiert. Absichten werden vor Auslieferung festgeschrieben; plötzliche Abstürze hinterlassen eine festgeschriebene Absicht und kein erfundenes Ergebnis.

MCP-Berechtigungen sind lokale Bearer-Fähigkeiten, die in eine vom Aufrufer angegebene Datei geschrieben und nicht im Terminal ausgegeben werden. --minutes von mcp grant bestimmt die Laufzeit; erst --write erlaubt das Erstellen gewöhnlicher Erinnerungen. mcp serve --grant-file liest die Fähigkeit aus dieser Datei und bietet über MCP 2024-11-05 auf stdio die Werkzeuge memory_search, memory_retrieve, memory_ask, memory_read, memory_read_revision, memory_history, memory_diff, memory_write, memory_delete, card_write, card_graph, card_link. Jeder Aufruf trägt den Tresor aus der Berechtigung und wird vor Dispatch separat auf die Fähigkeit geprüft.

MCP kann keine erhöhten Terminalrechte übernehmen. Es kann keine privaten Erinnerungen, Dateien oder Zugangsdaten lesen, keine Prozesse, Remotesitzungen, Loopback-Proxys oder kryptografischen Aufträge ausführen, keine Tresormitgliedschaft verwalten und kein DesktopStatus anfordern. Sperren löscht Berechtigungen im Speicher; nicht abgelaufene kehren nach Entsperren zurück, das Sperren selbst löscht sie nicht. Ausstellen, Auflisten, Widerrufen, Beantragen und Abholen des Autorisierungsdiensts sind über MCP-Werkzeuge aufrufbar, verwenden aber weiterhin die MCP-Fähigkeit selbst, übernehmen keine erhöhten Terminalrechte und verwenden keinen Center-Administrator-Bearer. Gewöhnliches Lesen löst {{secret:标签}} nicht auf. card_write trägt keine Geheimniszuordnung, daher scheitert das Aktualisieren von Karten mit Geheimnisreferenzen bei der Validierung. Kurze Referenz-IDs verkürzen nur typisierte Zugangsdaten-IDs; Markierungen im Haupttext bleiben unverändert.

otp_code implementiert TOTP nach RFC 6238 und HOTP nach RFC 4226. HOTP speichert den erhöhten Zähler im selben Commit, der den Code zurückgibt. parse_otp_import akzeptiert otpauth:// und Google Authenticators otpauth-migration://offline?data=... und parst Konten als TOTP- oder HOTP-Karten. Ist der Typ im URI-Host, im Parameter type oder in Migrationsdaten angegeben, gilt dieser Wert; fehlt er, ist ein Konto mit Zähler HOTP, andernfalls TOTP. Aufrufer müssen keinen Typ zusätzlich wählen. CLI---image decodiert zuerst diese beiden URI-Arten mit rqrr aus dem Bild und nutzt dann denselben Importpfad; URI und --image dürfen nicht gemeinsam angegeben werden. Bei mehreren Karten ist --title nur ein Titelpräfix; --id kann nur eine einzelne Karte ersetzen. Die Telefonkamera importiert diese beiden OTP-QR-Code-Arten nicht. Scannen für gehostete Gerätekopplung ist ein anderer Pfad, siehe unten. Kartenrevisionen können außerdem optionale Aliasse, Anmerkungen und Kategorien enthalten; beim Aktualisieren bewahrt das Weglassen dieser Felder den bisherigen Wert, eine leere Zeichenfolge löscht ihn. Seeds gelangen weder in Suche noch MCP. TOTP erfordert eine korrekte lokale Uhr. Das Ergebnis ist ein autorisierter kurzlebiger Code, kein Seedexport; das Audit protokolliert weder Codes noch Seeds.

credential_copy ist eine ausdrückliche Ausnahme von den Ausgabebeschränkungen für Zugangsdaten. Es erfordert lokale Rechteerhöhung, schreibt zuerst die Auditabsicht fest und übergibt danach UTF-8-Klartext an den Zwischenablageclient. Die CLI gibt {"copied":true} erst nach erfolgreichem Schreiben in die Systemzwischenablage aus. MCP kann kein Kopieren anfordern. Das Audit erfasst credential.copy und die Auslieferungsabsicht, nicht die Erfolgsbestätigung der Betriebssystemzwischenablage.

Die mobile ABI ist in crates/ffi/memories.h deklariert. Handles sind numerische Registrierungs-IDs, keine rohen Rust-Zeiger. Zurückgegebene Strings werden genau einmal mit memories_free freigegeben. Ungültiges JSON erzeugt generische Fehler ohne Echo der Eingabe. memories_lock_all erhöht beim Wechsel der Anwendung in den Hintergrund die globale Sperrgeneration, unterdrückt verspätete laufende Antworten und verwirft alle gehosteten Sitzungen. Der mobile Pfad enthält keine Prozessausführung, lokale MCP-Berechtigungserstellung, lokale Berechtigungsverwaltung oder RPCs für Berechtigungsanträge. hosted_*-Aufrufe zu gehosteten Centern sind ein anderer Pfad: Für Inhalte sind nur Auflisten, Lesen und Schreiben von kind = credential zugelassen.

Kryptografische Aufträge prüfen den Genehmigungsdigest vor der Auflösung kurzer IDs; der Digest bindet daher die vom Aufrufer gesehenen Referenzen. Der Dienst prüft lokale Rechteerhöhung und Tresorzugriff, löst ausschließlich Zugangsdaten-Assets auf, schreibt die Ausführungsabsicht fest und ruft dann den gemeinsamen Runner auf. Der Runner prüft Werkzeuge erneut, kopiert und prüft Eingaben, materialisiert Zugangsdaten in einem ausschließlich für den Eigentümer zugänglichen Arbeitsbereich, führt Befehle ohne Shell aus, unterdrückt Werkzeugausgaben und veröffentlicht nur erfolgreiche Artefakte. Platzhalter ersetzen ausschließlich Pfade. MCP-Allowlist und mobile FFI weisen Prozessaufträge zurück.

Berechtigungen, Berechtigungsanträge, Hosting und versiegelte Geheimnisse

Lokale Autorisierung und gehosteter Center verwenden dieselben Rollengrenzen. Reader maximal read, Editor maximal read_write, Admin maximal read_write_delete, Owner maximal allow_all. Ohne Umfangsangabe gilt read. Reader und Editor können weder ausstellen noch weiterdelegieren. Ausstellung ist sowohl durch die Rolle als auch durch den Umfang der vom Aufrufer gehaltenen Berechtigung begrenzt, darf keine Tresorgrenze überschreiten und nicht länger als die Elternberechtigung gültig sein. Die Laufzeit beträgt 1–60 Minuten. Direkt von Mitgliedern ausgestellte Berechtigungen haben Tiefe 1; Ausstellung mittels Berechtigung erhöht sie um 1, über 2 wird abgelehnt. Persistente Mitgliedszugangsdaten beim Center haben Tiefe 0 und zählen nicht als Delegation. Empfänger müssen bereits Tresormitglieder sein, dürfen keine höhere Rolle als der Aussteller haben und nicht den reservierten Namen center-admin tragen. Inhaltsberechtigungen ändern die Rolle des Empfängers nicht.

Höchstens 10000 Berechtigungen dürfen gleichzeitig gültig sein (service::MAX_ACTIVE_GRANTS); lokaler Daemon und gehosteter Center teilen diese Grenze. Token erscheinen ausschließlich in der einmaligen Antwort beim Ausstellen oder Abholen. Persistenter Zustand speichert nur SHA-256 und Metadaten; Vergleiche erfolgen in konstanter Zeit. Sperren verwirft Schlüssel im Speicher und pausiert Berechtigungen, widerruft sie aber nicht; nach Entsperren oder Neustart bleiben nicht abgelaufene Berechtigungen gültig. Abgelaufene Berechtigungen und ihre Nachfahren werden beim Laden und bei periodischen Prüfungen entfernt. Widerruf wird an Nachfahren weitergegeben. Wird ein Mitglied entfernt oder die Rolle eines Ausstellers unter einen ausgestellten Umfang abgesenkt, werden die betreffenden Berechtigungen beim Richtliniencommit ungültig. Berechtigungen gelangen nicht in Tresorsynchronisierung oder Wiederherstellungssicherungen.

Berechtigungsanträge werden zuerst genehmigt und dann abgeholt. Die Genehmigung eines Umfangsantrags erfasst nur die Grenze und erzeugt kein Token; der Antragsteller holt es einmal mit den Mitgliedszugangsdaten ab, die bei Antragserstellung verwendet wurden. Geht diese Antwort verloren, kann das Token nicht erneut abgerufen werden. Rollenanträge existieren nur lokal und ändern bei Genehmigung sofort die Richtlinie, ohne Abholen; Owner wird über signierte Eigentumsübertragung vergeben, zeitlich begrenzte Berechtigungen können keine dauerhaften Rollenänderungen genehmigen. Gehosteter Center akzeptiert ausschließlich Umfangsanträge. Antragsteller können ihre eigenen Anträge weder genehmigen noch ablehnen. Berechtigungsaufrufer, deren Subjekt und Aussteller verschieden sind, können Anträge einreichen, aber nicht genehmigen, ablehnen, abbrechen oder abholen. Höchstens offen bleiben 20 Anträge pro Antragsteller und Tresor sowie 200 pro Tresor. Nach 7 Tagen werden sie ungültig. Entschiedene, abgelaufene oder abgeholte Anträge werden 30 Tage nach ihrem letzten Zustandsübergang gelöscht.

Das lokale Audit ist eine gerätesignierte Hashkette. DIR/audit.jsonl des Centers ist eine schlüssellose Kette: Sie erkennt Änderungen relativ zu einem bekannten Kopf, verhindert aber nicht, dass der Betreiber das gesamte Protokoll neu schreibt.

Der Center hat zwei Modi. mode = ticket (Standard) stellt nur Registrierungs-, MCP-Autorisierungs- und Entsperrtickets aus; Inhalte bleiben in den eigenen verschlüsselten Gerätespeichern. Entsperrtickets sind bis zum Ablauf wiederverwendbar, nicht an ein bestimmtes Gerät gebunden und erlauben nur lokales Entsperren mit dem Gerätepasswort, ohne sudo oder erhöhte MCP-Rechte. Bei mode = saas und Betrieb des Centers mit --data liegen Inhalte im verschlüsselten Serverspeicher. Der Betreiber besitzt das Speicherpasswort und kann entsperrten Klartext lesen. Dies ist serverseitige Verschlüsselung, keine Vertraulichkeitsgrenze gegenüber dem Betreiber. Ist genau ein mode = "saas" konfiguriert, leitet der Daemon Inhalts-RPC an /v1/rpc dieses Centers weiter. Nicht unterstützte Operationen scheitern direkt, ohne Rückfall auf den lokalen Speicher. Der Administrator-Bearer verwaltet Sperren, Entsperren und Mitglieder; seine Verwendung auf Inhaltsrouten liefert 401. allow_all deckt nur gehostete Inhaltsoperationen ab, nicht Serververwaltung, Geräteverwaltung, sudo, Registrierung, Wiederherstellung, Ausführung oder kryptografische Aufträge.

Karten mit e2e: true in gehosteten Speichern weisen Klartextgeheimnisse zurück. Nach Kopplung werden Geheimnisse in Umschläge für den öffentlichen X25519-Geräteschlüssel gelegt und mit einem bekannten Ed25519-Schlüssel signiert. Der Center speichert nur öffentliche Schlüssel und Chiffretext. Er sieht wer, welche Karte und wann und kann alte Umschläge zurückhalten oder erneut abspielen, aber den Haupttext nicht sehen. Geräteberechtigungen können weder ausstellen noch genehmigen. Widerruf löscht die Umschläge des Geräts, kann aber bereits entschlüsselten Klartext nicht zurückholen. Nur eine Owner-Berechtigung darf die e2e-Markierung entfernen; dieser Schreibvorgang darf keine Geheimnisse enthalten. Lokale Tresore verwenden für neue Geräte weiterhin ablaufende signierte Anfragen und vollständige Fingerabdruckprüfung, keine Kamera.

Retrieval und Modelldatenfluss

Suchcaches halten höchstens die Indizes zweier Tresore. Pro Tresor sind maximal 10,000 Chunks, 16 MiB Quelltext und Metadaten sowie 32 MiB Vektoren erlaubt. Private Inhalte, Zugangsdaten, Dateien sowie gelöschte, quarantänisierte und konfliktbehaftete Revisionen werden schon vor der Indexaufnahme ausgeschlossen. SQLite-Temporärspeicher wird zwingend im Arbeitsspeicher gehalten. Caches gelangen weder in Sicherungen noch Cloudexporte. Sperren löscht sämtliche Indizes und Vektoren. Änderungen von Richtlinien, Revisionen oder Quarantänestatus invalidieren den jeweiligen Cache.

Gewöhnlicher Haupttext wird nahe Unicode-sicheren Grenzen in Chunks mit höchstens 768 Zeichen und normalerweise 128 Zeichen Überlappung zerlegt. Chinesischer und gemischter Text wird mit Jieba segmentiert. FTS5 BM25 gewichtet Titel, Haupttext und sichere Metadaten mit 5, 1 und 2. any kombiniert Schlüsselwörter, all verlangt jedes Wort, phrase die ursprüngliche Phrase. Diese Bedingungen filtern auch Vektor- und Hybridkandidaten. Abfragen werden escaped und nicht als beliebige FTS-Operatoren ausgeführt. Einfaches memory search führt Chunks pro Dokument zusammen; memory_retrieve und rag search liefern einzelne Chunks mit Asset-ID, Revision, stabilem Chunkhash, ursprünglichen UTF-8-Offsets, Bewertung und Quellenlabel.

Vektoren sind normalisierte Speichercaches. Vektorretrieval verwendet Kosinusähnlichkeit. Hybrides Retrieval verwendet Reciprocal Rank Fusion mit k gleich 60. Standardmäßiges leichtgewichtiges Reranking verbessert Abfrageabdeckung und exakte Phrasenübereinstimmung in einer begrenzten Kandidatenmenge. Konfigurierte Modellendpunkte können gelerntes Reranking durchführen.

Standardembedding ist EmbeddingGemma 300M Q4 im Prozess mit lokaler ONNX-Inferenz und Vektordimension 768. ONNX-Telemetrie wird vor Erstellung der Inferenzsitzung ausdrücklich deaktiviert. Die Inferenzengine wird mit der Anwendung ausgeliefert; die etwa 209 MiB großen Modelldateien sind öffentliche Daten, die rag model-install anhand einer festen Repositoryrevision herunterlädt und vor Veröffentlichung pro Datei auf SHA-256 prüft oder die rag.local_model_dir bereitstellt. Geprüfte Dateien können offline wiederverwendet werden. Modelldateien haben eine eigene Gemma-Lizenz, sind keine Geheimnisse und keine unabhängig auditierte Sicherheitsgrenze.

Nach Konfiguration eines entfernten Embeddingendpunkts können autorisierte RAG-Operationen sämtliche geeigneten Dokumentchunks dorthin senden. Generierung sendet nur die Frage und ausgewählte Quellchunks. Gelerntes Reranking sendet seine Kandidaten. Entfernte URLs müssen HTTPS verwenden; HTTP ist nur für Loopback erlaubt. Weiterleitungen von Modell-APIs werden zurückgewiesen. Loopbackanfragen verwenden keinen Proxy. Andere Anfragen können HTTP-, HTTPS- oder SOCKS-Proxys sowie Proxyumgebungen verwenden. Wiederholungen sind begrenzt und decken nur vorübergehende Verbindungs- oder Lesefehler, HTTP 429 und ausgewählte 5xx ab. Wiederholungen können zu mehrfacher Abrechnung führen. TLS-Prüfung wird nicht deaktiviert. API-Schlüssel werden nur über konfigurierte Umgebungsvariablennamen referenziert und nicht in TOML, URLs oder Befehlsargumente geschrieben. MCP-Werkzeugparameter können weder Anbieter-URL noch Zugangsdaten oder Proxy auswählen.

Gerätespezifische Tresore weisen vor der Inferenz Modellschritte an Anbieter außerhalb von Loopback zurück. Lokale Inferenz und ausdrücklich konfigurierte Loopbackdienste bleiben verfügbar.

Retrieve, RagIndex, RagStatus und RagAsk bewahren Tresorautorisierung und MCP-Umfang. IPC führt Modellarbeit außerhalb des Dienstmutex aus und prüft Entsperrgeneration, Berechtigung, Zugriffsrechte und Quellrevisionsstempel vor und nach externer Arbeit sowie vor Auslieferung erneut. Signierte Absichten gehen Inferenz oder Export voraus. Das Audit erfasst Erfolg oder Fehler und die ausgelieferten Quell-IDs, aber keine Prompts oder Schlüssel. Generierung behandelt Quelltext als nicht vertrauenswürdige Daten und besitzt keine Anwendungswerkzeuge. Das Modell muss strukturierte Antworten und Quellenverweise liefern. Nicht vorhandene Referenz-IDs werden zurückgewiesen. Ohne Belege wird keine Generierung aufgerufen und das Ergebnis als insufficient_evidence markiert. Die Referenzprüfung prüft nur deren Existenz, beweist keine faktische Richtigkeit des generierten Texts und beseitigt keine Prompt-Injection in nicht vertrauenswürdigem Quelltext.

Sperren, abgelaufene oder widerrufene Berechtigungen sowie Änderungen des Quellenzustands unterdrücken verspätete Ergebnisse und verhindern Folgeschritte. Bereits gestartete entfernte Anfragen oder Inferenz können zu Ende laufen; bereits gesendeter Remote-Text lässt sich nicht zurückrufen.

Die mobile FFI erhält verbesserte lexikalische Suche und unterstützt BM25-retrieve. Modellkonfiguration und Modellinferenzoberfläche wurden Flutter nicht hinzugefügt. Modellgestützte Operationen verwenden den konfigurierten Desktopdaemon.

Cloudobjektsynchronisierung

Die Desktop-CLI verwendet PKCE, Loopbackcallbacks und feste Anbieterendpunkte für Browser-OAuth. CloudBegin erstellt unter sudo ein ablaufendes Ticket, das an Aufrufer, Anbieter und Client gebunden ist. Netzwerkanfragen laufen außerhalb des Daemons. CloudComplete prüft Ticket und aktuelle Berechtigung vor dem Commit. Sperren, Abmelden und Neustart invalidieren offene Tickets, damit verspätete Ergebnisse keine Anmeldung wiederherstellen.

State.cloud_accounts speichert Token lokal verschlüsselt. Status liefert nur Kontometadaten. Sicherungen, Kopplung, Tresorsynchronisierung und MCP enthalten keine Token. Anmeldung begründet keine Tresormitgliedschaft. Pro Anbieter verbindet jedes Gerät ein Konto; erneute Anmeldung ersetzt dessen Konto erst nach erfolgreicher neuer Autorisierung.

State.cloud_sync speichert einen persistenten Postausgang und Posteingangsbestätigungen in demselben verschlüsselten Zustand. CloudSyncEnqueue schreibt vor jeglichem Transport-I/O die exakten serialisierten Umschlagbytes und signierten Deskriptoren. Die Objekt-ID ist deren SHA-256; Wiederholungen verwenden dieselbe ID. CloudSyncWork liefert Chiffretext und Listencursor, keine OAuth-Token. sync::execute führt begrenzte Uploads, Downloads und Auflistungen ohne gehaltenen Dienstmutex aus. CloudSyncAck prüft die prozesslokale Sitzungsgeneration und schreibt anschließend Uploadmarkierungen, entdeckte IDs, heruntergeladene Bytes und Tresorzusammenführung gemeinsam fest. Kommt ein Deskriptor vor dem Objekt an, bleibt er ausstehend. Sperren, Entsperren und Abmelden erhöhen die Sitzungsgeneration, sodass verspätete Bestätigungen nicht importieren können.

memories cloud sync lässt den Daemon Token aktualisieren und über OneDrive- oder Google-Drive-Anwendungsordner hoch- und herunterladen. Dieses HTTP läuft außerhalb der Schreibsperre. Token werden niemals über IPC zurückgegeben. Tests verwenden MemoryTransport und Loopback-Graph/Drive-Fixtures. Abgeschlossene Warteschlangennutzlasten werden zu Hashbestätigungen und Veröffentlichungsmarkierungen pro Anbieter und Empfänger verdichtet. Bestätigungen bleiben lokal und löschen keine Cloudhistorie. Fehlende Objekte werden mit persistentem exponentiellem Abstand erneut versucht. Die Kapazität ausstehender Arbeit übt Gegendruck auf Auflistung aus. Anbieterworker arbeiten seriell pro Konto und weisen Aktualisierungs- oder Importergebnisse ungültiger Sitzungen zurück.

CLI-Autorisierung und cloud sync sind somit implementiert und Anbietertransporte mit lokalen Fixtures getestet. Zustimmung, Aktualisierung, Zusammenführung zweier Geräte, Offlinewiederholungen und Widerruf bei echten OneDrive- oder Google-Drive-Konten wurden noch nicht als validiertes Verhalten ausgeliefert. Mobile Anmelde- und Synchronisierungsbedienelemente verwenden AppAuth und gemeinsame Rust-Worker; echte Zustimmung und Plattformvalidierung bleiben Freigabebedingungen. Mobile Hintergrundsynchronisierung ist nicht aktiviert.

Widerruf verwirft eingereihte Cloudexporte und invalidiert bereits erfasste Arbeit vor der nächsten Objektoperation. Bereits gestartete Netzwerkanfragen können nicht zurückgerufen werden.

Ausdrückliche Gerätesynchronisierung ist ein anderer Pfad. sync export und sync import tauschen vollständige authentifizierte Umschläge aus. Online-sync send und sync receive geben dieselbe Paketart an das zustandslose Relay weiter. Erfolgreiches Senden bedeutet nur, dass das Relay das Paket erhalten hat. Unbekannte Schreibvorgänge alter Epochen werden quarantänisiert und können erst nach lokaler Prüfung mit sync reapply neu signiert werden. Berechtigungsforks erfordern, dass eine Person, die auf beiden Zweigen Owner ist, den ausgewählten Kopf und die gesamte verworfene Richtlinienkette signiert. Unvereinbare Eigentumsübertragungen bleiben blockiert.

Desktopstatusgrenzen

Request::DesktopStatus liefert Initialisierungs- und Sperrstatus, Speicher- und Verbindungszahlen, konfigurierte Anbieterarten und Synchronisierungswarteschlangenzahlen. Es läuft vor dem Dispatch entsperrter Operationen, klont oder schreibt keinen verschlüsselten Zustand, berührt weder Inaktivitäts- noch Rechteerhöhungstimer und legt keine Identifikatoren, Kontozusammenfassungen, Inhalte oder Zugangsdaten offen. Gesperrte Antworten enthalten diese Details nicht. Die MCP-Allowlist weist diese Anfrage zurück.

Die CLI-Bibliothek trägt das lokale Dashboard sowie Windows- und macOS-Trays. memories tray und das eigenständige memories-tray verwenden native Ereignisschleifen auf dem Hauptthread. HTTP-Dienst und begrenzte Statusproben laufen auf separaten Threads, sodass ein beschäftigter Daemon Tray oder Browser nicht blockiert. Proben rufen die CLI desselben Verzeichnisses über gewöhnliche betriebssystemauthentifizierte IPC auf, haben Fristen und räumen Unterprozesse auf. Die Probefrist für Windows-Pipe-Lesen beträgt drei Sekunden. Fehlgeschlagene Proben löschen Details; Sperren verbirgt sie bei der nächsten Abfrage. Polling erneuert weder Entsperrinaktivitätszeit noch erhöhte Rechte.

Die HTTP-Oberfläche stellt nur eingebettete Ressourcen und eine feste Statusprojektion bereit und kann keine beliebigen Dienstanfragen verteilen. Sie lauscht ausschließlich auf 127.0.0.1. Der einzige Datenendpunkt ist GET /api/status, geschützt durch ein pro Prozess zufällig erzeugtes 256-Bit-Token. Der Starter setzt das Token in das URL-Fragment. Die Seite entfernt es aus der Adressleiste, bewahrt es nur im Sitzungsspeicher des Tabs auf und sendet es im Authorization-Header. Die vollständige Start-URL ist eine Dashboardfähigkeit und darf nicht geteilt werden. Unerwartete Hosts, fremde Origins und websiteübergreifende Fetch-Metadaten werden zurückgewiesen. Es gibt weder CORS, Drittanbieterressourcen, Frame-Einbettung noch Änderungsrouten. Der Browser erhält eine typisierte Statusprojektion, keine generische IPC-Brücke, Zugangsdaten, Erinnerungstexte, Kontonamen, Pfade oder Berechtigungstoken.

Das Tray kann den lokalen Daemon über eine ausdrückliche Menüaktion starten. Das Schließen von Tray oder Dashboard stoppt deren HTTP-Listener und Überwachung, stoppt oder entsperrt aber keinen unabhängig laufenden Daemon. Authentifizierung bleibt in der CLI. Bösartige Programme desselben Betriebssystemkontos bleiben innerhalb der bestehenden lokalen Vertrauensgrenze.

Linux-Builds enthalten memories webui mit demselben Loopbackdashboard und denselben Tokengrenzen. Die native Tray-Ereignisschleife wird nur unter Windows und macOS kompiliert. Linux hat kein natives Tray.

Lokales TOML enthält nur nicht geheime Speicher-, Relay- und Desktopeinstellungen. Ausdrücklich angegebene fehlende Dateien, unbekannte Schlüssel und ungültige Werte werden vor Öffnen des Speichers zurückgewiesen. Relative Speicherpfade werden relativ zur Konfigurationsdatei aufgelöst. Ein Pfadwechsel wählt einen anderen Speicher und migriert keine Daten. Relay-URLs behalten die bestehenden Remote-TLS-Beschränkungen bei und dürfen keine Zugangsdaten enthalten.