Memories

Repository: https://github.com/mbcc2006/memories. Die CLI heißt memories, der Relay memories-relay und die native Bibliothek memories_ffi.

Clientseitig verwaltete verschlüsselte Erinnerungen, private Dateien und Zugangsdaten mit einer Rust-CLI, einem Android/iOS-Client, einem lokalen MCP-Server und einem WebSocket-Relay, der ausschließlich im Arbeitsspeicher arbeitet.

Entwicklungsversion, Formatversion 1. Dieses Repository enthält ausführbaren Code und Sicherheitsregressionstests. Es wurde keiner unabhängigen kryptografischen Prüfung oder Prüfung der Anwendungssicherheit unterzogen. Informationen zu Garantien, Vertrauensgrenzen und aktuellen Einschränkungen finden Sie in SECURITY.md.

Wie alles zusammenpasst

Im eigenständigen Betrieb hält Memories auf jedem Gerät einen verschlüsselten lokalen Speicher vor. Damit können Sie durchsuchbares Wissen speichern, eine KI-Persona zwischen Clients übertragen oder private Dateien und Geheimnisse durch bewusste Autorisierung verwenden. Cloud-Speicher enthält Chiffretext; der Relay verbindet ausschließlich online befindliche Gegenstellen. Keines von beiden ersetzt einen autorisierten Client.

Die mobile App bietet außerdem die Modi Center (Ihr selbst gehosteter Server) und SaaS (https://memories.ivjn.us). Diese Modi verwenden einen separaten gehosteten Speicher, dessen Betreiber seine Inhalte lesen kann. Durch die Auswahl oder den Wechsel eines Modus wird eine bestehende lokale Bibliothek weder hochgeladen noch verschoben oder zusammengeführt. Siehe mobile Modi.

Memories Web verbindet sich mit Ihrem bestehenden gehosteten Center, damit Sie Erinnerungen, Karten und Dateien im Browser verwalten können. Neue Center-Builds stellen es auch unter /app/ bereit. Informationen zu Zugriffstokens, erlaubten Ursprüngen und unterstützten Vorgängen finden Sie im Leitfaden zum Webclient. Die gehostete SaaS-API ist unter https://memories.ivjn.us verfügbar; verwenden Sie ein für diesen Dienst ausgestelltes Mitgliedstoken.

unlock ermöglicht gewöhnliche autorisierte Arbeit im Speicher. memories sudo fügt eine kurzlebige Sitzung für private Inhalte, Dateien, Zugangsdaten und sensible Verwaltungsaufgaben hinzu; es gewährt keine Administratorrechte des Betriebssystems und umgeht keine Tresorberechtigungen. Eine gewöhnliche, auf einen Tresor begrenzte MCP-Berechtigung ist eine separate, eingeschränkte KI-Fähigkeit, nicht die sudo-Befugnis des Terminals. Unbeaufsichtigter Zugriff ist eine separate, ausdrücklich zu aktivierende, ausschließlich lesende Fähigkeit, die private Inhalte und geheime Werte offenlegen kann.

Hier beginnen

Für die Entwicklung siehe Repository-Richtlinien, Architektur und Validierungsergebnisse.

Vereinfachtes Chinesisch: Produktbeschreibung, Bedienungsanleitung, Technische Dokumentation.

Marketing-Website / Projektvorstellungswebsite: website/, statische Website auf Englisch/Chinesisch mit Anweisungen zur Bereitstellung auf Cloudflare Pages.

Bauen und ausführen

Installieren Sie Rust 1.88 oder neuer und die C-Toolchain der Plattform (SQLite wird aus dem Quellcode kompiliert).

cargo build --workspace --locked
cargo test --workspace --locked
cargo clippy --workspace --all-targets --locked -- -D warnings
cargo install --path crates/cli --locked

Starten Sie memories daemon in einem separaten Terminal. Er bedient ausschließlich den aktuellen Betriebssystembenutzer über eine Named Pipe unter Windows oder einen Unix-Socket unter Linux/macOS. Verwenden Sie mit --home PATH oder MEMORIES_HOME ein dediziertes Datenverzeichnis; standardmäßig wird das Anwendungsdatenverzeichnis des Betriebssystems verwendet. Richten Sie --home nicht auf einen bestehenden allgemein genutzten Ordner: Seine Berechtigungen werden zum Schutz des lokalen Dienstes eingeschränkt.

Lokaler Schnellstart

Wenn memories installiert ist und der Daemon läuft, verwenden Sie ein zweites interaktives Terminal. Für einen neuen eigenständigen Speicher:

memories init --name laptop
memories vault create Personal
memories vault list

Erstellen Sie eine UTF-8-Datei namens notes.md mit einer kurzen Notiz, die „project“ enthält. Ersetzen Sie unten VAULT_ID durch die id, die von vault create oder vault list zurückgegeben wird und führen Sie dann Folgendes aus:

memories memory put VAULT_ID --title "Project notes" --input notes.md
memories memory search VAULT_ID "project"
memories memory grep VAULT_ID 'project|release' -i -n

memory grep gleicht einen regulären Ausdruck mit jeder entschlüsselten Inhaltszeile gewöhnlicher Erinnerungsdokumente im ausgewählten Tresor ab. Es gibt DOCUMENT_ID:LINE aus oder DOCUMENT_ID:LINE_NUMBER:LINE mit -n / --line-number; -i / --ignore-case ignoriert die Groß-/Kleinschreibung. Private Dokumente, widersprüchliche Versionen, Karten, Dateien und Zugangsdaten sind ausgeschlossen, genauso wie private Inhalte bei der gewöhnlichen Suche. Ohne Treffer erfolgt keine Ausgabe.

Ersetzen Sie ASSET_ID durch die id der gespeicherten Notiz. Verwenden Sie für FROM_REVISION das Feld revision, das von history zurückgegeben wird; der Diff vergleicht diese Revision mit dem aktuellen Head:

memories memory read VAULT_ID ASSET_ID
memories memory history VAULT_ID ASSET_ID
memories memory diff VAULT_ID ASSET_ID FROM_REVISION
memories lock
memories unlock

Verwenden Sie bei späteren Besuchen unlock, nicht init. Wenn dies ein neues Gerät ist, das einer bestehenden Identität beitritt, koppeln Sie es, bevor Sie Tresore erstellen. Bei einem benutzerdefinierten Speicher übergeben Sie dem Daemon und jedem Client-Befehl dasselbe --home PATH.

Entdecken Sie Aufgaben mit memories --help und vertiefen Sie sich dann mit memories memory --help oder memories memory put --help. Fügen Sie für chinesische Hilfe --lang zh hinzu, zum Beispiel memories --lang zh memory put --help. Die Hilfe benötigt keinen Daemon.

Passwörter werden ohne Echo aus einem interaktiven Terminal gelesen. Es gibt weder ein Passwortargument noch eine Passwort-Umgebungsvariable. Lokale und Backup-Passwörter unterliegen keiner Längenbeschränkung auf Anwendungsebene, einschließlich leerer Eingaben; Passwortbestätigung und Authentifizierung gelten weiterhin. Befehle geben versioniertes JSON aus; fehlgeschlagene Befehle liefern einen Exit-Status ungleich null. Öffentliche Geräteschlüssel und Fingerabdrücke sind absichtlich sichtbar; private Schlüssel und Zugangsdatenwerte werden von gewöhnlichen Befehlen nicht ausgegeben. Bewusstes unbeaufsichtigtes Lesen von Zugangsdaten ist eine in Unbeaufsichtigte CLI/MCP beschriebene Ausnahme.

Entfernter Daemon (HTTP/WebSocket / Relay-RPC)

Optionales tokenauthentifiziertes HTTP/WebSocket-Listening und WSS-Relay-RPC übertragen dasselbe gerahmte service::Request-Protokoll wie lokales IPC (auf dem Desktop nach unlock/sudo mit vollem Funktionsumfang; die mobile Freigabe behält die FFI-Sperrliste bei). Verwenden Sie memories daemon --listen http://127.0.0.1:7900 (optional --tls-cert / --tls-key für HTTPS/WSS). RPC führt Vorgänge auf dem Speicher des Hosts aus; es synchronisiert keine lokale Replik. Informationen zu Listen-/Client-Flags, verbleibenden Risiken und mobiler Freigabe finden Sie unter entfernter Daemon.

Optionale Autorisierungs-Center können die lokale Selbstinitialisierung verbieten und Registrierungs-/MCP-Berechtigungstickets an Endpunkte verteilen. memories-center --data DIR betreibt zusätzlich einen vollständigen gehosteten Tresor: Daemons mit einem Center-Eintrag mode = "saas" werden von ihm gesteuert, der Betreiber kann ihn aus der Ferne entsperren, und Mitglieder werden im Center verwaltet.

Autorisierungskette

Tresorrollen sind Owner, Admin, Editor und Reader. Nur Admin oder Owner dürfen Berechtigungen ausstellen oder delegieren; die Ausstellung benötigt einen entsperrten Tresor, aber keine Terminal-Rechteerhöhung, während die Genehmigung einer Rollenanfrage eine Rechteerhöhung benötigt. Eine Berechtigung wird durch die Rolle des Ausstellers (und jede übergeordnete Berechtigung) begrenzt, der Empfänger darf keine höhere Rolle besitzen, und center-admin kann kein Empfänger sein. Die Delegationstiefe beträgt höchstens 2. Ein ausgelassener Umfang bedeutet read, nicht allow_all. Berechtigungsanfragen gehen an alle geeigneten Genehmiger oder an bestimmte --approver-Mitglieder; niemand entscheidet über die eigene Anfrage. Die Genehmigung gibt kein Token zurück: Der Antragsteller holt es einmalig ab (memories request claim, memories center request claim, MCP request_claim oder POST /v1/requests/{id}/claim). Grenzen: 20 ausstehende Anfragen pro Antragsteller und Tresor, 200 pro Tresor (HTTP 429 im Center), 7 Tage TTL für ausstehende Anfragen, 30 Tage Aufbewahrung und höchstens 10,000 aktive Berechtigungen sowohl im Daemon als auch in einem gehosteten Center. memories access list VAULT zeigt Mitglieder nach Stufe, Geräte, ausstehende und genehmigte, noch nicht abgeholte Anfragen; memories grant list VAULT listet Berechtigungen auf. Das Entfernen eines Mitglieds widerruft kaskadierend seine Berechtigungen (Generation pro Mitglied); Berechtigungen werden nur als Hashes dauerhaft gespeichert, und das Auditprotokoll ist durch Hashes verkettet (Center: DIR/audit.jsonl). Siehe Autorisierung.

Persona-Chat (memories persona chat send|list|history|mark-read) löst chat_message-Automatisierungshooks aus; eingehende Automatisierungs-Webhooks sind außerdem über memories-relay unter POST /v1/persona/{room}/{vault}/{persona}/automation/trigger erreichbar (siehe Persona, entfernter Daemon).

Linux-Build und Paket

Installieren Sie unter Debian/Ubuntu (einschließlich Ubuntu in WSL2) Rust 1.88+ und die nativen Build-Abhängigkeiten:

sudo apt-get update
sudo apt-get install -y build-essential pkg-config libssl-dev python3 git
bash scripts/build-linux.sh
# Optional development build:
bash scripts/build-linux.sh --debug

Das Skript baut den Rust-Workspace für das GNU-Ziel des Hosts: x86_64 oder aarch64. Release-Ausgaben liegen in target/<host-target>/release/ (oder im konfigurierten Cargo-Zielverzeichnis); Debug-Ausgaben verwenden debug/. Ein Flutter-SDK ist nicht erforderlich. Linux unterstützt CLI, Daemon, Relay, FFI-Bibliothek und memories webui; das native Tray ist derzeit nur unter Windows/macOS verfügbar.

Erstellen Sie aus einem sauberen, committeten Checkout ein Linux-Release-Archiv:

bash scripts/package-linux.sh

Dadurch werden die Release-Binärdateien neu gebaut und eine .tar.gz, BUILD-INFO.json, SHA256SUMS und eine Beispielkonfiguration nach dist/vVERSION-linux-ARCH/ geschrieben. Das Archiv enthält memories, memories-relay, libmemories_ffi.so, den C-Header, Dokumentation und Lizenzen, wobei Ausführungsberechtigungen erhalten bleiben. Bestehende Ausgabeverzeichnisse werden nicht überschrieben. Der manuelle Workflow Desktop-Pakete bauen baut ebenfalls ein Linux-x86_64-Paket und lädt es hoch.

Dies sind native GNU/Linux-Builds, keine statischen oder querkompilierten Binärdateien. Verwenden Sie eine kompatible glibc/OpenSSL-Laufzeit; bauen Sie auf der ältesten Distribution, die Sie unterstützen möchten. ca-certificates wird für System-TLS benötigt und xdg-utils zum Öffnen des Dashboards in einem Desktop-Browser. Das Kopieren von Zugangsdaten in die Zwischenablage benötigt zusätzlich wl-clipboard (Wayland) oder xclip (X11). Modellgewichte werden separat mit memories rag model-install installiert.

Konfiguration

Führen Sie memories config init aus, um eine TOML-Konfiguration zu erstellen, memories config path, um sie zu finden, und memories config show, um die wirksamen Einstellungen zu prüfen. Die Release-Version enthält memories.example.toml mit Optionen für Speicherverzeichnis, Relay und Desktop. Wählen Sie mit --config PATH oder MEMORIES_CONFIG eine andere Datei. CLI-Optionen haben Vorrang vor Umgebungsvariablen, diese vor der Konfiguration und diese vor Standardwerten. Siehe Konfigurationsleitfaden.

Desktop-Tray und Status-Dashboard

Doppelklicken Sie unter Windows im entpackten Release-Verzeichnis auf memories-tray.exe. Öffnen Sie unter macOS die mitgelieferte Memories.app oder verwenden Sie die Befehlszeile:

memories tray
memories webui

Das Tray/die Menüleiste zeigt den Daemon- und Tresorstatus, öffnet die lokale WebUI und kann den Daemon starten. Das Dashboard meldet Sperrstatus, Bibliotheksanzahl, Verbindungsanzahlen und Cloud-Synchronisierungswarteschlangen, ohne gespeicherte Inhalte anzuzeigen. --home wählt denselben Speicher wie die CLI; --no-open hält den Browser beim Start geschlossen. Initialisieren/entsperren Sie wie gewohnt über die CLI. Verhalten und Paketierung beschreibt der Desktop-Leitfaden.

Sprachen

Der mobile Client und die CLI unterstützen Englisch (en), vereinfachtes Chinesisch (zh), Japanisch (ja), Deutsch (de) und Französisch (fr). Das mobile Sprachmenü ist auf dem Sperrbildschirm und in der Bibliothek verfügbar. Standardmäßig folgt es dem System und behält eine manuelle Auswahl über Neustarts hinweg bei.

memories --lang zh --help
memories cloud login --lang ja --help
memories --lang de status
memories language zh       # Remember this language
memories language          # Show saved and effective language
memories language system   # Follow the system again

Die CLI-Sprachauswahl verwendet --lang, dann MEMORIES_LANG, dann eine gespeicherte Sprachpräferenz und dann den ersten nicht leeren Wert von LC_ALL, LC_MESSAGES oder LANG. Die Präferenz wird pro --home / MEMORIES_HOME gespeichert und funktioniert ohne Daemon. Unter Windows verwendet sie außerdem die Betriebssystemsprache, wenn keine dieser Variablen gesetzt ist. Nicht unterstützte Gebietsschemata fallen auf Englisch zurück; Umgebungswerte wie fr_FR.UTF-8 und zh-CN werden akzeptiert. Befehle, Optionsnamen, JSON-Felder, Fehlercodes und die Bestätigungswörter USE und APPROVE bleiben unverändert. Benutzerinhalte werden nicht übersetzt. Technische Diagnosen ohne Übersetzung behalten ihre ursprünglichen Details mit einer lokalisierten Fehlerzusammenfassung. Zur Pflege siehe Lokalisierungsleitfaden.

Kurze IDs

CLI-, MCP- und mobile Anfragen verwenden einfache kurze hexadezimale IDs, normalerweise mit sechs Zeichen (zum Beispiel 0b0668). IDs haben keine Typ- oder Klassifikationsbedeutung und besitzen weder Präfix noch Unterstrich. Verwenden Sie die von vault list, card list, card search oder dem Verlauf zurückgegebenen IDs direkt im entsprechenden Befehl. Lange UUIDs, vollständige Revisionshashes und IDs mit Präfix werden abgelehnt; es gibt keine Ausgabeoption für lange IDs.

Bestehende IDs mit acht Zeichen bleiben gültig. Kollidierende Präfixe werden automatisch in Schritten von zwei Zeichen auf bis zu 16 Zeichen verlängert; mehrdeutige Eingaben werden abgelehnt. Geräteschlüssel oder Sicherheitsfingerabdrücke werden dadurch nicht verkürzt.

memories card list eb7abf
memories card search eb7abf "claude relay"
memories card read eb7abf 0b0668

IDs werden im Geltungsbereich jedes Befehlsarguments aufgelöst. Bei einer Kollision wird die zurückgegebene ID um zwei Zeichen verlängert, bis zu 16; mehrdeutige Eingaben schlagen fehl, statt ein Objekt auszuwählen. Listen oder suchen Sie nach einer Kollision erneut. Gelöschte Assets bleiben im Kollisionsindex. Kurze IDs sind Referenzen, keine Autorisierung: unlock, sudo, Tresorberechtigungen und MCP-Berechtigungen gelten weiterhin.

Signierte Speicherdatensätze behalten ohne Migration ihre ursprünglichen Kennungen. Zertifikate, öffentliche Schlüssel, Verifizierungsfingerabdrücke, Auditdatensätze und verschlüsselte Transporthüllen werden weder verkürzt noch umgeschrieben.

Retrieval und RAG

Die gewöhnliche Suche zerlegt jetzt Chinesisch in Tokens und unterstützt mehrere Schlüsselwörter. Ihr BM25-Index wird im Arbeitsspeicher zwischengespeichert, bei Inhalts-/Richtlinienänderungen invalidiert und beim Sperren gelöscht. Erweitertes Retrieval ergänzt Abschnittsoffsets, Vektorbewertungen, hybride Rangfusion, leichtgewichtiges Reranking und optional erlerntes Reranking über eine konfigurierte URL. Zugangsdaten und private Inhalte bleiben ausgeschlossen.

memories rag ingest VAULT_ID notes.md --title "Research notes"
memories rag search VAULT_ID "Chinese and English keywords" --mode bm25
memories rag model-install
memories rag index VAULT_ID
memories rag search VAULT_ID "What does this document mean?" --mode hybrid
memories rag ask VAULT_ID "Summarize the evidence"

Die eingebaute CPU-Inferenz-Engine führt EmbeddingGemma im Memories-Prozess aus; Ollama oder eine andere Inferenzanwendung ist nicht erforderlich. Modelldateien sind öffentliche Daten, die einmalig mit model-install installiert oder in rag.local_model_dir bereitgestellt werden. Gemini Embedding ist eine separate Online-API. Konfigurieren Sie vom Kunden ausgewählte URLs für entfernte Embeddings, Generierung und optionales Reranking. HTTP(S)/SOCKS-Proxys, Zeitlimits und begrenzte Wiederholungsversuche sind konfigurierbar. Siehe RAG-Leitfaden.

Private Dateien und Zugangsdaten

sudo ist eine interne Autorisierungssitzung, kein Administratorzugriff auf das Betriebssystem. Sie verwendet dasselbe lokale Passwort. Die Rechteerhöhung dauert höchstens 15 Minuten, läuft nach fünf Minuten Inaktivität ab und ist auf den Elternprozess des Terminals begrenzt. Sperren oder Neustarten des Dienstes löscht sie. Gewöhnliches Entsperren läuft nach 15 Minuten Inaktivität ab.

memories sudo
memories file import VAULT_ID document.pdf
memories file export VAULT_ID FILE_ID exported.pdf
memories file exec VAULT_ID FILE_ID -- caddy run --config "{file}" --adapter caddyfile
memories credential add VAULT_ID "API token"
memories credential import VAULT_ID "SSH identity" existing-private-key
memories credential generate VAULT_ID "laptop ssh"
memories credential generate VAULT_ID "laptop ssh" --algorithm rsa --bits 4096
memories credential generate VAULT_ID "db ca" --kind tls-ca --algorithm rsa --subject memories-ca
memories credential generate VAULT_ID "db server" --kind tls --ca CA_ID --algorithm rsa --name db.example.test
memories credential public VAULT_ID KEY_ID
memories run --vault VAULT_ID --credential CREDENTIAL_ID /absolute/program/path
memories run --vault VAULT_ID --credential CREDENTIAL_ID --env API_TOKEN /absolute/program/path
memories credential bind gh --vault VAULT_ID --credential CREDENTIAL_ID --env GH_TOKEN
memories credential bindings
memories credential unbind gh
memories run --binding gh -- pr list --state open
memories hook install --commands gh
memories hook uninstall
memories credential allow-host VAULT_ID CREDENTIAL_ID api.example.com
memories credential http VAULT_ID CREDENTIAL_ID https://api.example.com/status
memories remote probe example.test --port 22
memories remote open ssh --vault VAULT_ID --credential KEY_ID --host example.test --user alice --host-key HOST_KEY
memories remote open ssh --vault VAULT_ID --credential KEY_ID --certificate CERT_ID --host example.test --user alice --host-key HOST_KEY
memories remote open mysql --vault VAULT_ID --credential CREDENTIAL_ID --host db.example.test --user app --database appdb
memories remote open redis --vault VAULT_ID --credential CREDENTIAL_ID --host redis.example.test --user default
memories remote open postgres --vault VAULT_ID --credential CREDENTIAL_ID --host db.example.test --user app --database appdb
memories remote open postgres --vault VAULT_ID --credential CREDENTIAL_ID --tls-ca CA_ID --host db.example.test --user app --database appdb
memories remote open mysql --vault VAULT_ID --credential CREDENTIAL_ID --host db.example.test --user app --database appdb --no-tls
memories remote run SESSION_ID -- uname -a
memories remote run SESSION_ID --op query -- SELECT 1
memories remote propose SESSION_ID -- uname -a
memories remote approve TICKET_ID
memories remote exec TICKET_ID
memories remote close SESSION_ID
memories proxy start ssh --vault VAULT_ID --credential KEY_ID --host example.test --user alice --host-key HOST_KEY
memories proxy start postgres --vault VAULT_ID --credential CREDENTIAL_ID --host db.example.test --user app --database appdb
memories proxy list
memories proxy stop PROXY_ID

Ein Programm mit einer gespeicherten Konfigurationsdatei ausführen

memories file exec VAULT_ID FILE_ID -- PROGRAM ARGS... liest eine autorisierte Datei und ersetzt jedes {file} in den Programmargumenten durch einen absoluten temporären Dateipfad. Verwenden Sie --revision REVISION vor --, um eine historische Version auszuwählen. Es benötigt dieselbe Entsperrung, denselben Tresorzugriff und dasselbe Terminal-memories sudo wie der Dateiexport. Ein entfernter/gehosteter Daemon kann die Datei bereitstellen; das Programm läuft immer auf dem CLI-Rechner unter dem Konto des CLI-Benutzers.

memories sudo
memories file import VAULT_ID ./Caddyfile
# Use the returned file ID. Caddy 2 Caddyfile syntax needs an explicit adapter.
memories file exec VAULT_ID FILE_ID -- caddy run --config "{file}" --adapter caddyfile

Der Kindprozess erbt Arbeitsverzeichnis, Umgebung und Standardstreams; sein Exit-Code wird ohne JSON-Erfolgshülle zurückgegeben. Es wird keine Shell eingefügt und es gibt kein Ausführungszeitlimit von fünf Minuten. Führen Sie das Programm im Vordergrund aus. Temporäres Verzeichnis und Datei sind nur für den Eigentümer zugänglich (Unix 0700/0600; Windows-Benutzer-ACL) und werden entfernt, nachdem der Kindprozess beendet wurde oder nicht starten konnte. Ctrl+C/Ctrl+Break unter Windows und SIGINT/SIGTERM/SIGHUP unter Unix lösen das Herunterfahren aus; vor dem Beenden des direkten Kindprozesses und dem Aufräumen werden zehn Sekunden eingeräumt. Unix-Signale werden an den Kindprozess weitergeleitet; Windows-Konsolenereignisse erreichen Prozesse, die dieselbe Konsole teilen.

Dies exportiert Klartext für die Lebensdauer des Kindprozesses. Vertrauen Sie dem Programm und seinen Plugins: Seine Ausgabe wird nicht bereinigt. Sperren/Widerrufen kann die übergebene Kopie nicht zurückholen oder den Kindprozess stoppen. Erzwungenes Beenden von Memories, Stromausfall oder das Schließen einer Windows-Konsole kann die temporäre Datei zurücklassen; Löschen ist kein sicheres Vernichten. Abgekoppelte Nachfolgeprozesse werden nicht verwaltet. Jeder Aufruf verwendet einen festen Dateischnappschuss namens config; es erfolgen keine automatischen Aktualisierungen, Neuladungen, Vorlagenerweiterungen oder Importe zugehöriger Dateien. Relative Pfade folgen den Regeln des Zielprogramms; verwenden Sie daher absolute Pfade für externe Includes/Zertifikate und geben Sie das Format explizit an, wenn ein Programm es sonst aus dem Dateinamen ableitet.

Zugangsdaten in Prozesse injizieren

Die Prozessinjektion von Zugangsdaten mit memories run verwendet stdin; --env erlaubt bewusst eine Umgebungsvariable. Der SHA-256-Fingerabdruck des Programms muss bestätigt oder über --approve-digest angegeben werden. Beide Ausgabestreams des Kindprozesses werden unterdrückt. Das empfangende Programm kann die Zugangsdaten dennoch kopieren oder übertragen und muss vertrauenswürdig sein. Eine Ausführungsbindung bindet einen Zugangsdaten-Eintrag an einen Programmfingerabdruck, sodass ein Coding-Agent ihn ohne die sudo-Sitzung Ihres Terminals verwenden kann. credential bind gh (sudo, eingegebenes USE) löst gh über PATH auf, erfasst seinen SHA-256 und speichert die Bindung ausschließlich im verschlüsselten Zustand dieses Geräts; sie wird nie synchronisiert und bei der Wiederherstellung gelöscht. Sie läuft nach --hours ab (standardmäßig 8, höchstens 720) und funktioniert nur, solange die Bibliothek entsperrt ist. run --binding gh -- ARGS führt das Programm dann im aktuellen Verzeichnis mit den Zugangsdaten in der gewählten Umgebungsvariable aus, spiegelt seine Ausgabe, wobei jedes Vorkommen des Zugangsdatenwerts durch [REDACTED] ersetzt wird (--suppress-output verwirft die Ausgabe stattdessen), und endet mit dem Exit-Code des Programms. --deny WORDS lehnt Befehle ab, deren Nicht-Flag-Argumente diese Wörter in der angegebenen Reihenfolge enthalten; --ask WORDS lässt den Hook vor ihrer Ausführung nachfragen. Für gh werden auth, alias und extension (auch extensions und ext) verweigert und bei pr merge, repo delete und release delete wird nachgefragt, sofern nicht --no-default-rules gesetzt ist. Regeln gleichen die Wörter so ab, wie sie eingegeben werden; zuvor mit gh alias set definierte Aliasse werden nicht aufgelöst. Bis die Bindung abläuft, kann jedes unter Ihrem Benutzerkonto laufende Programm das gebundene Programm mit den Zugangsdaten ausführen; es kann die Zugangsdaten nicht über Memories lesen. Das Programm selbst, seine Erweiterungen und seine Kindprozesse können dies jedoch, also binden Sie nur Programme, denen Sie vertrauen. Eine Bindung ohne --credential und --env wendet nur die Regeln an.

hook install --commands gh fügt den Benutzereinstellungen von Claude Code einen PreToolUse-Hook hinzu (nach Anzeige des Eintrags und Abfrage von APPROVE). Wenn Claude Code gh ... in Bash oder PowerShell ausführen will, ersetzt der Hook dieses Befehlswort durch memories run --binding gh -- und lässt den Rest der Befehlszeile unverändert. Die Ausführung von gh innerhalb von $( ), Backticks, sh -c, xargs und ähnlichen Wrappern wird mit einer Begründung verweigert; Heredoc-Inhalte und als Argumente verwendete Substitutionen (etwa --body "$(cat <<'EOF' ... EOF)") sind zulässig. Eingaben aus Pipes oder Umleitungen werden mit --stdin weitergeleitet (bis zu 16 MiB). Das Programm läuft in der Umgebung des Daemons, daher wird ein Präfix NAME=value gh ... abgelehnt; verwenden Sie stattdessen die Flags des Programms. Argumente, die die Shell zur Laufzeit expandiert ($var, Globs), können nicht anhand der Regeln geprüft werden, daher fragt der Hook vor ihrer Ausführung nach. Der Hook genehmigt einen Befehl nur dann unmittelbar, wenn er ausschließlich aus gebundenen Ausführungen besteht; führt er zusätzlich andere Programme aus oder schreibt Dateien, gilt die übliche Bestätigung von Claude Code. Die Anzahl der Worker, die weiterhin aus Pipes lesen, welche von verbleibenden Nachfolgeprozessen eines gebundenen Programms offen gehalten werden, ist begrenzt; weitere gebundene Ausführungen werden verweigert, solange zu viele bestehen. Die eigenen Verweigerungs- und Nachfrageregeln von Claude Code gelten weiterhin, sehen aber möglicherweise den umgeschriebenen Befehl; halten Sie sensible Unterbefehle daher in den Regeln der Bindung fest. Gebundene Programme laufen außerhalb der Dienstsperre, sodass ein langes gh run watch andere Clients nicht blockiert; das Fünf-Minuten-Limit gilt weiterhin.

Die HTTPS-Schnittstelle sendet ein Bearer-Token nur über HTTPS/443 an einen konfigurierten Host, folgt keinen Weiterleitungen, übernimmt keine Proxy-Einstellungen und gibt nur den Statuscode zurück, um die Spiegelung von Zugangsdaten in einem Antwortinhalt zu vermeiden. Vom Daemon verwaltete SSH-, FTP-, TCP-, MySQL-, Redis- und PostgreSQL-Sitzungen halten Geheimnisse im Dienst. Jede Anweisung wird vorgeschlagen, mit APPROVE genehmigt und dann einmalig in der aktiven Sitzung ausgeführt. remote run führt alle drei Schritte aus; Skripte können sie mit remote propose (reiht ein Ticket ein), remote approve (sudo, einmalige Nutzung) und remote exec (derselbe Aufrufer mit erhöhten Rechten) aufteilen. SSH akzeptiert Passwort-Zugangsdaten, einen importierten privaten OpenSSH-Schlüssel (credential import) oder einen im Tresor erzeugten Schlüssel (credential generate). Die Erzeugung gibt den privaten Schlüssel niemals aus; credential public liefert nur den öffentlichen SSH-Schlüssel oder das TLS-Zertifikat. Optional können Sie einen zweiten Zugangsdaten-Eintrag mit einem OpenSSH-Zertifikat anhängen (--certificate). SSH benötigt außerdem einen fest hinterlegten Hostschlüssel-Fingerabdruck aus remote probe. MySQL-, Redis- und PostgreSQL-Sitzungen verwenden standardmäßig TLS mit Hostnamenprüfung. Redis und PostgreSQL verwenden rustls mit webpki-Stammzertifikaten; MySQL verwendet die TLS-Bibliothek der Plattform. --tls-ca ergänzt eine gespeicherte PEM-CA aus einem Tresor-Zugangsdaten-Eintrag; dies bleibt vom globalen --ca-file PATH (MEMORIES_CA_FILE) getrennt, das ein PEM-CA-Bundle aus dem Dateisystem für Daemon-/Relay-WSS sowie ausgehende HTTPS-/Datenbank-Clients ergänzt. Setzen Sie diese Optionen für den Prozess, der die Verbindung herstellt (starten Sie den Daemon damit für vom Daemon verwaltete Upstream-Vorgänge). Das globale --insecure überspringt Zertifikats- und Hostnamenprüfung, ohne TLS zu deaktivieren: gefährlich, nur für Entwicklung/selbst signierte Zertifikate; bevorzugen Sie --ca-file. Serverseitiges --tls-cert / --tls-key bleibt unverändert. Siehe TLS-Beispiele für Clients. Übergeben Sie --no-tls, um Datenbank-TLS zu deaktivieren. MCP kann diesen Weg nicht verwenden. Dateivorgänge verwenden FTP; genehmigte SSH-Sitzungen akzeptieren ausschließlich exec.

Geheimnisse in Wiki-Dokumenten schützen

Öffnen Sie in der App das Menü einer Erinnerung/Karte und wählen Sie Geheimnis im Dokument schützen (Chinesisch: 替换资料中的密钥). Benennen Sie die Referenz (zum Beispiel API_KEY), geben Sie dann das exakte Geheimnis über die verdeckte Eingabe ein und autorisieren Sie den Vorgang. Alle exakten Treffer im Inhalt dieses Dokuments werden zu {{secret:API_KEY}}; der Wert wird als verschlüsselter Zugangsdaten-Eintrag gespeichert. Gewöhnliche Lesevorgänge, Suche und MCP sehen nur die Referenz.

Wählen Sie Geheimnis kopieren (复制密钥) im Menü eines Dokuments oder Zugangsdaten-Eintrags. Wählen Sie bei einem Dokument mit mehreren Referenzen zuerst die Bezeichnung. Bestätigen und autorisieren Sie den Vorgang, um den aktuellen Wert in die Systemzwischenablage zu kopieren, ohne ihn anzuzeigen.

Die CLI bietet dieselben Vorgänge (verwenden Sie kurze IDs aus list oder search):

memories sudo
memories memory protect-secret VAULT_ID DOCUMENT_ID API_KEY
# For a knowledge card, use: memories card protect-secret VAULT_ID CARD_ID API_KEY
memories credential copy VAULT_ID DOCUMENT_ID --label API_KEY
memories credential copy VAULT_ID CREDENTIAL_ID

Der Ersetzungsbefehl fragt nach dem Geheimnis; geben Sie Geheimnisse nicht in Argumenten oder Referenznamen an. Bezeichnungen akzeptieren 1-64 ASCII-Buchstaben, Ziffern, Unterstriche oder Bindestriche und dürfen in diesem Dokument noch nicht verwendet werden. Das Kopieren einer Dokumentreferenz benötigt --label, selbst bei nur einer Referenz. Kopieren liefert ausschließlich den Kopierstatus ("copied": true). Windows verwendet die native Zwischenablage, macOS pbcopy, und Linux benötigt wl-copy (Wayland) oder xclip (X11). Geschützte account/token/env/OTP-Karten können ebenfalls direkt kopiert werden; OTP-Kopien liefern den Startwert, keinen Einmalcode.

Die Ersetzung betrifft nur den aktuellen Dokumentinhalt. Alte signierte Versionen, Backups, andere Dokumente und geteilte Kopien behalten ihre bisherigen Inhalte; widerrufen oder rotieren Sie offengelegte Schlüssel beim jeweiligen Anbieter. Inhalte der Zwischenablage bleiben nach dem Sperren bestehen und sind möglicherweise für andere Apps oder den Zwischenablageverlauf des Betriebssystems sichtbar. Löschen Sie sie nach Gebrauch. Diese Funktion entdeckt Geheimnisse nicht automatisch und rotiert keine Schlüssel. Aktualisieren Sie alle Clients, bevor Sie Dokumente synchronisieren, die Geheimnisreferenzen enthalten. Ablehnungsbedingungen, Bearbeitung und Aktualisierung von Zugangsdaten, Plattformanforderungen und Fehlerbehebung für die Zwischenablage beschreibt der vollständige Leitfaden.

Passwortlose SSH- und Datenbank-Proxys

memories proxy start öffnet nach Terminal-sudo und Prüfung der Host-Zulassungsliste der Zugangsdaten einen Listener auf 127.0.0.1. Es gibt eine id, eine listen-Adresse und einen sofort nutzbaren command zurück. Führen Sie diesen Befehl im Terminal des Agenten auf dem Rechner des Daemons aus; es wird kein gespeichertes Passwort und kein privater Schlüssel zurückgegeben. Upstream-Konto, Host und anfängliche Datenbank werden durch die Startargumente des Proxys ausgewählt. Ein Proxy autorisiert Befehle für dieses Konto ohne Genehmigung jedes einzelnen Befehls.

memories sudo
memories proxy start ssh --vault VAULT_ID --credential KEY_ID --host example.test --user alice --host-key HOST_KEY
memories proxy start postgres --vault VAULT_ID --credential PASSWORD_ID --host db.example.test --user app --database appdb
memories proxy start mysql --vault VAULT_ID --credential PASSWORD_ID --host db.example.test --user app --database appdb
memories proxy start redis --vault VAULT_ID --credential PASSWORD_ID --host cache.example.test --user default
memories proxy list
memories proxy stop PROXY_ID

Verwenden Sie zuerst credential allow-host VAULT_ID CREDENTIAL_ID HOSTNAME, um das Ziel eines Zugangsdaten-Eintrags zu autorisieren. Prüfen Sie einen mit remote probe ermittelten SSH-Fingerabdruck über einen vertrauenswürdigen Kanal, bevor Sie --host-key angeben. SSH-Proxys leiten exec-, Shell-, PTY- und Subsystem-Anfragen weiter; Upstream-Hostschlüssel bleiben fest hinterlegt. Lokale SSH-Hostschlüssel sind kurzlebig, daher deaktiviert der zurückgegebene Befehl die dauerhafte Speicherung von Hostschlüsseln nur für den lokalen Endpunkt.

Datenbank-Upstreams verwenden standardmäßig verifiziertes TLS, optional mit --tls-ca CA_ID. Der lokale Datenbankabschnitt verwendet Klartext über Loopback. PostgreSQL unterstützt SCRAM-SHA-256-, MD5- und Passwortauthentifizierung. MySQL unterstützt mysql_native_password und caching_sha2_password; vollständige SHA-256-Passwortauthentifizierung benötigt TLS. Die Weiterleitung von PostgreSQL-Abbruch-/Startoptionen und MySQL-Komprimierung sind nicht implementiert. Lokale Anmeldenamen und anfängliche Datenbankanfragen überschreiben das konfigurierte Upstream-Konto/die konfigurierte Datenbank nicht.

Jeder Prozess, der den lokalen Port erreichen kann, kann dessen autorisiertes entferntes Konto verwenden. Halten Sie den Port lokal. Sperren, automatische Tresorsperre bei Inaktivität, proxy stop und das Herunterfahren des Daemons schließen Listener und bestehende Verbindungen. Proxys laufen auch bei Benutzung nach 30 Minuten ab; es sind höchstens vier Proxys und 16 Verbindungen pro Proxy erlaubt. MCP kann Proxys weder starten noch auflisten oder stoppen; ein Agent verwendet seinen gewöhnlichen Terminal-Client, nachdem der Benutzer einen Proxy gestartet hat.

Passwörter und Befehlsausgaben erfassen

memories catch (auch memories credential catch) erfasst ein UTF-8-Geheimnis und speichert es als verschlüsselten Zugangsdaten-Eintrag. Führen Sie zuerst im selben Terminal memories sudo aus. Ohne Quellen-Flag fragt es wie credential add nach einer verdeckten Eingabe:

memories sudo
memories catch VAULT_ID "Database password"

Verwenden Sie --stdin für eine Pipe oder eine umgeleitete Datei. Diese Beispiele funktionieren in Windows CMD; secret-tool steht für Ihr eigenes Programm, das den Wert ausgibt:

secret-tool.exe | memories catch VAULT_ID "Database password" --stdin --regex "password=([^\r\n]+)"
memories catch VAULT_ID "API token" --stdin --json-pointer /token < response.json
memories catch VAULT_ID "API token" --exec secret-tool.exe --json-pointer /token -- issue --format json

--exec PROGRAM -- ARGS... startet das angegebene Programm direkt und erfasst stdout. Es schließt stdin des Kindprozesses und unterdrückt stderr. Verwenden Sie für ein CMD-Skript --exec cmd.exe -- /d /c script.cmd; Shell-Operatoren benötigen eine bewusst ausgewählte Shell. Interaktive externe Programme, die ein Terminal benötigen, werden in diesem Modus nicht unterstützt; verwenden Sie stattdessen verdeckte Eingabe oder einen nicht interaktiven Ausgabebefehl.

Ohne Selektor behält die Erfassung den vollständigen Text bis auf ein abschließendes LF/CRLF. Ein regulärer Ausdruck muss genau einmal treffen; seine einzelne Erfassungsgruppe wird gespeichert oder der gesamte Treffer, wenn er keine Gruppen hat. Verwenden Sie (?:...) für zusätzliche Gruppierung. --json-pointer wählt eine JSON-Zeichenkette (zum Beispiel /credentials/password); es kann nicht mit --regex kombiniert werden. JSON-Objekte müssen eindeutige Schlüssel besitzen, einschließlich verschachtelter Objekte und maskierter Entsprechungen wie password und pass\u0077ord. Leere Werte, ungültiges UTF-8, mehrdeutige Treffer, doppelte Schlüssel und fehlgeschlagene Befehle werden ohne Speicherung abgelehnt. Verwenden Sie --id CREDENTIAL_ID, um einen Zugangsdaten-Eintrag zu ersetzen.

Die Eingabe ist auf 1 MiB begrenzt. Befehle überschreiten nach 30 Sekunden ihr Zeitlimit; setzen Sie --timeout bei Bedarf auf 1-300 Sekunden. Bei Zeitüberschreitung oder übermäßiger Ausgabe beendet die Erfassung ihren direkten Kindprozess; sie bietet keine Begrenzung des gesamten Prozessbaums. stdin aus einer Pipe wartet auf EOF und hat kein Zeitlimit. Erfolgreiche Ausgabe enthält die Zugangsdaten-ID, niemals den erfassten Wert. Verwenden Sie memories run oder autorisierte HTTP-Vorgänge, um ihn zu verwenden. Geben Sie echte Geheimnisse nicht in Befehlsargumenten, Regex-Mustern oder Titeln an. Die Erfassung löscht keine Quelldateien, keinen Shell-Verlauf und keine vom Quellprogramm erzeugten Protokolle.

Geräte, Mitglieder und Synchronisierung

Cloud-Konten autorisieren

Autorisieren Sie OneDrive oder Google Drive auf diesem Gerät mit Ihrer eigenen registrierten OAuth-Anwendung. Starten Sie den aktuellen Daemon, entsperren Sie die Bibliothek und führen Sie vor der Anmeldung sudo im selben Terminal aus:

memories sudo
memories cloud login onedrive --client-id YOUR_MICROSOFT_CLIENT_ID
memories cloud login google-drive --client-config /path/to/google-desktop-client.json
memories cloud status
memories cloud logout onedrive

Die Anmeldung öffnet den Browser und validiert einen lokalen Callback mit PKCE/state. Tokens werden im verschlüsselten gerätelokalen Zustand gespeichert und sind von Backups/Geräteaustausch ausgeschlossen. Der Status gibt niemals Tokens aus. Die Abmeldung entfernt die lokale Autorisierung; die Einwilligung beim Anbieter wird separat verwaltet. memories cloud sync lädt nach Aktualisierung der Tokens unveränderliche Chiffretextobjekte über den verbundenen OneDrive- oder Google-Drive-Anwendungsordner hoch und herunter. Mobil stehen Steuerelemente für Cloud-Verbindung und Vordergrundsynchronisierung bereit; die Registrierung eines nativen OAuth-Clients ist erforderlich. Siehe mobile Cloud-Einrichtung.

Informationen zu Anbieterregistrierung, Redirect-URIs, --no-browser, Ablauf und Fehlerbehebung finden Sie in docs/cloud-authorization.md.

Gerätekopplung und Tresorübertragung

Initialisieren Sie das neue Gerät mit seinem eigenen Passwort und führen Sie Folgendes aus:

memories sudo
memories device invite request.json

Übertragen Sie die Anfrage auf ein bestehendes Gerät. Vergleichen Sie den vollständigen Einladungsfingerabdruck direkt mit dem anfragenden Gerät, bevor Sie sie genehmigen:

memories sudo
memories device approve request.json approval.json --fingerprint REQUEST_FINGERPRINT

Der genehmigende Befehl gibt seinen öffentlichen Geräteschlüssel zurück. Prüfen Sie diesen Schlüssel über einen vertrauenswürdigen Kanal, bevor Sie die Antwort auf dem neuen Gerät annehmen. Führen Sie vor der Annahme sudo im selben Terminal auf dem neuen Gerät aus:

memories sudo
memories device accept approval.json --sender APPROVING_DEVICE_PUBLIC_KEY

Anfragen laufen nach zehn Minuten ab und sind nur einmal verwendbar. Ein neu initialisiertes Gerät darf keine Tresore haben, bevor es einer bestehenden Identität beitritt. Jedes Gerät behält seinen eigenen privaten Transportschlüssel und Gerätesignaturschlüssel; die Signaturbefugnis der Benutzeridentität wird ausschließlich innerhalb der verschlüsselten Genehmigung übertragen. Ein vom Benutzer signiertes Zertifikat allein gewährt keinen Tresorzugriff: Die signierte Geräte-Zulassungsliste des Tresors muss es ebenfalls genehmigen.

Genehmigen Sie für eine andere Person stattdessen deren Anfrage für einen bestimmten Tresor:

memories member approve VAULT_ID request.json approval.json --fingerprint REQUEST_FINGERPRINT --role reader
memories member list VAULT_ID
memories member role VAULT_ID USER_PUBLIC_KEY editor
memories member remove VAULT_ID USER_PUBLIC_KEY
memories device revoke VAULT_ID DEVICE_PUBLIC_KEY

Eigentümer verwalten Administratoren und Eigentum; Administratoren verwalten gewöhnliche Mitglieder; Editoren schreiben Assets; Leser lesen und verwenden Assets. Gerätewiderruf gilt pro Tresor. Wenden Sie ihn auf jeden betroffenen Tresor an. Gehen Sie niemals davon aus, dass das Entfernen eines Mitglieds dessen bestehende Kopien löscht.

Verschlüsselter Dateiaustausch funktioniert ohne Relay:

memories sync export VAULT_ID RECIPIENT_DEVICE_PUBLIC_KEY packet.json
memories sync import packet.json

Betreiben Sie für eine Online-Übertragung memories-relay hinter einem TLS-Reverse-Proxy und erstellen Sie mit memories sync room einen Raum. Zuerst auf dem Empfänger, dann auf dem Sender:

memories sync receive --relay wss://relay.example.com --room ROOM
memories sync send VAULT_ID RECIPIENT_DEVICE_PUBLIC_KEY --relay wss://relay.example.com --room ROOM

Der Relay hält keine Pakete für Offline-Geräte in einer Warteschlange vor. Erfolgreiches Senden bedeutet, dass ein Paket an den Relay übergeben wurde, nicht dass eine Gegenstelle es geprüft/importiert hat; der Empfänger meldet den Importerfolg separat. sync export/import und Relay-sync send/receive sind bewusste Übertragungen vollständiger Tresore, keine automatische inkrementelle Cloud-Synchronisierung. cloud sync PROVIDER tauscht stattdessen unveränderliche Chiffretextobjekte über dauerhafte Cloud-Warteschlangen aus; die Prüfung mit realen Konten steht weiterhin aus. Relay-RPC ist wiederum etwas anderes: Es ruft den entfernten Daemon auf, ohne dessen Tresor in den Speicher des Clients zu importieren. Ein benutzereigener, ständig online befindlicher Client kann eine Replik halten, aber dieser Client ist ein vertrauenswürdiger Endpunkt und kein nicht vertrauenswürdiger Speicherserver.

Jede Erstellung/Aktualisierung schreibt eine neue signierte Revision in den Tresor-DAG (Erinnerungen, Wissens-/Brain-Karten, Metadaten geschützter Karten, Dateien und Zugangsdaten). Verwenden Sie memory history / card history / file history, um Revisionen aufzulisten (revision, Zeitstempel, Autor, Head, Zusammenfassung). Rufen Sie eine Revision mit read --revision ab und vergleichen Sie mit memory diff / card diff / file diff (einheitlicher Text-Diff über Titel, strukturierte Metadaten und Inhalt; Datei-Diffs lassen binäre Nutzdaten weg; geheime Zugangsdateninhalte werden niemals zurückgegeben). Revisionen werden mit dem Tresor unbegrenzt aufbewahrt, ohne automatische Bereinigung. Gleichzeitige Asset-Bearbeitungen bleiben als mehrere Heads bestehen. Verwenden Sie nach ihrer Prüfung memory history und bewusst memory put --id ASSET_ID --resolve. Zuvor unbekannte Änderungen aus alten Epochen gelangen in sync quarantine; sync reapply signiert eine neue Revision der aktuellen Epoche. Bei auseinanderlaufenden Berechtigungsketten wird der Zugriff sicher verweigert. Ein auf beiden Zweigen gültiger Eigentümer kann sie prüfen und sync resolve-policy VAULT_ID packet.json --keep-local ausführen und anschließend die signierte Auflösung verteilen. Konflikte mit unvereinbaren Eigentumsübertragungen bleiben blockiert, statt einer Partei einseitige Kontrolle zu gewähren.

Audit und Wiederherstellung

memories audit VAULT_ID --verify
memories sudo
memories audit VAULT_ID
memories backup offline-backup.memories

Backups verwenden ein unabhängiges Passwort. Bewahren Sie eine Kopie außerhalb des Geräts auf. Starten Sie zur Wiederherstellung einen Daemon mit einem neuen --home und führen Sie dann Folgendes aus:

memories --home NEW_DIRECTORY restore offline-backup.memories --name replacement
memories --home NEW_DIRECTORY sudo
memories --home NEW_DIRECTORY archive list

Die Wiederherstellung erstellt unabhängige Tresore mit den aktuellen Assets und erhaltenen Konflikt-Heads. Sie belebt keine veralteten Befugnisse für geteilte Tresore wieder. Ursprüngliche Versionen, Löschmarkierungen und signierte Auditdatensätze verbleiben im verschlüsselten, schreibgeschützten Wiederherstellungsarchiv (archive history, archive read, archive audit). Treten Sie aktiven geteilten Tresoren über ein aktuell autorisiertes Mitglied erneut bei. Historische Zugangsdatenwerte können weder über die normalen Schnittstellen noch über die Archivschnittstellen ausgegeben werden.

Skill-Injektion für KI-Clients

Installieren Sie den mitgelieferten Skill memories, damit ein KI-Client lernen kann, Memories-Wissen zu suchen, abzurufen und zu speichern, anhand autorisierter Dokumente zu antworten und autorisierte Zugangsdatenvorgänge zu verwenden:

memories inject all --dry-run
memories inject all
memories inject codex
memories inject opencode claude
memories inject all --project /path/to/project

Standardmäßig erfolgt die Installation benutzerweit. --project DIRECTORY installiert nur in einem bestehenden Projektverzeichnis (verwenden Sie --project . für das aktuelle Verzeichnis). claude zielt auf Claude Code, wobei claude-code als Alias akzeptiert wird.

~ ist das Home-Verzeichnis des Betriebssystembenutzers, einschließlich %USERPROFILE% unter Windows. OpenCode berücksichtigt OPENCODE_CONFIG_DIR, dann ein absolutes XDG_CONFIG_HOME plus opencode, dann den oben genannten Standard. Claude Code berücksichtigt CLAUDE_CONFIG_DIR. Codex verwendet seinen dokumentierten Pfad .agents/skills, unabhängig von CODEX_HOME. Die Projektinstallation ignoriert diese globalen Überschreibungen. OpenCode findet außerdem Claude-/agentenkompatible Skill-Verzeichnisse; halten Sie bei Verwendung mehrerer Clients den Inhalt des Skills memories an allen Orten gleich, um widersprüchliche Definitionen zu vermeiden.

Die Installation erfolgt offline und benötigt weder Daemon noch initialisierten Speicher. Sie schreibt nur den mitgelieferten Skill, ohne Tresorinhalte zu lesen/exportieren, Berechtigungen zu erstellen oder MCP-/Client-Konfiguration zu verändern. --home/MEMORIES_HOME wählen den Memories-Datenspeicher für normale Vorgänge, nicht das Skill-Ziel; die Installation bettet diesen Pfad nicht ein. Konfigurieren Sie bei einem vom Standard abweichenden Speicher dasselbe Home in der Umgebung Ihres Clients oder im MCP-Befehl.

Bestehende identische Dateien bleiben unberührt. Eine abweichende SKILL.md, auch ein älterer Skill aus einer früheren Memories-Version, wird abgelehnt, sofern nicht --force angegeben wird; diese Option ersetzt nur diese Datei und erhält benachbarte Dateien. Verknüpfte Skill-Dateien/-Verzeichnisse werden selbst mit --force abgelehnt. Alle Ziele werden vor dem Schreiben auf Konflikte geprüft, und jede Datei wird atomar veröffentlicht. Ein späterer Dateisystem-E/A-Fehler kann dazu führen, dass frühere Ziele installiert bleiben; beheben Sie den Fehler und führen Sie den Vorgang erneut aus. --dry-run führt dieselben Prüfungen durch und meldet geplante Pfade/Aktionen, ohne etwas zu schreiben; verwenden Sie --dry-run --force, um Ersetzungen vorab anzusehen.

Stellen Sie sicher, dass memories im PATH des Clients liegt. Öffnen Sie eine neue Client-Sitzung, wenn der Skill nicht sofort erkannt wird. Rufen Sie in Codex $memories auf; in Claude Code /memories; bitten Sie OpenCode, den Skill memories zu laden. Die lokale Skill-Installation installiert keine Skills auf Kontoebene in Claude Desktop/Cowork oder Cloud-Sitzungen. Der Skill verwendet eine bereits konfigurierte MCP-Verbindung, wenn eine verfügbar ist; konfigurieren Sie diese separat wie unten beschrieben.

Konventionen zur Erkennung: Codex, OpenCode, Claude Code.

AGENTS.md / Persona-Skill erzeugen

Schreiben Sie eine projektbezogene AGENTS.md (oder ein Skill-Verzeichnis im Cursor-/Codex-Stil), die die Bedienung von Memories erklärt: Tresore, Karten, Persona/Welt/Dinge, Verlauf/Diff und Grundlagen des entfernten Daemons. Optional können Sie eine Übersicht des Persona-Kerns einbetten:

memories skill generate --out AGENTS.md
memories skill generate --out AGENTS.md --persona VAULT/PERSONA
memories agents generate --out ./skills/memories-persona --layout skill --persona VAULT/PERSONA

--layout agents (Standard) schreibt eine einzelne Markdown-Datei. --layout skill schreibt SKILL.md in das Ausgabeverzeichnis (oder an den Pfad, wenn er bereits auf .md endet). Wird --persona ausgelassen, wird der Client-Standardwert persona verwendet, sofern gesetzt. Die Erzeugung mit einer Persona liest diese Karte über den Daemon (zuerst entsperren). Ohne Persona erfolgt die Erzeugung offline und benötigt keinen Daemon. Verwenden Sie --force, um eine abweichende bestehende Datei zu ersetzen; --dry-run zeigt den Plan vorab, ohne zu schreiben.

memories inject bleibt das separate Offline-Installationsprogramm für den mitgelieferten allgemeinen Skill in den Pfaden von Codex / OpenCode / Claude Code.

Standardwerte der Client-CLI

Nicht geheime Standardwerte liegen in defaults.json im Memories-Home-Verzeichnis (MEMORIES_HOME / --home), nicht im Chiffretext eines Tresors:

memories default set persona VAULT/PERSONA
memories default set vault VAULT_ID
memories default set type persona
memories default get
memories default get type
memories default delete type

Explizit gesetzte Flags haben immer Vorrang. Persona-Unterbefehle, die Tresor/Asset annehmen, verwenden für ausgelassene Positionsargumente die Standardwerte (world-get, thing, append-event, …). persona import benötigt weiterhin eine explizite Tresor-ID vor dem Skill-Pfad (Positionsreihenfolge von clap).

Lokales MCP

Dieser Abschnitt beschreibt gewöhnliche, auf einen Tresor begrenzte MCP-Berechtigungen. Der separate, ausdrücklich zu aktivierende unbeaufsichtigte Server hat eine weiter gefasste Lesegrenze.

memories sudo
memories mcp grant VAULT_ID PRIVATE_GRANT_FILE --minutes 15
memories mcp serve --grant-file PRIVATE_GRANT_FILE
memories mcp revoke PRIVATE_GRANT_FILE

Die Berechtigung ist eine lokale Bearer-Fähigkeit, die in eine Datei geschrieben und nicht ausgegeben wird. Schützen Sie diese Datei. Berechtigungen gewähren standardmäßig Lesezugriff; verwenden Sie --scope read_write für das Schreiben gewöhnlicher Inhalte oder --scope read_write_delete, um Löschungen einzuschließen. --write ist eine kompatible Kurzform für --scope read_write. Diese Umfänge gewähren keinen Zugriff auf private Inhalte, Dateien, Zugangsdaten oder sudo. Konfigurieren Sie den stdio-MCP-Befehl Ihres KI-Clients als memories mcp serve --grant-file ... mit demselben Home wie der laufende Daemon. Die Tools sind 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, workflow_card, workflow_read, workflow_update und workflow_list sowie die unter Persona-Karten aufgeführten Persona-Tools. workflow_card erstellt Schritt-Workflows, Checklisten-Vorlagen oder aus einer Vorlage kopierte Aufgaben, und workflow_update bearbeitet Checklistenfelder oder schaltet Schritte weiter; beide benötigen einen Schreibumfang. workflow_read und workflow_list funktionieren mit Lesezugriff. Jeder Aufruf enthält die autorisierte Tresor-ID. memory_retrieve gibt zitierte Dokumentabschnitte zurück. Der Standardmodus ist lokales BM25; vector und hybrid verwenden den konfigurierten Embedding-Anbieter des Daemons. memory_ask beantwortet Fragen anhand dieser Quellen, wenn eine Generierungs-URL konfiguriert ist, und lehnt Zitate ab, die nicht in den abgerufenen Belegen enthalten waren. Siehe Retrieval und RAG. Private Erinnerungen, Dateien, Zugangsdatenzugriff, Prozessausführung und Änderungen der Tresormitgliedschaft sind ausgeschlossen. Ausstellung, Auflistung und Widerruf von Berechtigungen sowie Berechtigungsanfragen sind separate MCP-Tools und erben sudo nicht. Sperren entfernt Berechtigungen aus dem Arbeitsspeicher; nicht abgelaufene Berechtigungen werden nach dem Entsperren wieder aktiv. MCP-Protokoll: 2024-11-05. MCP-Lesevorgänge lassen Geheimnisreferenzen unaufgelöst. Das aktuelle Tool card_write kann Karten mit Geheimnisreferenzen nicht aktualisieren, weil es deren Zuordnung nicht erhält; bearbeiten Sie diese Karten über die CLI oder die mobile App.

Unbeaufsichtigte Desktop-CLI/MCP

Die bewusste Registrierung erfordert eine durch Eingabe von ENABLE bestätigte Einwilligung sowie einmaliges Entsperren/sudo mit Passwort zur Einrichtung. Wählen Sie bewusst windows-dpapi, macos-keychain, linux-secret-service oder das weniger geschützte Backend owner-file und stellen Sie dann eine auf einen Tresor begrenzte Client-Datei aus. Wählen Sie diese Datei mit unattended ... --client-file PATH oder mcp serve-unattended --client-file PATH aus. Diese Clients können gewöhnliche/private Inhalte, Originaldateien, Verlauf und bewusst angeforderten Zugangsdaten-Klartext lesen, aber keine Assets verändern oder sudo erben.

Der Daemon-Start lädt nur Schlüssel, keine gewöhnliche implizite Autorisierung. Manuelles lock sperrt unbeaufsichtigten Zugriff dauerhaft bis zu einem passwortautorisierten unattended resume; revoke entfernt eine Berechtigung und disable entfernt alle unbeaufsichtigten Befugnisse. Vom Center verwaltete Speicher, entfernte Transporte und mobile Clients können dies nicht verwenden. Gewöhnliches MCP bleibt unverändert. Base64 für Zugangsdaten ist eine Kodierung, keine Verschlüsselung: Ein KI-Client oder seine Protokolle können das Geheimnis behalten. Siehe Einrichtung, Bytebereich-Lesevorgänge und Sicherheitsgrenzen.

Wissenskarten und geschützte Karten

Alle Wissenskarten unterstützen Kartentypen und benutzerdefinierte Felder: Notiz, Kontakt, Link, Codeausschnitt, Checkliste, Ereignis und Zugangsdaten sowie wiederverwendbare Tresorvorlagen. Felder sind geordnet und werden validiert; sensible Werte bleiben maskiert, sofern sie nicht bewusst mit verifizierter Autorisierung offengelegt werden. Verwenden Sie memories type und memories card field oder die Karteneditoren von Flutter und dem eingeschränkten Desktop.

Karten unterstützen Tags, Quellen, optionale Aliasse (别名), Notizen/Anmerkungen (备注), Kategorien (分类), gerichtete Beziehungen und Rückverweise. Gewöhnliche Karteninhalte und unbedenkliche Kontozusammenfassungen sind lokal durchsuchbar; gewöhnliches Lesen privater Karten benötigt sudo und ist von gewöhnlicher Suche und MCP ausgeschlossen. Die separate unbeaufsichtigte Befugnis kann private Karten im erlaubten Umfang lesen. Verwenden Sie beim Erstellen/Aktualisieren --alias, --notes und --category. card list (auch auf oberster Ebene memories list / memories ls) kann die Tresor-ID auslassen, um jeden zugänglichen Tresor zu durchsuchen (jedes Ergebnis enthält vault). --type knowledge|brain|persona|workflow|account|env|token|totp|hotp|otp filtert nach summary.type (knowledge sind einfache Wiki-/Wissenskarten; brain ist strukturiertes Wissen mit einer Zusammenfassung und typisierten Verknüpfungen; otp bedeutet totp+hotp); --otp ist die Kurzform für --type otp. --category NAME filtert; --group-by-category gruppiert die Ausgabe. Die Liste zeigt Alias, Notizen und Kategorie, sofern vorhanden.

memories card put VAULT_ID --title "An idea" --input notes.md --tag design --alias "Design note" --notes "from workshop" --category design
memories card list VAULT_ID
memories list
memories ls --type knowledge
memories card list --type brain
memories list --type otp
memories ls --otp --category security
memories card list VAULT_ID --type account
memories card list VAULT_ID --category design
memories card list VAULT_ID --group-by-category
memories card brain VAULT_ID --title "Alice" --abstract "Product lead bridging design and eng" \
  --link CARD_A=reports-to --link "OTHER_VAULT/CARD_B=collaborates|shared roadmap" \
  --alias "Alice" --notes "org chart" --category people
memories card brain VAULT_ID --id BRAIN_ID --title "Alice" --abstract "Updated abstract" --link CARD_B=partner
memories card link VAULT_ID CARD_A CARD_B --relation supports
memories card graph VAULT_ID
memories card graph VAULT_ID --include-private
memories card search VAULT_ID design
memories card unlink VAULT_ID CARD_A CARD_B --relation supports
memories card delete VAULT_ID CARD_ID

card delete entfernt die Karte (wie memory delete) aus aktuellen Ansichten; der signierte Verlauf bewahrt frühere Revisionen. Das Löschen privater oder geschützter Karten benötigt sudo.

Brain-Karten speichern ein Klartext-abstract (innerhalb der Tresorberechtigungen durchsuchbar, kein geschütztes Geheimnis) und typisierte Verknüpfungen { vault?, card, role?, note? }, die tresorübergreifend sein können. Setzen Sie den gesamten --link-Wert in Anführungszeichen, wenn er | oder Leerzeichen enthält, damit die Shell ihn nicht als Pipeline interpretiert. summary.type ist brain mit link_count. List/graph/read lösen Verknüpfungstitel und -typen auf, wenn dies erlaubt ist, und markieren fehlende oder nicht autorisierte Ziele als broken (kein kaskadierendes Löschen). Die Suche indiziert Titel, Zusammenfassung, Verknüpfungsrollen/-notizen und öffentliche Zielzusammenfassungen aus demselben Tresor, niemals Geheimnisse. Brain-Verknüpfungen innerhalb desselben Tresors erscheinen auch in card graph.

Persona-Karten (summary.type = persona) speichern einen produktübergreifenden Identitätskern mit verknüpften Archiv-Assets, einer IANA-timezone zur Einordnung lokaler Tage/Zeitabschnitte (jeden zweiten Tag / Morgen- und Abendlektionen), einem Weltbereich (place / pose / look / allgemeine things mit freien JSON-Attributen / Hauptbuch / Wetter / Würfel / Drehscheibe / Zeitplan) und ausschließlich angehängten Verhaltensereignissen mit Zeitstempeln in UTC und Ortszeit. Siehe docs/persona.md. Importieren Sie mit memories persona import VAULT_ID ./xiaoya-persona --timezone Asia/Shanghai; aktualisieren Sie den Weltzustand mit memories persona world-set.

Workflow-Karten (summary.type = workflow) speichern geordnete Schritte in der Kartenrevision, jeweils mit pending, active, done oder skipped, sowie einen Gesamtstatus; memories card workflow VAULT --title Release --step "Write notes" --step Ship erstellt eine solche Karte, memories card workflow-update VAULT ASSET --advance schaltet einen Schritt weiter, und memories card list --type workflow listet sie auf.

Eine Checklisten-Vorlage wird mit memories card workflow VAULT --template --assignee NAME --summary OVERVIEW --goal GOAL erstellt (summary.type bleibt workflow, das Profilfeld template ist true), mit memories card list --type workflow --template aufgelistet und mit memories card workflow VAULT --template TEMPLATE in einen Aufgaben-Workflow kopiert. Dieser kann mit --workflow WORKFLOW eine andere Workflow-Karte verknüpfen und mit --archive MEMORY eine Erinnerung archivieren.

Gewöhnliche gerichtete Verknüpfungen (card link) verweisen auf Karten im selben Tresor. Graphen lassen gelöschte, konfliktbehaftete und nicht autorisierte Knoten sowie deren angrenzende Kanten aus. Referenzen verbleiben im verschlüsselten Verlauf. Die Wiederherstellung erhält die IDs eindeutiger Assets, sodass Beziehungen und Zugangsdatenreferenzen im wiederhergestellten unabhängigen Tresor weiter funktionieren; Referenzen auf konfliktbehaftete Assets müssen möglicherweise repariert werden. Mobil werden ausgehende Verknüpfungen, Rückverweise und ein verschiebbarer/vergrößerbarer Graph angezeigt (bis zu 24 Knoten auf der Zeichenfläche, mit Auswahl aus dem vollständigen Graphen und Beziehungslisten).

Geschützte Karten speichern Metadaten und separate Zugangsdaten in einer Transaktion:

Website-Anmeldungen werden üblicherweise gesammelt importiert, statt einzeln eingegeben; siehe Website-Anmeldungen importieren und exportieren.

memories sudo
memories card account VAULT_ID --title "Example mail" --email user@example.test --smtp smtp.example.test
memories card env VAULT_ID ./app.env --title "Application config"
memories card token VAULT_ID --title "API session" --host api.example.test
memories card token VAULT_ID --title "Browser session" --host app.example.test --cookie
memories card request VAULT_ID TOKEN_CARD_ID https://api.example.test/session
memories card otp VAULT_ID --title "Example OTP" --issuer Example --account user@example.test
memories card otp VAULT_ID --title "Example HOTP" --issuer Example --account user@example.test --hotp --counter 0
memories card otp-import VAULT_ID --title "Imported OTP" --alias "Work 2FA" --notes "laptop" --category otp 'otpauth://totp/Example:user@example.test?secret=GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ&issuer=Example'
memories card otp-import VAULT_ID --image ./ga-export.png --title "GA import" --category otp
memories card otp-code VAULT_ID OTP_CARD_ID

OTP-Titel können die Form issuer / account aus dem Import behalten, während --alias und --notes Anzeigenamen und Anmerkung separat speichern; --category gruppiert sie in card list.

Passwörter, Tokens, Cookies und OTP-Startwerte werden über verdeckte Terminal-Eingabe angegeben, niemals über Befehlsargumente. Geben Sie im Bearer-Modus ein rohes JWT ein oder im Cookie-Modus name=value; other=value. Konto-SMTP verwendet standardmäßig SSL-Port 465; dies erfasst die Konfiguration und versendet keine E-Mails. Fügen Sie --id CARD_ID hinzu, um Metadaten und Geheimnis einer geschützten Karte zu ersetzen; Zugangsdaten-ID und Kartenverknüpfungen bleiben erhalten. Zugangsdaten-IDs sind Referenzen, keine geheimen Werte. Allgemeine Kartenschreibvorgänge können geschützte Referenzen nicht ersetzen.

Der dotenv-Importer maskiert alle Werte, einschließlich leerer/nicht geheimer Werte, und indiziert niemals Werte oder Kommentare. Er akzeptiert ein KEY=value pro Zeile, optionales export, Leerzeilen und Kommentare. Doppelte Schlüssel und mehrzeilige Werte in Anführungszeichen werden abgelehnt. Er expandiert keine Variablen und führt die Datei nicht aus. Die ursprüngliche Quelldatei bleibt an ihrem Ort; der Import verändert ihre Berechtigungen nicht und löscht sie nicht. Frei formulierbare Kartentitel/-notizen sind kein automatisches System zur Erkennung von Geheimnissen.

Der HTTPS-Adapter injiziert clientseitig entweder Authorization: Bearer ... oder Cookie: .... Er benötigt sudo, den exakt genehmigten Host, HTTPS-Port 443 und GET/POST. Weiterleitungen und Umgebungs-Proxys sind deaktiviert; nur der Status wird zurückgegeben, während Antwortinhalte/-header unterdrückt werden, um die Ausgabe gespiegelter Geheimnisse zu verhindern. Dies ist ein Adapter für autorisierte Anfragen, kein allgemeiner Weiterleitungsproxy oder Browser-Cookie-Speicher. Cookie-Ablauf, JWT-Aktualisierung und automatische Anmeldung sind nicht implementiert.

TOTP unterstützt SHA-1/SHA-256/SHA-512 (--algorithm), 6/8 Ziffern (--digits) und Perioden von 30/60 Sekunden (--period). HOTP verwendet dieselben Algorithmen und Ziffernanzahlen mit --hotp und einem anfänglichen --counter (bei jedem otp-code erhöht). Importieren Sie mit otp-import Google-Key-URIs (otpauth://totp/... oder otpauth://hotp/...), Google-Authenticator-Migrations-URIs (otpauth-migration://offline?data=...) oder über --image ein QR-Bild (dekodiert mit reinem Rust-rqrr). Die TOTP/HOTP-Art wird aus dem URI oder Migrationsdatensatz übernommen. Ist diese Art ausgelassen, wählt ein counter HOTP aus, und jedes andere Konto ist TOTP. Migrationsnutzdaten können mehrere Karten erstellen; --title ist der Titel einer einzelnen Karte oder ein Präfix für einen Stapel. otp-code liefert nach sudo den kurzlebigen Code und protokolliert die Erzeugung im Audit, ohne den Code in Auditdatensätzen zu speichern; HOTP-Antworten enthalten den nächsten Zähler. Suche und MCP erzeugen niemals Codes oder geben Startwerte zurück. Mobil werden abgelaufene Codes verborgen und der Dialog beim Sperren/Wechsel in den Hintergrund geschlossen. Halten Sie die Geräteuhr für TOTP genau. Mobil werden OTP-QR-Codes nicht mit der Kamera gescannt; verwenden Sie CLI---image oder fügen Sie einen otpauth://- / Migrations-URI ein. Gehostete Gerätekopplung hat einen separaten Kameraablauf; siehe Center.

Mobil stehen die Aktionen Geschützte Karte, .env importieren und Anmeldungen importieren (CSV) bereit. Grundinformationen zu Konten/Zugangsdaten erscheinen direkt in Suchergebnissen und Kartendetails. Token- und OTP-Karten bieten die Menüaktionen Autorisierte Anfrage und OTP erzeugen. Die allgemeine Kartenbearbeitung erhält geschützte Metadaten; das Ersetzen von Geheimnissen erfolgt derzeit über die CLI.

Website-Anmeldungen importieren und exportieren

Website-Anmeldungen liegen in geschützten login-Karten und werden gesammelt übertragen. Import und Export benötigen memories sudo und eine Rolle mit Schreibberechtigung.

memories sudo
# Browser CSV (Chrome/Edge/Brave or Firefox about:logins); the header is detected.
memories login import VAULT_ID --from chrome passwords.csv
memories login import VAULT_ID --from firefox firefox-logins.csv --with-notes
# Read a Firefox profile directly (modern key4.db; prompts for any primary password).
memories login import VAULT_ID --from firefox-profile "/path/to/Profiles/xxxx.default"
# Windows Credential Manager generic credentials (Windows only).
memories login import VAULT_ID --from windows --filter github
memories login import VAULT_ID --from windows --all
# A previous encrypted export.
memories login import VAULT_ID --from memories logins.mlx

# Export: portable encrypted file (recommended) or a browser-compatible CSV.
memories login export VAULT_ID --format encrypted logins.mlx
memories login export VAULT_ID --format csv logins.csv

Eine Anmeldung mit demselben Website-Host und Benutzernamen wie eine bestehende Karte wird übersprungen, wenn das Passwort übereinstimmt, und bei Abweichung als Konflikt gemeldet; --update überschreibt stattdessen. Fehlerhafte CSV-Zeilen werden übersprungen und mit Zeilennummer gemeldet; ein einzelner Import ist auf 2000 Anmeldungen begrenzt. Die Browser-Spalte note wird nur mit --with-notes importiert, weil Notizen als gewöhnlicher Text indiziert werden. Das direkte Lesen von Firefox verarbeitet das moderne Schlüsselformat (Firefox 58+); exportieren Sie bei älteren Profilen eine CSV aus about:logins. Zum Lesen gespeicherter Browser-Passwörter muss der Browser auf manchen Plattformen geschlossen sein; der Browser-Speicher wird dabei niemals verändert.

Der verschlüsselte Export verwendet ein unabhängiges Passwort und lässt sich in jeden Tresor importieren. Der CSV-Export ist Klartext, um Anmeldungen zurück in einen Browser oder einen anderen Passwortmanager zu übertragen: Er ist ausschließlich über die lokale CLI verfügbar, gibt eine Warnung aus, schreibt eine nur für den Eigentümer zugängliche Datei, die noch nicht existieren darf, entschärft Formel-Injektion in Tabellenkalkulationen und sollte nach Gebrauch gelöscht werden. Nur auf ein Gerät beschränkte Tresore können nicht exportiert werden.

Gerätespezifische Konfiguration

memories local-python
memories local-python --program /path/to/python
memories vault list
memories card search LOCAL_VAULT_ID Python

Dies führt den ausgewählten Python-Interpreter im isolierten Modus aus, um seine Version und sein Programmverzeichnis zu erfassen. Umgebungsvariablen werden nicht gesammelt. Jeder Aufruf erfasst eine neue Beobachtung im verschlüsselten Tresor Dieses Gerät mit local_only: true. Dieser gesamte Tresor ist von Geräteautorisierungspaketen und exportierten Backups ausgeschlossen; Mitgliedseinladungen, Synchronisierungsexport/-import und Richtliniensynchronisierung werden abgelehnt. Er bleibt auf diesem Gerät durchsuchbar und übersteht Sperren/Neustarten, aber die Wiederherstellung exportierter Backups stellt ihn bewusst nicht wieder her. Erstellen Sie Wissenskarten in diesem Tresor, um andere lokale Konfiguration zu erfassen. Die Gerätekopplung benötigt weiterhin ein Ziel ohne bestehende Tresore; koppeln Sie zuerst, bevor Sie seine lokalen Konfigurationsbeobachtungen erstellen.

Aktualisieren Sie vor dem Austausch von Karten alle beteiligten Clients: Ältere Clients verstehen die neue Art card und geschützte Metadaten nicht.

Mobil

Wählen Sie beim ersten Start Standalone, Center oder SaaS. Standalone verwendet die verschlüsselte lokale Bibliothek. Center fragt nach der URL Ihres gehosteten Servers und einem Mitgliedstoken; SaaS verwendet https://memories.ivjn.us und fragt nach einem Mitgliedstoken. Gehostete Modi benötigen weder das Erstellen noch das Entsperren einer lokalen Bibliothek. Verwenden Sie später Modus wechseln in der Hauptsymbolleiste, um den Modus zu ändern; bestehende Daten bleiben in ihrem ursprünglichen Speicher. Verbindungsschritte, verfügbare Funktionen, Autorisierung, Bearbeitung und Fehlerbehebung beschreibt der mobile Leitfaden oder die chinesische Bedienungsanleitung.

Mobilen Client bauen und validieren

Verwenden Sie Flutter 3.44.2 (die CI-Version), JDK 17+, Android SDK/NDK und cargo install cargo-ndk --locked. Dieser Checkout wurde mit NDK 28.2.13676358 und den SDK-Plattformen 35, 36 und 37.0 gebaut (Flutter-SDK und Plugins wählen ihre Kompilierungsplattformen aus). Akzeptieren Sie vor dem Bauen die Android-SDK-Lizenzen. Stellen Sie flutter auf PATH bereit und installieren Sie die Rust-Ziele aarch64-linux-android und x86_64-linux-android mit rustup target add.

.\scripts\build-android.ps1 -Apk

Dies baut native ARM64/x86_64-Bibliotheken und eine Debug-APK unter mobile/build/app/outputs/flutter-apk/app-debug.apk. Zugangsdaten zur Release-Signierung sind nicht enthalten. Verwenden Sie unter macOS mit Xcode bash scripts/build-ios.sh und signieren und starten Sie die App anschließend mit Ihrem eigenen Entwicklungsteam. Statische iOS-Bibliotheken werden zwangsweise eingebunden, damit die Dart-FFI-Symbole verfügbar bleiben.

Führen Sie nach dem Bauen der nativen Bibliotheken den tatsächlichen mobilen ABI-Smoke-Test auf einem angeschlossenen Gerät oder Emulator von mobile aus:

flutter test integration_test/native_smoke_test.dart -d DEVICE_ID

Dieser Test verwendet eine temporäre Bibliothek und prüft verschlüsselte Speicherung, Autorisierung, Verweigerung des Lesens von Zugangsdaten, Auditverifikation und Sperren/Entsperren über Rust-FFI. Bauen Sie danach die normale APK erneut, weil Flutter-Integrationstests den Einstiegspunkt der Debug-APK durch ihren Test-Runner ersetzen.

Im Standalone-Modus verwendet der mobile Client denselben Rust-Dienst über C-FFI, lokale Volltextsuche, Dateiauswahldialoge, Geräte-/Mitgliedsgenehmigungsdateien, Online-Relay-Übertragungen sowie Verlaufs- und Auditansichten. Ein durch Keychain/Keystore geschützter lokaler Faktor ergänzt das Passwort. Der Wechsel in den Hintergrund löscht die Autorisierung und schließt Inhaltsdialoge; Android blockiert Screenshots und iOS verdeckt den Schnappschuss des App-Umschalters. Hintergrundsynchronisierung ist in dieser Version nicht aktiviert.

Center und SaaS verwenden den gehosteten Rust-Client über FFI für Anfragegenehmigungen, Wissensnavigation, serverseitige Suche, Details, Bearbeitung, Löschung und Gerätekopplung. Aktionen folgen dem Token-Umfang; strukturierte/versiegelte Karten benötigen ihre spezialisierten Editoren. Der Wechsel in den Hintergrund schließt die gehostete Sitzung; verwenden Sie bei der Rückkehr Gespeicherte Sitzung erneut verbinden oder geben Sie erneut ein Token ein. Lesen Sie den Modusvergleich, bevor Sie einen Arbeitsablauf wählen.

Repository

Details zu Implementierung und Verifikation finden Sie in docs/architecture.md und docs/validation.md. Das Speicher- und Synchronisierungsdesign für OneDrive/Google Drive ist in docs/cloud-storage-design.md dokumentiert. CLI-Autorisierung und cloud sync sind implementiert; Anbieterübertragungen wurden mit lokalen Testdaten ohne reale Konten getestet. Mobile Steuerelemente für Anmeldung/Synchronisierung verwenden AppAuth und den gemeinsamen Rust-Worker; die Prüfung realer Einwilligung und der Plattformen bleiben Freigabevoraussetzungen.