Memories – Benutzerhandbuch

Dieses Dokument erläutert, wie Sie die wichtigsten bereits implementierten Aufgaben mit der aktuellen CLI erledigen. Ersetzen Sie VAULT_ID, ASSET_ID und andere großgeschriebene Kennungen in den Beispielen durch die kurzen IDs, die der jeweilige Befehl tatsächlich zurückgibt. Passwörter werden ohne Anzeige aus einem interaktiven Terminal gelesen. Es gibt weder Passwortparameter noch Passwortumgebungsvariablen. Die Anwendung begrenzt die Länge lokaler Passwörter und Sicherungspasswörter nicht; auch eine leere Eingabe ist zulässig. Schritte, die eine Bestätigung benötigen, verlangen weiterhin eine erneute Eingabe.

Alle Datenbefehle setzen einen laufenden Daemon voraus, der dasselbe Datenverzeichnis verwendet. Globale Optionen:

Befehle geben versioniertes JSON aus. Bei einem Fehler ist der Exitcode ungleich null. Die Bestätigungswörter USE und APPROVE bleiben unabhängig von der Oberflächensprache englisch.

Unter Linux können CLI, Daemon, Relay, FFI und die unten beschriebene Statusseite ausgeführt werden. Linux hat kein natives Tray. Die mobile Anwendung hat keine Oberfläche für die Modellsuche, keine Hintergrundsynchronisierung und keinen Kameraimport von OTP-QR-Codes. Beim Koppeln verwalteter Geräte können Kopplungscodes gescannt werden; siehe Ende-zu-Ende-Geheimnisse zwischen Geräten. Die Ende-zu-Ende-Verifizierung mit echten Cloudkonten ist noch nicht abgeschlossen. Die Befehlszeile kann HOTP, otpauth:// und otpauth-migration:// importieren und mit --image OTP-QR-Code-Bilder dekodieren.

Einstieg nach Aufgabe

Wenn Parameter unklar sind, lesen Sie zuerst die allgemeine Hilfe und anschließend die Hilfe der Unterbefehle. Die Hilfe benötigt keinen Daemon:

memories --help
memories --lang zh memory --help
memories --lang zh memory put --help

--lang zh ändert nur die Sprache von Hilfe und Hinweisen, nicht Befehlsnamen oder Parametersyntax. Die sh-Beispiele in diesem Dokument verwenden eine POSIX-Shell. Das \ am Zeilenende mehrzeiliger Befehle setzt die Zeile fort; fassen Sie solche Befehle in PowerShell/CMD zu einer Zeile zusammen.

Daemon starten und Tresor initialisieren

Starten Sie den Dienst in einem Terminal. Er akzeptiert nur Verbindungen des aktuellen Betriebssystembenutzers: unter Windows über Named Pipes, unter Linux und macOS über Unix-Sockets.

memories daemon

Öffnen Sie ein weiteres Terminal, um das Gerät zu initialisieren, einen Tresor anzulegen, zu sperren und erneut zu entsperren:

memories init --name laptop
memories vault create Personal
memories vault list
memories lock
memories unlock
memories status
memories identity

--name ist optional; der Standardgerätename lautet local-device. identity zeigt die öffentliche Identität dieses Geräts. Initialisierung, Entsperrung und sudo verlangen eine Passworteingabe in einem interaktiven Terminal. Richten Sie --home nicht auf einen vorhandenen gewöhnlichen Ordner; das Programm schränkt dessen Berechtigungen ein.

Der lokale Speicher (store) ist hier das mit --home gewählte Datenverzeichnis. Die Initialisierung richtet die lokale Identität und den Passwortschutz ein. Ein Tresor (vault) ist eine nach Mitgliedern und Berechtigungen abgegrenzte Datensammlung darin; ein Speicher kann mehrere Tresore enthalten. Bei einem eigenen Verzeichnis müssen der Dienst und jeder Clientbefehl dasselbe --home PATH verwenden. Für einen bestehenden Speicher genügt künftig unlock; wiederholen Sie init nicht. Soll ein neues Gerät einer vorhandenen Identität beitreten, führen Sie zuerst die Gerätekopplung durch und erstellen Sie vorher keinen Tresor Personal oder „Dieses Gerät“.

Erstellen Sie nach diesen Schritten mit einem Editor eine UTF-8-Datei notes.md und schreiben Sie eine Testnotiz mit dem im folgenden Suchbeispiel verwendeten chinesischen Wort für „Projekt“ hinein. Ersetzen Sie VAULT_ID im folgenden Beispiel durch die von vault create oder vault list zurückgegebene id, um die erste Erinnerung zu speichern und zu suchen:

memories memory put VAULT_ID --title "项目笔记" --input notes.md
memories memory search VAULT_ID "项目"

Die id im Speicherergebnis ist die ASSET_ID zum späteren Lesen. Verwenden Sie memory für gewöhnliche Notizen, card für Tags, Kategorien und Beziehungen und file für Originaldateien wie PDFs, die nicht automatisch zu durchsuchbarem Text werden. Verwenden Sie credential für Geheimnisse und speichern Sie diese nicht in gewöhnlichen Notizen.

Ein gewöhnliches unlock erlaubt normale Datenoperationen im Rahmen der Berechtigungen, öffnet aber keine privaten Inhalte, Dateien oder Zugangsdaten. sudo ist eine lokale Autorisierungssitzung und keine Betriebssystemadministratorberechtigung. Sie verwendet dasselbe lokale Passwort, gilt höchstens 15 Minuten, verfällt nach 5 Minuten Inaktivität und gehört ausschließlich zum Elternprozess dieses Terminals. Sperren oder Neustarten des Dienstes löscht sie. Eine gewöhnliche Entsperrung verfällt nach 15 Minuten Inaktivität.

Nicht geheime Konfiguration anzeigen oder erstellen:

memories config path
memories config init
memories config init --output ./development.toml
memories --config ./development.toml config show

config init überschreibt keine vorhandenen Dateien. config show öffnet keinen verschlüsselten Tresor. Konfigurationsfelder umfassen storage_dir, relay_url, [desktop] und [rag]. Schreiben Sie keine Passwörter, privaten Schlüssel, OAuth-Token oder MCP-Berechtigungen in diese Datei. Nach Änderungen des Speicherverzeichnisses oder der Modellkonfiguration müssen Sie auch den Daemon neu starten.

Erinnerungen und Karten schreiben, lesen und suchen

Schreiben Sie eine gewöhnliche Erinnerung. Speichern Sie den Text in einer UTF-8-Datei und übergeben Sie diese mit --input:

memories memory put VAULT_ID --title "项目笔记" --input notes.md
memories memory search VAULT_ID "项目"
memories memory read VAULT_ID ASSET_ID
memories memory history VAULT_ID ASSET_ID
memories memory diff VAULT_ID ASSET_ID FROM_REVISION
memories memory diff VAULT_ID ASSET_ID FROM_REVISION --to TO_REVISION
memories memory grep VAULT_ID 'project|release' -i -n

memory grep gleicht reguläre Ausdrücke zeilenweise mit dem entschlüsselten Text gewöhnlicher Erinnerungen im gewählten Tresor ab und gibt DOCUMENT_ID:LINE aus. Mit -n / --line-number lautet die Ausgabe DOCUMENT_ID:LINE_NUMBER:LINE; -i / --ignore-case ignoriert Groß- und Kleinschreibung. Private Dokumente, Konfliktversionen, Karten, Dateien und Zugangsdaten werden nicht geprüft, entsprechend dem Ausschluss privater Inhalte bei der gewöhnlichen Suche. Ohne Treffer erfolgt keine Ausgabe.

FROM_REVISION und TO_REVISION stammen beide aus dem Feld revision der Ausgabe von history, nicht aus id. Die Ausgangsversion ist ein Positionsargument, kein --from; ohne --to wird mit dem aktuellen head verglichen.

Jedes Erstellen/Aktualisieren hängt eine Version an den signierten Revisions-DAG des Tresors an (gewöhnliche Erinnerungen, Wissens-/Brain-Karten, Metadaten geschützter Karten, Dateien und Zugangsdaten). history für memory / card / file listet Versionen (revision, Zeitstempel, Autor, head-Status, Zusammenfassung); read --revision liest historische Texte; diff gibt einen Unified-Text-Diff einschließlich Titel und Kartenmetadaten aus. Datei-Diffs lassen Binärinhalte aus und vergleichen nur Metadaten und Länge. Geheime Inhalte von Zugangsdaten können nicht durch diff/read zurückgegeben werden. Revisionen bleiben langfristig im Tresor erhalten und werden nicht automatisch gekürzt.

Zum Lesen einer historischen Version verwenden Sie --revision REVISION. Zum Ersetzen eines vorhandenen Eintrags verwenden Sie --id ASSET_ID. Bei mehreren nicht zusammengeführten Versionen prüfen Sie zuerst den Verlauf und erstellen dann mit --id ASSET_ID --resolve eine neue Version, die auf alle diese Elternversionen verweist. Aktuell sichtbaren Eintrag löschen:

memories memory delete VAULT_ID ASSET_ID

Das Löschen entfernt nicht den signierten Verlauf. --private markiert den Eintrag als privat. Private Einträge benötigen sudo und sind von gewöhnlicher Suche und MCP ausgeschlossen.

Wissenskarten verwenden dieselben Asset-Unterbefehle und können Tags, Quellen, Aliasse, Notizen, Kategorien und Beziehungen enthalten. Bei card list (auch als übergeordnete Befehle memories list / memories ls verfügbar) kann die Tresor-ID entfallen; dann werden alle zugänglichen Tresore durchsucht (jedes Ergebnis enthält vault). --type knowledge|brain|persona|workflow|account|env|token|totp|hotp|otp filtert nach summary.type (knowledge ist eine gewöhnliche Wissenskarte; brain eine strukturierte Wissenskarte mit Zusammenfassung und typisierten Links; otp steht für totp+hotp). --otp entspricht --type otp. --category filtert nach Kategorie, --group-by-category gruppiert nach Kategorie:

memories card put VAULT_ID --title "一个想法" --input notes.md --tag design --source "会议" --alias "设计备忘" --notes "工作坊" --category design
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 --category design
memories card list VAULT_ID --group-by-category
memories card brain VAULT_ID --title "Alice" --abstract "连接设计与工程的产品负责人" \
  --link CARD_A=reports-to --link "OTHER_VAULT/CARD_B=collaborates|共同路线图" \
  --alias "Alice" --notes "组织图" --category people
memories card brain VAULT_ID --id BRAIN_ID --title "Alice" --abstract "更新后的摘要" --link CARD_B=partner
memories card link VAULT_ID CARD_A CARD_B --relation supports
memories card unlink 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 list VAULT_ID
memories card read VAULT_ID CARD_ID
memories card delete VAULT_ID CARD_ID

Wie memory delete entfernt card delete die Karte nur aus der aktuellen Ansicht; frühere Versionen bleiben im signierten Verlauf erhalten. Das Löschen privater oder geschützter Karten benötigt sudo.

Brain-Karten speichern ein durchsuchbares Klartextfeld abstract (ohne es zum geschützten Geheimnis zu machen) und auch tresorübergreifende Links { vault?, card, role?, note? }. Die Syntax von --link lautet [VAULT/]CARD[=ROLE][|NOTE]. Enthält der Wert | oder Leerzeichen, setzen Sie ihn vollständig in Anführungszeichen, damit die Shell ihn nicht als Pipeline behandelt. summary.type ist brain und enthält link_count. Liste/Graph/Lesen lösen bei ausreichenden Berechtigungen Titel und Typen der Linkziele auf. Fehlende oder nicht zugängliche Ziele werden als broken markiert (keine kaskadierende Löschung). Die Suche indexiert Titel, Zusammenfassung, Linkrollen/-notizen und Zusammenfassungen öffentlicher Ziele desselben Tresors, niemals Geheimnisse. Brain-Links innerhalb desselben Tresors erscheinen auch in card graph.

Der mobile Editor unterstützt Handschrifteingabe und Texterkennung aus Fotos/Bildern, vollständig auf dem Gerät; siehe Handschrift und Texterkennung.

Workflow-Karten und Checklistenvorlagen

Workflow-Karten haben summary.type gleich workflow. Geordnete Schritte werden in Kartenrevisionen gespeichert; jeder Schritt hat den Status pending, active, done oder skipped, außerdem hat die Karte einen Gesamtstatus. Die Syntax von --step lautet TITLE oder ID:TITLE; mit einem abschließenden =CARD kann eine Karte verknüpft werden. Wiederholen Sie den Parameter einmal pro Schritt:

memories card workflow VAULT_ID --title Release --step "Write notes" --step Ship
memories card workflow-update VAULT_ID WORKFLOW_ID --advance
memories card workflow-update VAULT_ID WORKFLOW_ID --step STEP_ID --step-status done
memories card list --type workflow

--advance führt den angegebenen Schritt weiter. Ohne Angabe wird der aktuell active Schritt weitergeführt, andernfalls der erste pending Schritt.

Checklistenvorlagen sind ebenfalls Karten vom Typ workflow, deren Datenfeld template true ist. Beim Erstellen einer Vorlage hat --template keinen Wert; --assignee, --summary und --goal sind erforderlich. --assignee kann eine Persona-Karten-ID, Persona-ID oder ein beliebiger Name sein. --assignee-name ist der Anzeigename; bei einer Persona-Karte wird standardmäßig deren Anzeigename verwendet. --template TEMPLATE_ID kopiert Checklistenfelder und Workflow-Links der Vorlage in eine Aufgabe:

memories card workflow VAULT_ID --template --assignee PERSONA_ID --summary "每周发布检查" --goal "按时发布"
memories card list --type workflow --template
memories card workflow VAULT_ID --template TEMPLATE_ID --workflow WORKFLOW_ID --archive MEMORY_ID
memories card workflow-update VAULT_ID TASK_ID --acceptance "已发布并通知" --status done

--workflow verknüpft eine weitere Workflow-Karte im selben Tresor; --archive archiviert eine Erinnerung oder Karte und kann wiederholt werden. --clear-workflow und --clear-archives von workflow-update entfernen jeweils diese beiden Linkarten. Hat die Aufgabe selbst keine Schritte, wirken --advance, --step, --step-status und --status auf den verknüpften Workflow. Der Abnahmebericht --acceptance darf bis zum Abschluss der Aufgabe leer sein.

Persona-Karten

Persona-Karten synchronisieren Persönlichkeit und Verhalten zwischen Produkten wie Grok Bot / Muse. Die Persona-Karte im Tresor und ihre verknüpften Archive sind die maßgebliche Quelle.

memories persona import VAULT_ID /path/to/xiaoya-persona
memories card list --type persona
memories card read VAULT_ID PERSONA_ID
memories card history VAULT_ID PERSONA_ID
memories card diff VAULT_ID PERSONA_ID REVISION_ID
memories persona append-event VAULT_ID PERSONA_ID --text "行为记录" --kind note

• Kern (core): Sprechweise und Darstellung; über persona put / persona_card überarbeiten.
• Archive (archives): Eigenständige Wissenskarten für Vereinbarungen, Tagebücher, Kleidung, Perspektiven usw., verknüpft über archives der Persona; nicht zurück in den Kern kopieren.
• Verhaltensereignisse: append-event hängt Einträge an das Archiv events an (nur anhängend).

Weltzustand, Gegenstände, Automatisierung und Chats zwischen Personas werden ebenfalls über den Unterbefehl persona gepflegt. Ohne VAULT_ID PERSONA_ID wird persona aus den Clientstandardwerten verwendet:

memories persona world-get VAULT_ID PERSONA_ID
memories persona world-set VAULT_ID PERSONA_ID --place "书房" --weather-condition "多云" --weather-temp-c 26
memories persona world-rollover VAULT_ID PERSONA_ID
memories persona thing put VAULT_ID PERSONA_ID --id notebook --name 笔记本 --count 1 --attrs '{"color":"blue"}'
memories persona thing list VAULT_ID PERSONA_ID
memories persona thing attr set VAULT_ID PERSONA_ID --id notebook --path color --value '"red"'
memories persona dice-roll VAULT_ID PERSONA_ID --sides 6
memories persona schedule-list VAULT_ID PERSONA_ID
memories persona automation list VAULT_ID PERSONA_ID
memories persona automation trigger VAULT_ID PERSONA_ID --id morning --source manual
memories persona chat send VAULT_ID PERSONA_A PERSONA_B --text "你好"
memories persona chat history VAULT_ID PERSONA_A --with PERSONA_B --limit 20

• Weltzustand: world-set aktualisiert Ort, Haltung, Kleidung, Gegenstandsmengen, Wetter, Würfel, Drehrad, Termine usw. world-rollover beginnt beim Tageswechsel ausdrücklich einen neuen Buchungstag und löscht nur Tagesfelder wie meals, orders_done, die kurze look-Zusammenfassung und counters_today; kumulierte Zähler bleiben erhalten.
• Gegenstände (things): thing put/get/list/delete/image verwaltet beliebige Gegenstände; thing attr get/set/delete liest und schreibt einzelne Attribute über Punktpfade oder JSON Pointer. attrs ist freies JSON.
• Automatisierung: automation put/list/run/trigger/delete verwaltet Hooks im Weltzustand; die Zeitzone ist timezone der Persona. Ausgehende webhook_out dürfen nur exakt übereinstimmende URLs der Positivliste verwenden. Die standardmäßig leere Liste blockiert alle ausgehenden POSTs; verwalten Sie sie mit automation webhook-allow --add URL / --remove URL. Webhook-Token werden nicht in Antworten zurückgegeben; angezeigt wird nur webhook_token_set.
• Chat: Nachrichten zwischen zwei Persona-Karten im selben Tresor lösen beim Senden auf beiden Seiten den Automatisierungs-Hook chat_message aus (die Nutzlast enthält keinen Nachrichtentext). chat list zeigt Unterhaltungen; das Lesen von history markiert sie nicht als gelesen, dafür ist chat mark-read erforderlich.

Siehe den englischen Leitfaden zu Persona-Karten.

Auch beim Erstellen gewöhnlicher Karten kann --link TARGET_ID=RELATION wiederholt werden. Solche Beziehungen müssen auf Karten desselben Tresors zeigen. Der Graph lässt gelöschte, konfliktbehaftete und nicht autorisierte Knoten sowie deren Kanten aus. --include-private benötigt sudo.

Private Dateien:

memories sudo
memories file import VAULT_ID document.pdf
memories file export VAULT_ID FILE_ID exported.pdf
memories file history VAULT_ID FILE_ID
memories file diff VAULT_ID FILE_ID FROM_REVISION

file import unterstützt --title und --id. file export unterstützt --revision. file history listet signierte Dateirevisionen; file diff vergleicht nur Titel, Metadaten und Länge und gibt keine Binärinhalte aus.

Mit file exec übergeben Sie verwaltete Konfiguration an ein lokales Programm. {file} in den Programmargumenten wird durch den absoluten Pfad der temporären Datei ersetzt:

memories sudo
memories file import VAULT_ID ./Caddyfile
# 将返回的文件 ID 填入 FILE_ID；这里使用 Caddy 2 的 Caddyfile 格式。
memories file exec VAULT_ID FILE_ID -- caddy run --config "{file}" --adapter caddyfile

Es gelten dieselben Berechtigungen wie bei file export: Entsperrung, Tresorzugriff und memories sudo im selben Terminal sind erforderlich. Mit --revision REVISION vor -- verwenden Sie eine historische Version. Auch beim Lesen von einem entfernten oder verwalteten Daemon läuft das Programm auf dem lokalen CLI-Rechner als aktueller Benutzer. Es wird direkt ohne Shell gestartet; Arbeitsverzeichnis, Umgebungsvariablen, Standardein-/ausgabe und Exitcode bleiben erhalten. Es gibt keine Ausführungsgrenze von fünf Minuten und keine JSON-Erfolgsantwort.

Temporäre Verzeichnisse und Dateien sind nur für den aktuellen Benutzer zugänglich (Unix-Berechtigungen 0700/0600, unter Windows Benutzer-ACLs). Das Programm sollte im Vordergrund laufen: Die temporäre Datei bleibt bis zum Ende des Kindprozesses erhalten und wird auch bei Startfehlern bereinigt. Unter Windows lösen Ctrl+C/Ctrl+Break und unter Unix SIGINT/SIGTERM/SIGHUP die Bereinigung beim Beenden aus; höchstens zehn Sekunden wird gewartet, bevor der direkte Kindprozess beendet wird. Unix-Signale werden an den Kindprozess weitergegeben; Windows-Konsolenereignisse empfangen Prozesse derselben Konsole.

Während der Ausführung liegt die Konfiguration im Klartext vor. Programm und Plugins können sie lesen und ausgeben; Ausgaben werden nicht bereinigt. Sperren des Tresors oder Widerrufen von Berechtigungen holt bereits ausgelieferte Kopien nicht zurück und stoppt das Programm nicht. Erzwungenes Beenden von Memories, Stromausfall oder Schließen der Windows-Konsole können temporäre Dateien zurücklassen. Löschen ist kein sicheres Überschreiben; vom Elternprozess losgelöste Hintergrundnachkommen werden nicht verwaltet. Jede Ausführung verwendet nur einen festen Snapshot namens config; es gibt keine automatischen Updates, reloads, Vorlagenerweiterung oder Importe verknüpfter Dateien. Relative Pfade werden nach den Regeln des Zielprogramms interpretiert. Für verknüpfte Konfigurationen und Zertifikate werden absolute Pfade empfohlen; geben Sie bei Bedarf das Konfigurationsformat ausdrücklich an.

Verwenden Sie kurze IDs aus Listen und Suchergebnissen unverändert. Lange UUIDs, vollständige Revisionshashes und IDs mit Präfix werden abgelehnt. Bei mehrdeutiger Eingabe schlägt der Befehl fehl; listen oder suchen Sie erneut.

Python ausschließlich lokal erfassen:

memories local-python
memories local-python --program /path/to/python

Der ausgewählte Interpreter wird im isolierten Modus ausgeführt; Version und Verzeichnis der ausführbaren Datei werden erfasst, Umgebungsvariablen nicht. Das Ergebnis wird in den Tresor „Dieses Gerät“ mit local_only geschrieben.

Suche und Antworten mit Quellen

Lassen Sie den Daemon zunächst dieselbe Konfiguration mit [rag] verwenden. Das Importieren von UTF-8-Text oder Markdown erstellt eine gewöhnliche Wissenskarte und gibt die erwartete Anzahl von Textblöcken zurück:

memories rag ingest VAULT_ID notes.md --title "研究笔记" --source "本地文件"
memories memory search VAULT_ID "中文 关键词"
memories rag search VAULT_ID "关键词" --mode bm25 --match-mode all

Optionen für rag search und rag ask:

Integrierte EmbeddingGemma-Gewichte installieren und Vektorindex im Arbeitsspeicher erstellen:

memories rag model-install
memories rag index VAULT_ID
memories rag status VAULT_ID
memories rag search VAULT_ID "这段文档在说什么" --mode vector
memories rag search VAULT_ID "找出证据" --mode hybrid --limit 8
memories rag ask VAULT_ID "根据证据概括"

model-install initialisiert keinen verschlüsselten Tresor. Die Gewichte werden standardmäßig unter models/embeddinggemma im ausgewählten Datenverzeichnis installiert. Lokale Inferenz läuft im Memories-Prozess und benötigt kein Ollama. Vektor- und Hybridsuche berechnen bei Bedarf auch Einbettungen nach, solange der Index noch nicht vollständig aufgebaut ist.

rag ask benötigt die Generierungsadresse aus der Konfiguration. Für reine lexikalische Suche verwenden Sie --mode bm25; sobald Fragen beantwortet werden, ist die Generierungsadresse weiterhin erforderlich. Ohne Belege wird der Generierungsdienst nicht aufgerufen und insufficient_evidence im Ergebnis ist wahr. [S1] in Antworten ist nur eine Quellenmarkierung dieses Ergebnisses. Zum Öffnen des Originals verwenden Sie die Asset-id aus dem Ergebnis, nicht den Textblockhash als Asset-ID:

memories memory read VAULT_ID ASSET_ID

Aus PDFs, DOCX und Binärdateien wird nicht automatisch Text extrahiert. Konvertieren Sie sie zuerst in UTF-8-Text und importieren Sie diesen. Importieren Sie vertrauliche Texte nicht als gewöhnliche Karten. Starten Sie nach Änderungen der Modellkonfiguration den Daemon neu.

Entfernte Einbettung, Generierung und Neusortierung werden unter [rag.embedding], [rag.generation] und [rag.rerank] konfiguriert. Für API-Schlüssel wird nur der Umgebungsvariablenname eingetragen, etwa api_key_env = "GEMINI_API_KEY"; der Schlüsselwert gehört in die Umgebung des Daemons. Ohne [rag.embedding] bleibt die Einbettung beim lokalen Modell. Gemini Embedding ist eine Online-API, nicht das offline arbeitende EmbeddingGemma.

Zugangsdaten und geschützte Karten erfassen und verwenden

Führen Sie zunächst im selben Terminal memories sudo aus.

Neue Zugangsdaten über verborgene Eingabe hinzufügen oder aus einer vorhandenen Datei importieren. Der Import löscht die Quelldatei nicht:

memories credential add VAULT_ID "API 令牌"
memories credential import VAULT_ID "SSH 身份" existing-private-key

Der Erfassungsbefehl memories catch entspricht memories credential catch. Ohne Quellenangabe wird eine verborgene Eingabe angefordert:

memories catch VAULT_ID "数据库密码"

Zum Lesen aus einer Pipeline verwenden Sie --stdin. --regex extrahiert einen eindeutigen Treffer; bei einer Erfassungsgruppe wird diese gespeichert, ohne Erfassungsgruppe der gesamte Treffer. Mit --json-pointer wählen Sie eine JSON-Zeichenfolge. Beide Optionen dürfen nicht kombiniert werden:

secret-tool | memories catch VAULT_ID "数据库密码" --stdin --regex "password=([^\r\n]+)"
memories catch VAULT_ID "API 令牌" --stdin --json-pointer /token < response.json
memories catch VAULT_ID "API 令牌" --exec secret-tool --json-pointer /token -- issue --format json

--exec PROGRAM startet das Programm direkt und erfasst die Standardausgabe, schließt die Standardeingabe des Kindprozesses und verwirft dessen Standardfehlerausgabe. Nach -- folgen Programmargumente. Speichern Sie keine echten Geheimnisse in Argumenten, regulären Ausdrücken oder Titeln. --timeout reicht von 1 bis 300 Sekunden, Standard: 30 Sekunden. Pipelineeingabe wartet ohne Zeitlimit bis EOF. Die Eingabegrenze beträgt 1 MiB. Das Erfolgsergebnis enthält nur die Zugangsdaten-ID. Mit --id CREDENTIAL_ID ersetzen Sie vorhandene Zugangsdaten.

Schlüssel im Tresor erzeugen. Private Schlüssel werden nicht ausgegeben:

memories credential generate VAULT_ID "笔记本 SSH"
memories credential generate VAULT_ID "笔记本 SSH" --algorithm rsa --bits 4096
memories credential generate VAULT_ID "数据库 CA" --kind tls-ca --algorithm rsa --subject memories-ca
memories credential generate VAULT_ID "数据库服务器" --kind tls --ca CA_ID --algorithm rsa --name db.example.test
memories credential public VAULT_ID KEY_ID

--kind kann ssh, tls-ca oder tls sein. --algorithm kann ed25519, rsa oder ecdsa sein. credential public gibt nur öffentliche SSH-Schlüssel oder TLS-Zertifikate zurück.

Zugangsdaten an ein Programm mit absolutem Pfad übergeben. Standardmäßig werden sie über die Standardeingabe eingespeist; --env erlaubt ausdrücklich eine Umgebungsvariable. Der SHA-256 des Programms muss interaktiv bestätigt oder zuvor mit --approve-digest genehmigt werden. Beide Ausgabekanäle des Kindprozesses werden unterdrückt:

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

Eine Ausführungsbindung bindet Zugangsdaten an den Fingerabdruck eines Programms, damit Programmieragenten sie ohne das sudo Ihres Terminals verwenden können. credential bind gh benötigt sudo und die Bestätigung USE: Es findet gh im PATH, erfasst SHA-256 und speichert die Bindung ausschließlich im lokalen verschlüsselten Zustand. Sie wird nicht synchronisiert und bei der Wiederherstellung einer Sicherung gelöscht. Die Bindung verfällt nach --hours Stunden (Standard: 8, höchstens 720) und funktioniert nur bei entsperrtem Speicher. Danach startet run --binding gh -- 参数 das Programm im aktuellen Verzeichnis, übergibt die Zugangsdaten in der angegebenen Umgebungsvariable und gibt die Ausgabe unverändert zurück, ersetzt darin jedoch alle Vorkommen der Zugangsdaten durch [REDACTED] (mit --suppress-output wird die Ausgabe verworfen). Der Befehl endet mit dem Exitcode des Programms:

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

--deny 词 lehnt Befehle ab, deren Nichtoptionsargumente diese Wörter in der angegebenen Reihenfolge enthalten. --ask 词 lässt den Hook vor der Ausführung eine Bestätigung einholen. Für gh werden standardmäßig auth, alias, extension (und die Aliasse extensions, ext) abgelehnt; für pr merge, repo delete und release delete wird eine Bestätigung verlangt. --no-default-rules deaktiviert dies. Regeln gleichen nur die eingegebenen Wörter ab; zuvor mit gh alias set definierte Aliasse werden nicht aufgelöst. Bis zum Ablauf der Bindung kann jedes unter Ihrer Identität laufende Programm das gebundene Programm mit den Zugangsdaten ausführen, diese aber nicht über memories selbst lesen. Das Programm, seine Erweiterungen und Kindprozesse können sie lesen; binden Sie daher nur vertrauenswürdige Programme. Bindungen ohne --credential und --env wenden nur Regeln an.

hook install --commands gh zeigt die Einträge, verlangt APPROVE und schreibt anschließend einen PreToolUse-Hook in die Claude-Code-Benutzereinstellungen. Will Claude Code in Bash oder PowerShell gh ... ausführen, ersetzt der Hook dieses Befehlswort durch memories run --binding gh --; die restliche Befehlszeile bleibt unverändert. gh in Umhüllungen wie $( ), Backticks, sh -c oder xargs wird mit Begründung abgelehnt; Heredoc-Inhalte und Befehlsersetzungen als Argumente (etwa --body "$(cat <<'EOF' ... EOF)") bleiben unberührt. Pipeline- oder umgeleitete Eingaben werden mit --stdin weitergegeben (höchstens 16 MiB). Da das Programm in der Daemon-Umgebung läuft, werden Präfixe wie NAME=value gh ... abgelehnt; verwenden Sie stattdessen Programmargumente. Erst zur Laufzeit expandierte Argumente ($var, Platzhalter) können nicht durch Regeln geprüft werden; der Hook verlangt zuerst eine Bestätigung. Nur wenn der gesamte Befehl aus Aufrufen gebundener Programme besteht, gibt der Hook ihn direkt frei. Werden weitere Programme ausgeführt oder Dateien geschrieben, bleibt die gewöhnliche Claude-Code-Bestätigung erforderlich. Halten zurückgelassene Hintergrundprozesse die Ausgabepipes offen, ist die Anzahl der lesenden Threads begrenzt; bei Überschreitung werden neue gebundene Ausführungen abgelehnt. Die eigenen deny-/ask-Berechtigungsregeln von Claude Code bleiben wirksam, sehen aber möglicherweise den umgeschriebenen Befehl. Tragen Sie sensible Unterbefehle daher in die Bindungsregeln ein. Gebundene Programme laufen außerhalb der Dienstsperre; ein langes gh run watch blockiert andere Clients nicht, aber die Grenze von 5 Minuten bleibt bestehen.

Erlaubte Hosts für Zugangsdaten einschränken und den Daemon eine HTTPS-Anfrage senden lassen, die nur den Statuscode zurückgibt:

memories credential allow-host VAULT_ID CREDENTIAL_ID api.example.com
memories credential http VAULT_ID CREDENTIAL_ID https://api.example.com/status

credential http verwendet ausschließlich HTTPS-Port 443, folgt keinen Weiterleitungen und übernimmt keine Proxys.

Auch geschützte Karten lesen Geheimnisse über verborgene Eingabe statt über Argumente:

memories card account VAULT_ID --title "示例邮箱" --email user@example.test --smtp smtp.example.test
memories card env VAULT_ID ./app.env --title "应用配置"
memories card token VAULT_ID --title "API 会话" --host api.example.test
memories card token VAULT_ID --title "浏览器会话" --host app.example.test --cookie
memories card request VAULT_ID TOKEN_CARD_ID https://api.example.test/session
memories card otp VAULT_ID --title "示例 OTP" --issuer Example --account user@example.test
memories card otp VAULT_ID --title "示例 HOTP" --issuer Example --account user@example.test --hotp --counter 0
memories card otp-import VAULT_ID --title "导入的 OTP" "otpauth://totp/Example:user@example.test?secret=GEZDGNBVGY3TQOJQGEZDGNBVGY3TQOJQ&issuer=Example"
memories card otp-import VAULT_ID --image ./ga-export.png --title "GA import"
memories card otp-code VAULT_ID OTP_CARD_ID

Für Konto-SMTP gilt standardmäßig SSL-Port 465, anpassbar mit --port und --no-ssl. Dies speichert nur die Konfiguration und versendet keine E-Mails. --cookie speichert die Tokenkarte als Cookie-Header. --method von card request ist standardmäßig GET und akzeptiert nur GET oder POST. OTP unterstützt --algorithm sha1|sha256|sha512, --digits und --period. --hotp wechselt zu HOTP; --counter ist der Anfangszähler, ohne Angabe 0. TOTP ignoriert den Zähler. otp-import akzeptiert einen URI als Argument; ohne URI und ohne --image liest es eine Zeile aus der Standardeingabe. Ein einzelnes Konto verwendet otpauth://. totp oder hotp im URI wird automatisch erkannt; ohne Typ ist ein URI mit counter HOTP, andernfalls TOTP. Google-Authenticator-Migration verwendet otpauth-migration://offline?data=... und kann mehrere Karten gleichzeitig erstellen. --image PATH dekodiert den ersten QR-Code vom Typ otpauth:// oder otpauth-migration:// im Bild und kann nicht zusammen mit einem URI verwendet werden. --title ist optional: Bei einer Karte ist es der Titel, bei mehreren das Titelpräfix; ohne Angabe lautet der Titel „Aussteller / Konto“. --id ersetzt nur eine Karte und ist bei Migrationsimporten mit mehreren Konten unzulässig. otp-code gibt einen kurzlebigen Prüfcode statt des Seeds zurück; bei HOTP enthält das Ergebnis den nächsten Zähler. Der oben gezeigte secret ist ein öffentlicher RFC-Testvektor; ersetzen Sie ihn nicht durch einen echten Seed.

Zum Ersetzen einer vorhandenen geschützten Karte verwenden Sie --id CARD_ID. Zugangsdaten-ID und Kartenlinks bleiben erhalten; nicht übergebene --alias / --notes / --category behalten ihre Werte, eine leere Zeichenfolge löscht sie. Gewöhnliches card put kann geschützte Referenzen nicht ersetzen. OTP-Titel können issuer / account bleiben; speichern Sie den Anzeigenamen separat in Alias und Notizen.

Ein exakt vorkommendes Geheimnis im Dokumenttext schützen. Die Bezeichnung besteht aus 1 bis 64 ASCII-Buchstaben, Ziffern, Unterstrichen oder Bindestrichen und darf im Dokument noch nicht verwendet sein:

memories memory protect-secret VAULT_ID DOCUMENT_ID API_KEY
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

protect-secret fordert das Geheimnis an. Beim Kopieren einer Dokumentreferenz ist --label erforderlich. Das Kopierergebnis enthält nur "copied": true. Windows verwendet die Systemzwischenablage, macOS pbcopy; Linux benötigt wl-copy unter Wayland oder xclip unter X11. Geschützte Konto-, Token-, Umgebungs- und OTP-Karten können auch direkt kopiert werden; bei OTP wird der Seed kopiert, nicht der Einmalcode.

Die mobile Anwendung bietet „Geschützte Karte“, „.env importieren“ und „Anmeldedaten importieren (CSV)“; TOTP oder HOTP lässt sich auch durch Einfügen eines otpauth://-URI importieren. „Schlüssel in Daten ersetzen“ und „Schlüssel kopieren“ im Dokumentmenü entsprechen den oben beschriebenen Operationen. „OTP erzeugen“ erstellt einen Einmalcode. Die mobile Anwendung importiert OTP-QR-Codes nicht per Kamera; verwenden Sie für OTP-Bilder und Migrations-URIs die obige Befehlszeile. Das Scannen beim Koppeln verwalteter Geräte ist ein eigener Ablauf; siehe Ende-zu-Ende-Geheimnisse zwischen Geräten.

Website-Anmeldedaten importieren und exportieren

Website-Anmeldedaten werden in geschützten login-Karten gespeichert (öffentliche Websiteadresse und Benutzername, Passwort als eigenständige Zugangsdaten) und üblicherweise stapelweise importiert/exportiert. Import und Export benötigen memories sudo und eine schreibberechtigte Rolle:

memories sudo
# 浏览器 CSV（Chrome/Edge/Brave，或 Firefox 的 about:logins）；自动识别表头。
memories login import VAULT_ID --from chrome passwords.csv
memories login import VAULT_ID --from firefox firefox-logins.csv --with-notes
# 直接读取 Firefox 配置文件（现代 key4.db，会提示输入主密码，没有则留空）。
memories login import VAULT_ID --from firefox-profile "/路径/Profiles/xxxx.default"
# Windows 凭据管理器的通用凭据（仅 Windows）。
memories login import VAULT_ID --from windows --filter github
memories login import VAULT_ID --from windows --all
# 之前导出的加密文件。
memories login import VAULT_ID --from memories logins.mlx

# 导出：便携加密文件（推荐）或浏览器兼容的 CSV。
memories login export VAULT_ID --format encrypted logins.mlx
memories login export VAULT_ID --format csv logins.csv

Stimmen Websitehost, Benutzername und Passwort mit einer vorhandenen Karte überein, wird der Eintrag übersprungen. Bei anderem Passwort wird ein Konflikt erfasst und eine weitere Karte erstellt; nur --update überschreibt. Fehlerhafte CSV-Zeilen werden übersprungen und mit Zeilennummer gemeldet. Pro Import sind höchstens 2000 Einträge zulässig. Die Browser-Spalte note wird nur mit --with-notes importiert, da Notizen in den gewöhnlichen Volltextindex gelangen. Direktes Lesen aus Firefox unterstützt moderne Schlüsselformate (Firefox 58 und neuer); exportieren Sie ältere Profile über about:logins als CSV. Das Lesen gespeicherter Browserpasswörter verändert den Browserspeicher nicht.

Verschlüsselter Export verwendet ein eigenes Passwort und lässt sich in jeden Tresor importieren. CSV-Export enthält Klartext und dient zum Rückimport in Browser oder andere Passwortmanager. Er ist nur in der lokalen CLI verfügbar, warnt vorab und schreibt in eine noch nicht vorhandene Datei, die nur der Eigentümer lesen darf. Zellen, die mit = + - @ beginnen, werden gegen Formelinjektion geschützt. Löschen Sie die Datei nach Gebrauch. Geräteexklusive Tresore können nicht exportiert werden.

Entfernte Sitzungen und Loopback-Proxys

Autorisieren Sie zuerst den Zielhost mit credential allow-host. Bei SSH muss außerdem der durch die Probe ermittelte Hostschlüsselfingerabdruck über einen vertrauenswürdigen Kanal abgeglichen werden:

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 sessions
memories remote run SESSION_ID -- uname -a
memories remote propose SESSION_ID -- uname -a
memories remote approve TICKET_ID
memories remote exec TICKET_ID
memories remote close SESSION_ID

remote run erledigt Vorschlag, interaktive Genehmigung und Ausführung in einem Schritt. Für getrennte Skriptschritte stellt remote propose die Anfrage in die Warteschlange und gibt ein Ticket zurück. remote approve genehmigt es (benötigt sudo, Ticket nur einmal verwendbar); anschließend führt derselbe privilegierte Aufrufer es mit remote exec aus.

Datenbanken verwenden standardmäßig TLS mit Hostnamenprüfung. --tls-ca CA_ID fügt eine PEM-CA aus dem Tresor hinzu. --no-tls deaktiviert TLS ausdrücklich. --database ist der MySQL-/PostgreSQL-Datenbankname oder der logische Redis-Datenbankindex:

memories remote open mysql --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 redis --vault VAULT_ID --credential CREDENTIAL_ID --host redis.example.test --user default
memories remote run SESSION_ID --op query -- SELECT 1

remote open unterstützt ssh, ftp, tcp, mysql, redis und postgres. FTP verwendet Dateioperationen, SSH- und Datenbanksitzungen verwenden exec oder query. Jede Anweisung wird zunächst vorgeschlagen und dann genehmigt. remote run verbindet Vorschlag, interaktive Genehmigung und Ausführung. Das Genehmigungswort lautet APPROVE. MCP kann entfernte Sitzungen weder öffnen noch genehmigen.

Loopback-Proxys lauschen auf 127.0.0.1. Der zurückgegebene command kann in einem Terminal auf dem Daemon-Rechner ausgeführt werden und enthält keine gespeicherten Passwörter oder privaten Schlüssel:

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

Proxyprotokolle sind ausschließlich ssh, mysql, redis und postgres. Optional ist --listen-port; 0 lässt das System den Port auswählen. Ebenfalls optional sind --certificate, --tls-ca, --tls und --no-tls. Jeder Prozess, der diesen lokalen Port erreichen kann, kann das autorisierte entfernte Konto verwenden. Sperren, automatische Tresorsperre bei Inaktivität, proxy stop und Beenden des Daemons schließen Listener und bestehende Verbindungen. Proxys gelten höchstens 30 Minuten; erlaubt sind höchstens vier Proxys mit jeweils höchstens 16 Verbindungen. MCP kann Proxys weder starten noch auflisten oder stoppen.

Kryptografische Aufgaben ausführen

E-Mail- und Signaturwerkzeuge müssen separat installiert werden. Importieren Sie Identität und Passwort als zwei getrennte Zugangsdaten. --credential, --password_id und --key-password sind Zugangsdaten-IDs, nicht die Geheimnisse selbst. --password und --password-id sind Aliasse von --password_id.

Verwenden Sie zunächst --dry-run. Es liest Eingaben und Werkzeuge, gibt den Plan und die approval-Zusammenfassung aus, benötigt keinen Daemon und schreibt keine Ausgabedateien. Führen Sie nach der Bestätigung im selben Terminal sudo und anschließend denselben Befehl ohne --dry-run aus. Für nichtinteraktive Ausführung verwenden Sie stattdessen --approve-digest DIGEST. Die Ausgabe muss ein neuer Pfad in einem vorhandenen Verzeichnis sein.

S/MIME verwendet OpenSSL. Für PKCS#12-Identitäten verwenden Sie --pkcs12. Verschlüsselung benötigt nur den öffentlichen Empfängerschlüssel, daher werden keine Identitätszugangsdaten übergeben:

memories crypto smime-sign --vault VAULT_ID --input message.eml --output signed.eml --credential IDENTITY_ID --password_id PASSWORD_ID --pkcs12 --tool openssl=/path/to/openssl --dry-run
memories crypto smime-encrypt --vault VAULT_ID --input signed.eml --output encrypted.eml --recipient recipient.pem --tool openssl=/path/to/openssl --dry-run
memories crypto smime-decrypt --vault VAULT_ID --input encrypted.eml --output decrypted.eml --credential IDENTITY_ID --password_id PASSWORD_ID --pkcs12 --tool openssl=/path/to/openssl --dry-run

OpenPGP benötigt das zusammengehörige Paar gpg und gpgconf. --identity ist der vollständige Fingerabdruck. Für die MSYS-Version von GnuPG aus Git for Windows verwenden Sie --msys-gpg:

memories crypto pgp-sign --vault VAULT_ID --input message.eml --output message.sig.asc --credential KEY_ID --password_id PASSWORD_ID --identity FULL_FINGERPRINT --tool gpg=/path/to/gpg --tool gpgconf=/path/to/gpgconf --dry-run
memories crypto pgp-encrypt --vault VAULT_ID --input message.eml --output message.eml.asc --recipient recipient.asc --identity FULL_FINGERPRINT --tool gpg=/path/to/gpg --tool gpgconf=/path/to/gpgconf --dry-run
memories crypto pgp-decrypt --vault VAULT_ID --input message.eml.asc --output decrypted.eml --credential KEY_ID --password_id PASSWORD_ID --tool gpg=/path/to/gpg --tool gpgconf=/path/to/gpgconf --dry-run

Android-Signierung erstellt kein Installationspaket und kontaktiert keinen App-Store. Der Pfad zu apksigner ist lib/apksigner.jar im SDK:

memories crypto android-apk --vault VAULT_ID --input unsigned.apk --output signed.apk --credential KEYSTORE_ID --password_id STORE_PASSWORD_ID --identity release --tool java=/jdk/bin/java --tool zipalign=/sdk/build-tools/35.0.0/zipalign --tool apksigner=/sdk/build-tools/35.0.0/lib/apksigner.jar --dry-run
memories crypto android-bundle --vault VAULT_ID --input unsigned.aab --output signed.aab --credential KEYSTORE_ID --password_id STORE_PASSWORD_ID --identity release --tool jarsigner=/jdk/bin/jarsigner --dry-run

Wenn Schlüsselpassphrase und Speicherpassphrase unterschiedlich sind, verwenden Sie --key-password KEY_PASSWORD_ID.

iOS-Signierung ist nur unter macOS verfügbar. Die Eingabe ist eine .app, die bereits das passende embedded.mobileprovision enthält:

memories crypto ios-app --vault VAULT_ID --input Unsigned.app --output Signed.app --credential APPLE_P12_ID --password_id PASSWORD_ID --identity CERTIFICATE_SHA1 --entitlements App.entitlements --tool openssl=/path/to/openssl --tool security=/usr/bin/security --tool codesign=/usr/bin/codesign --dry-run

Diese Befehle versenden keine E-Mails und veröffentlichen keine Anwendungen. MCP und die mobile Anwendung können sie nicht ausführen.

Geräte koppeln, synchronisieren und sichern

Gerätekopplung fügt ein neues Gerät derselben Person einer vorhandenen Identität hinzu. Mitgliedseinladungen weisen einer anderen Person eine Rolle in einem Tresor zu. Beide verwenden Anfrage- und Genehmigungsdateien, sind aber nicht austauschbar.

Das neue Gerät führt zuerst init mit eigenem Passwort aus und darf vor dem Beitritt keine Tresore besitzen. Danach:

memories sudo
memories device invite request.json

Übergeben Sie die Anfragedatei an ein vorhandenes Gerät. Genehmigen Sie erst nach Abgleich des vollständigen Einladungsfingerabdrucks auf dem anfragenden Gerät. Der Genehmigungsbefehl gibt den öffentlichen Schlüssel des genehmigenden Geräts zurück. Prüfen Sie diesen Schlüssel über einen vertrauenswürdigen Kanal, bevor das neue Gerät annimmt:

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

Führen Sie auf dem neuen Gerät im selben Terminal wie den Annahmebefehl erneut sudo aus, nehmen Sie die Genehmigung an und prüfen Sie die Geräteliste:

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

Die Anfrage verfällt nach 10 Minuten und ist nur einmal verwendbar.

Mitgliedschaft einer anderen Person in einem Tresor genehmigen:

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 member transfer VAULT_ID USER_PUBLIC_KEY
memories device revoke VAULT_ID DEVICE_PUBLIC_KEY

Für --role bei Einladungsgenehmigungen und das Rollenargument von member role verwenden Sie admin, editor oder reader, beschränkt durch die Rechte des Bedieners: Eigentümer verwalten Administratoren, Administratoren nur gewöhnliche Leser und Bearbeiter. Bearbeiter können schreiben, Leser können lesen und verwenden. Obwohl die CLI owner akzeptiert, verlangt die Tresorrichtlinie genau einen Eigentümer; Einladungen oder gewöhnliche Rollenänderungen können keinen weiteren Eigentümer hinzufügen. Zur Eigentumsübertragung führt der aktuelle Eigentümer memories member transfer VAULT_ID USER_PUBLIC_KEY aus. Das Ziel muss bereits Mitglied sein; der bisherige Eigentümer wird danach Administrator. Geräte müssen in jedem betroffenen Tresor widerrufen werden. Das Entfernen eines Mitglieds löscht keine Kopien, die es bereits besitzt.

Dateiaustausch ohne Relay:

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

Für Onlineübertragung führen Sie zuerst memories-relay hinter einem TLS-Reverse-Proxy aus und erzeugen dann mit sync room eine Raumnummer. Der Empfänger wartet zuerst, danach sendet der Absender:

memories sync room
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

Entfernte Relays akzeptieren nur wss://. ws:// ist nur für lokale Entwicklungsadressen zulässig. URLs dürfen keine Benutzernamen oder Passwörter enthalten. relay_url in der Konfiguration kann als Standardadresse dienen; --relay im Befehl überschreibt sie. Standard für --slot ist beim Senden a, beim Empfangen b. Erfolgreiches Senden bedeutet nur, dass das Relay das Paket erhalten hat, nicht dass die Gegenseite es importiert hat. Das Relay stellt keine Warteschlange für Offlinegeräte bereit. sync export/import und Relay-sync send/receive sind ausdrücklich vollständige Tresorübertragungen, keine Cloudobjektsynchronisierung und kein entferntes RPC.

Quarantäne anzeigen, Revisionen alter Epochen erneut in die aktuelle Epoche signieren und den lokalen Richtlinienzweig beibehalten, wenn beide Seiten gültige Eigentümeridentitäten besitzen:

memories sync quarantine VAULT_ID
memories sync reapply VAULT_ID REVISION
memories sync resolve-policy VAULT_ID packet.json --keep-local

Cloudkonten verwenden eine selbst registrierte OAuth-Anwendung. Entsperren Sie vor der Anmeldung den Tresor und führen Sie im selben Terminal sudo aus:

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 sync onedrive
memories cloud logout onedrive

cloud login unterstützt --no-browser und --port. 0 wählt automatisch einen lokalen Callback-Port. Statusausgaben zeigen keine Token. Abmelden löscht nur die lokale Autorisierung. cloud sync erneuert Token und lädt unveränderliche Chiffretexte über den verbundenen OneDrive- oder Google-Drive-Anwendungsordner hoch und herunter. Die mobile Anwendung bietet Cloudverbindungen und Synchronisierung im Vordergrund. Die Ende-zu-Ende-Verifizierung mit echten OneDrive- und Google-Drive-Konten ist noch nicht abgeschlossen. Mobile Hintergrundsynchronisierung ist nicht aktiviert. Legen Sie das Datenbankverzeichnis nicht in den Synchronisierungsordner eines Cloudlaufwerk-Clients.

Audit und Offlinesicherung:

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

Zur Wiederherstellung ist ein neues Datenverzeichnis erforderlich, in dem der Daemon gestartet werden muss:

memories --home NEW_DIRECTORY restore offline-backup.memories --name replacement
memories --home NEW_DIRECTORY sudo
memories --home NEW_DIRECTORY archive list
memories --home NEW_DIRECTORY archive history VAULT_ID
memories --home NEW_DIRECTORY archive read VAULT_ID REVISION
memories --home NEW_DIRECTORY archive audit VAULT_ID

Wiederhergestellt wird ein unabhängiger Tresor mit aktuellen Assets und Konfliktköpfen. Ursprüngliche Versionen, Löschmarkierungen und signierte Audits bleiben im schreibgeschützten Archiv. Historische Zugangsdatenwerte können weder über gewöhnliche noch über Archivschnittstellen ausgegeben werden. Geräteexklusive Tresore und Cloudtoken sind nicht in der Sicherung enthalten.

Desktop-Statusoberfläche öffnen

Doppelklicken Sie im Windows-Releasepaket auf memories-tray.exe neben memories.exe. Öffnen Sie unter macOS die paketierte Memories.app. Im Terminal:

memories tray
memories webui
memories --home /path/to/development-home webui --no-open --port 0
memories webui --open
memories-tray --home /path/to/development-home --no-open

tray öffnet das native Tray oder die Menüleiste mit Statusseite. webui öffnet nur das Browserdashboard und bleibt im Vordergrund. --port 0 wählt einen freien Loopback-Port. --no-open öffnet den Browser nicht automatisch. --open öffnet ihn auch dann, wenn automatisches Öffnen in der Konfiguration deaktiviert ist. --config und --lang gelten ebenfalls für beide Befehle und memories-tray.

Das Tray zeigt offline, Initialisierung erforderlich, gesperrt oder entsperrt und kann den Daemon starten. Es initialisiert und entsperrt nicht und erhöht keine Berechtigungen. Die Statusseite aktualisiert sich etwa alle zwei Sekunden und zeigt Tresoranzahl, Anzahl der Proxys und entfernten Sitzungen, konfigurierte Cloudanbietertypen sowie Upload-, Download- und ausstehende Synchronisierungszähler. Texte, Tresornamen, Zugangsdaten, Konten, Pfade oder Token werden nicht angezeigt. Beenden des Trays oder Unterbrechen von webui im Vordergrund stoppt nur die Statusseite, nicht den bereits laufenden Daemon.

Unter Linux verwenden Sie memories webui. Linux hat kein natives Tray; das Linux-Releasepaket enthält keinen Tray-Starter.

MCP-Berechtigungen erteilen und AI-Skill installieren

Dieser Abschnitt beschreibt zunächst gewöhnliches MCP: Ein AI-Client erhält Berechtigungen für einen Tresor, eine Dauer und einen Operationsumfang und übernimmt kein sudo des Terminals. Die Berechtigung wird in eine Datei geschrieben und nicht ausgegeben. Die Datei selbst ist ein Bearer-Nachweis und muss geschützt werden. Standard ist schreibgeschützter Zugriff. --scope read_write erlaubt Lesen und Schreiben gewöhnlicher Daten, --scope read_write_delete zusätzlich Löschen; --write ist die kompatible Kurzform von read_write. Die Dauer wird mit --minutes angegeben, im Beispiel 15 Minuten:

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

Konfigurieren Sie den stdio-MCP-Befehl des AI-Clients als memories mcp serve --grant-file ... und verwenden Sie dasselbe Datenverzeichnis wie der Daemon. Die Werkzeuge 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, ergänzt um die Persona-Werkzeuge im englischen Leitfaden zu Persona-Karten. workflow_card erstellt Schritt-Workflows, Checklistenvorlagen oder aus Vorlagen kopierte Aufgaben; workflow_update ändert Checklistenfelder oder führt Schritte weiter. Beide benötigen Schreibrechte; workflow_read und workflow_list nur Leserechte. Jeder Aufruf enthält die autorisierte Tresor-ID. memory_retrieve verwendet standardmäßig lokales BM25; vector und hybrid nutzen den im Daemon konfigurierten Einbettungsanbieter. memory_ask antwortet bei konfigurierter Generierungsadresse und lehnt Quellenverweise außerhalb der Suchbelege ab.

Gewöhnliches MCP umfasst keine privaten Erinnerungen, Dateien, Zugangsdaten, Prozessausführung, entfernten Sitzungen, Proxys, kryptografischen Aufgaben, Mitgliederverwaltung oder Desktopstatus. Auch --scope allow_all überschreitet diese Grenze nicht. Ausstellen, Auflisten und Widerrufen von Berechtigungen sowie Berechtigungsanfragen sind separate MCP-Werkzeuge und übernehmen ebenfalls kein sudo. Sperren macht diese Berechtigungen vorübergehend unbrauchbar; nicht abgelaufene werden nach Entsperrung wieder verfügbar. Die Protokollversion ist 2024-11-05. Karten mit Geheimnisreferenzen können mit dem aktuellen card_write nicht aktualisiert werden, da es die Referenzzuordnung nicht erhält. Bearbeiten Sie sie per CLI oder mobil.

Für unbeaufsichtigtes Lesen siehe Unbeaufsichtigte CLI/MCP. Dieser Weg verlangt ausdrücklich die Auswahl eines Schlüsselverwaltungsbackends, Eingabe von ENABLE und Passwortautorisierung, anschließend das Erstellen einer auf einen Tresor beschränkten Clientdatei. Verwenden Sie mcp serve-unattended --client-file PATH, nicht gewöhnliches mcp serve. Der Zugriff ist nur lokal und schreibgeschützt, umfasst jedoch private Daten, Originaldateien, Verlauf und ausdrücklich angeforderte Zugangsdaten im Klartext und übernimmt kein sudo. AI-Clients und ihre Logs können Geheimnisse speichern; Base64 ist keine Verschlüsselung. Manuelles Sperren verhindert den Zugriff dauerhaft bis zu einem passwortautorisierten unattended resume. Entfernte Transporte, Mobilgeräte und von Center verwaltete Speicher können ihn nicht verwenden.

memories unattended enable --backend windows-dpapi
memories unattended mint --vault VAULT_ID --client-file /private/dir/client.json
memories unattended list VAULT_ID --client-file /private/dir/client.json
memories unattended history VAULT_ID ASSET_ID --client-file /private/dir/client.json
memories unattended read VAULT_ID ASSET_ID --client-file /private/dir/client.json
memories unattended credential-bytes VAULT_ID CREDENTIAL_ID --client-file /private/dir/client.json
memories mcp serve-unattended --client-file /private/dir/client.json
memories unattended status
memories unattended resume
memories unattended revoke GRANT_ID
memories unattended disable

Backends sind windows-dpapi, macos-keychain, linux-secret-service oder das ausdrücklich auszuwählende, schwächer geschützte owner-file. Das Verzeichnis der Clientdatei muss bereits existieren und ausschließlich dem Eigentümer zugänglich sein; mint überschreibt keine vorhandenen Dateien. read und credential-bytes geben base64url-Bytes in Abschnitten zurück: Beginnen Sie mit --offset 0, verwenden Sie jeweils next der letzten Antwort als neues --offset und fixieren Sie mit --revision die zuerst zurückgegebene Revision. Sobald next null ist, verbinden Sie die dekodierten Bytes in Reihenfolge. list / history liefern höchstens 100 Einträge pro Seite. status, resume, revoke und disable benötigen ein entsperrtes Terminal mit sudo.

Den mitgelieferten Skill installieren. Die Installation öffnet keinen Tresor und konfiguriert kein MCP:

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

all umfasst Codex, OpenCode und Claude Code. claude-code ist ein Alias von claude. --project installiert in ein vorhandenes Projektverzeichnis. Verwenden Sie nach einem CLI-Upgrade --force, um abweichende zuvor installierte Inhalte zu ersetzen:

memories inject all --force

--force ersetzt nur SKILL.md. Identische Inhalte bleiben unverändert. Links auf Skilldateien oder -verzeichnisse werden abgelehnt.

Für ein Projekt eine AGENTS.md mit Memories-Bedienungsanweisungen oder ein Skillverzeichnis im Cursor-/Codex-Stil erzeugen, optional mit eingebetteter Kernzusammenfassung einer Persona-Karte. agents ist ein Alias von skill:

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 Markdown-Datei; --layout skill schreibt SKILL.md im Ausgabeverzeichnis (endet der Ausgabepfad bereits mit .md, wird diese Datei direkt geschrieben). Ohne --persona wird persona aus den Clientstandardwerten verwendet. Bei Generierung mit Persona wird die Karte über den Daemon gelesen und muss zuvor entsperrt werden; ohne Persona erfolgt die Generierung offline ohne Daemon. --force ersetzt vorhandene Dateien mit abweichendem Inhalt; --dry-run zeigt nur eine Vorschau ohne Schreibzugriff.

Clientstandardwerte

Nicht geheime Befehlszeilenstandardwerte werden in defaults.json unter dem Datenverzeichnis (--home / MEMORIES_HOME) gespeichert und gehören nicht zum verschlüsselten Tresorinhalt:

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

Explizite Argumente haben immer Vorrang. Persona-Unterbefehle, die Tresor und Asset akzeptieren (world-get, thing, append-event usw.), verwenden bei ausgelassenen Positionsargumenten die Standardwerte. persona import verlangt weiterhin die Tresor-ID vor dem Skillpfad.

Autorisierungszentrum (Center)

Center ist eine externe Autorisierungssteuerung, die Registrierungs- und Fähigkeitstickets an die Endpunkte verteilt. Sobald die Konfiguration irgendeinen Eintrag [[centers]] enthält, wird der Endpunkt von Center verwaltet: Lokales Bootstrap über init / restore und lokale MCP-Berechtigungen sind verboten; stattdessen werden von Center ausgestellte Tickets verwendet. Der Tresor wird weiterhin lokal mit dem Gerätepasswort entsperrt. Center erhält weder Tresorschlüssel noch Geheimnisse im Klartext. Listenertoken, Center-Signaturschlüssel und Verwaltungstoken gehören nicht in TOML.

# 管理员：生成写入配置的公钥并签发票据（或使用 memories-center HTTP 服务）
export MEMORIES_CENTER_SECRET="…"   # 32 字节，URL 安全 base64 或 64 位十六进制
memories center public-key
memories center issue-bootstrap --center corp --device-name laptop
memories center issue-grant --center corp --vault VAULT_ID --scope read --minutes 15

# 终端（守护进程已按含 centers 的配置运行）
memories center list
memories center enroll --ticket "$BOOTSTRAP_TICKET"
memories sudo
memories center import-grant --ticket "$GRANT_TICKET"

Berechtigungsumfänge (read, write, read_write, read_write_delete, allow_all und ihre Aliasse), Konfigurationsformat und Bedrohungsmodell beschreibt das englische Autorisierungszentrum.

Verwaltete Tresore (SaaS)

memories-center --data DIR (oder die Umgebungsvariable MEMORIES_CENTER_DATA) lässt Center einen vollständigen verwalteten Tresor betreiben: Der Server speichert den Store verschlüsselt mit einem Passwort des Betreibers und verwendet dieselben Dienstschnittstellen wie der Daemon. Ein einziger Konfigurationseintrag mit mode = "saas" versetzt den lokalen Daemon in den SaaS-Modus; dieser Center kontrolliert die Inhaltsoperationen (Token aus MEMORIES_CENTER_TOKEN). Administratoren können über /v1/admin/lock und /v1/admin/unlock entfernt sperren/entsperren und über /v1/admin/members Mitglieder verwalten. Verwaltete Daten sind für den Betreiber sichtbar und nicht Ende-zu-Ende-verschlüsselt. Anfragemetadaten liegen in DIR/requests.json, das Hashkettenaudit in DIR/audit.jsonl.

Autorisierungskette

Tresorrollen sind Owner, Admin, Editor und Reader. Nur Admin und höher dürfen Berechtigungen ausstellen oder delegieren. Zum Ausstellen genügt ein entsperrter Tresor ohne Terminalerhöhung; das Genehmigen von Rollenanfragen benötigt jedoch erhöhte Berechtigungen. Der Umfang darf die Rolle des Ausstellers (und übergeordnete Berechtigungen) nicht überschreiten, die Empfängerrolle darf nicht höher sein als die des Ausstellers, und center-admin darf kein Empfänger sein. Die Delegationstiefe beträgt höchstens 2 Ebenen. Ohne Umfang gilt read, nicht allow_all. Lokaler Daemon und verwalteter Center erlauben gleichzeitig höchstens 10000 gültige Berechtigungen.

Berechtigungsanfragen können an alle geeigneten Genehmiger gesendet oder mit --approver an einen bestimmten gerichtet werden. Genehmigen und Ablehnen ist möglich, eigene Anfragen dürfen nicht entschieden werden. Eine Genehmigung gibt kein Token zurück; der Antragsteller muss es einmalig abholen: memories request claim VAULT ID, memories center request claim ID, MCP request_claim oder POST /v1/requests/{id}/claim. Pro Antragsteller und Tresor sind höchstens 20 offene Anfragen erlaubt, pro Tresor insgesamt 200 (Center gibt HTTP 429 zurück). Offene sowie genehmigte, noch nicht abgeholte Anfragen verfallen nach 7 Tagen; abgeschlossene Anfragen bleiben 30 Tage erhalten.

memories access list VAULT          # 按级别列出成员、设备、待处理与已批准未领取的请求
memories grant list VAULT
memories request create VAULT --scope read --approver MEMBER_ID
memories request approve VAULT ID
memories request claim VAULT ID

Das Entfernen eines Mitglieds widerruft kaskadierend die von ihm ausgestellten Berechtigungen (Ungültigkeit anhand der Mitgliedsgeneration). Berechtigungen werden nur als Hash gespeichert; das Auditlog ist eine Hashkette. Siehe die englische Autorisierung.

Sprache auswählen

Die mobile Anwendung bietet Sprachmenüs auf dem Sperrbildschirm und in der Tresoroberfläche. Standardmäßig folgt sie dem System; manuelle Auswahl bleibt nach Neustarts erhalten.

Die CLI-Priorität lautet --lang, MEMORIES_LANG, gespeicherte Sprache, danach die erste nicht leere Variable LC_ALL, LC_MESSAGES oder LANG. Unter Windows wird bei Fehlen aller dieser Variablen auch die Betriebssystemsprache geprüft. Nicht erkannte Gebietsschemata fallen auf Englisch zurück. zh-CN und fr_FR.UTF-8 werden erkannt.

memories --lang zh --help
memories language zh
memories language
memories language system

Das Argument nach language kann entfallen, um gespeicherte und aktuell wirksame Sprache anzuzeigen. system löscht die Auswahl und folgt wieder dem System. Die gespeicherte Sprache ist nach --home getrennt und benötigt keinen Daemon. Befehlsnamen, Optionsnamen, JSON-Felder, Fehlercodes sowie USE und APPROVE werden nicht übersetzt. Benutzerinhalte ebenfalls nicht.

Entfernter Daemon (HTTP/WebSocket / Relay-RPC)

Der optionale tokenauthentifizierte HTTP-/WebSocket-Listener und WSS-Relay-RPC verwenden dieselben binären JSON-WebSocket-Frames (AuthFrame gefolgt von Wire), entsprechend dem lokalen IPC-Protokoll service::Request. RPC führt Befehle auf dem Speicher des entfernten Hosts aus und erstellt keine Tresorkopie beim Aufrufer. Für Kopienaustausch verwenden Sie sync, für Synchronisierung über dauerhafte Cloudobjektwarteschlangen in OneDrive/Google Drive cloud sync PROVIDER. Auch für RPC oder vollständige Tresorübertragung ist das Relay kein Offline-Asset-Speicher. Listenertoken dürfen nur über Flags oder Umgebungsvariablen bereitgestellt werden, nicht in TOML. Standardmäßiges unverschlüsseltes HTTP/WS benötigt keine Zertifikate; mit --tls-cert / --tls-key aktivieren Sie bei Bedarf HTTPS/WSS. Nach entferntem Entsperren/Berechtigungserhöhen bietet der Desktopdaemon dieselben vollständigen Operationen wie lokales IPC (Erhöhungsnamensräume ws:remote / relay:remote). Mobiles Share folgt weiterhin der FFI-Sperrliste. Details siehe Entfernter Daemon.

Das Relay kann außerdem Persona-Automatisierungswebhooks weiterleiten: POST /v1/persona/{room}/{vault}/{persona}/automation/trigger. Anfrageinhalt und Webhook-Token entsprechen denen des Daemons; das Relay leitet nur an den verbundenen Host weiter und startet keine ausgehenden POSTs.

Globale TLS-Optionen: --ca-file PATH (MEMORIES_CA_FILE) fügt ausgehenden TLS-Clients eine PEM-CA hinzu. --insecure überspringt Zertifikats- und Hostnamenprüfung, verwendet aber weiterhin TLS; nur für Entwicklung/selbst signierte Umgebungen, bevorzugt --ca-file verwenden.

memories daemon --listen http://127.0.0.1:7900 --listen-token "$TOKEN"
export MEMORIES_DAEMON=http://127.0.0.1:7900
export MEMORIES_DAEMON_TOKEN="$TOKEN"
memories status

Mobilen Modus auswählen und wechseln

Beim ersten Start wählen Sie einen Modus. Auch nach einem Upgrade von einer älteren Version ohne Moduseinstellung erscheint die Auswahlseite. Die App merkt sich die Auswahl und öffnet beim nächsten Start direkt den entsprechenden Modus.

Der Center-Modus bezeichnet hier einen selbst betriebenen verwalteten Dienst; auf dem Server muss memories-center --data DIR aktiviert sein. Er unterscheidet sich vom Autorisierungs-Center, das nur Geräte- und Berechtigungstickets ausstellt. Mobil müssen weder config.toml bearbeitet noch mode = "saas" gesetzt oder der lokale Tresor zuerst entsperrt werden; diese TOML-Einstellungen gelten für den Desktopdaemon.

Geben Sie als Center-Adresse nur den Serverursprung an, etwa https://center.example.com, ohne /v1/rpc, Abfrageparameter oder Benutzername/Passwort. Nicht-Loopback-Adressen müssen HTTPS verwenden; localhost auf dem Telefon bezeichnet das Telefon selbst. Der Dienstbetreiber stellt Mitgliedstoken bereit; mögliche Operationen hängen von Tresor, Rolle, Umfang und Gültigkeitsdauer ab. Verwaltungstoken des Betreibers können Mitgliedstoken für Inhaltszugriffe nicht direkt ersetzen.

Während der Nutzung wechseln

Der Doppelpfeil oben auf der Hauptseite bedeutet „Modus wechseln“ und ist vor und nach der Anmeldung verfügbar. Der Dialog markiert den aktuellen Modus; Auswahl eines anderen wechselt dorthin, Abbrechen erhält die aktuelle Sitzung. Bearbeitungsseiten müssen zuerst gespeichert oder verlassen werden; ungespeicherte Inhalte verlangen eine Bestätigung.

Wechseln lädt keine Tresordaten hoch, verschiebt, vereint oder löscht sie nicht. Trennen widerruft das Token nicht auf dem Server. Center- und SaaS-Adressen sowie Token werden getrennt im sicheren Systemspeicher abgelegt. Ältere Verbindungen werden nur in den passenden Modus migriert: die offizielle SaaS-Adresse zu SaaS, alle anderen zu Center.

Funktionsumfang der Modi

Der Einzelgerätemodus behält lokale Datenansicht, Suche, Bearbeitung, Sicherung/Wiederherstellung, Freigabe und Cloudverbindungen. Center / SaaS bieten Listen, Suche, Details, Bearbeiten, Erstellen und Löschen verwalteten Wissens sowie Genehmigung von Berechtigungsanfragen und Verwaltung gekoppelter Geräte. Nach Verbindung sehen Sie aktuellen Tresor und Berechtigungsumfang und verwalten Inhalte unter „Verwaltetes Wissen“. Neue Karten bieten derzeit keine Tags, Quellen oder Beziehungen; die Bearbeitung bestehender gewöhnlicher Karten unterstützt diese Felder und erhält weitere Metadaten. Gewöhnliche Erinnerungen verwenden den Texteditor. Strukturierte Konfigurationen, geschützte Karten, Typvorlagen und Ende-zu-Ende-Karten sind hier nur lesbar und benötigen zur Änderung spezielle Editoren.

Die Berechtigungsseite ist in „Offen“ und „Verlauf“ geteilt. Vor Genehmigung oder Ablehnung lassen sich Antragsteller, Tresor, Umfang, Dauer und vollständige Begründung prüfen; eine Bestätigung ist erforderlich. Auch nach Genehmigung holt der Antragsteller die Berechtigung separat ab. Der Verlauf enthält Bearbeitungen dieser Verbindung und serverseitig zurückgegebene genehmigte Anfragen, kein vollständiges Auditlog. Bei Verbindungsfehlern prüfen Sie Netzwerk, Zertifikat, Adresse, Mitgliedstoken und ob der eigene Center verwalteten Speicher aktiviert hat.

Mobiler verwalteter Modus (Hosted Center)

Die Suche erfolgt serverseitig und schließt private Inhalte, Zugangsdaten und Dateien aus. Nach Leeren der Suchbegriffe erscheint die Wissensliste; mit Leserecht sind darin private Karten sichtbar. Schreibgeschützte Konten sehen keine Änderungszugänge, reine Schreibkonten können direkt erstellen. Löschen benötigt Löschrechte und erneute Bestätigung. Fehlgeschlagenes Speichern erhält den Entwurf; Details werden erst nach serverseitiger Löschbestätigung geschlossen. Der aktuelle Speichervorgang bietet keine atomare Nebenläufigkeitsprüfung gegen eine erwartete Version; gleichzeitiges Bearbeiten derselben Karte kann die neuesten Felder anderer überschreiben.

Aktualisieren Sie bei App-Upgrades auch den selbst betriebenen Center, damit er /v1/session bereitstellt. Bei abgelaufener oder widerrufener Sitzung trennen Sie die Verbindung und verbinden erneut mit gültigem Token. Bei fehlenden Berechtigungen wenden Sie sich an den Dienstadministrator; bei nicht verfügbarem Dienst oder gesperrtem Tresor versuchen Sie es später erneut.

Center und SaaS verwenden gemeinsam die hosted_*-Schnittstellen von FFI memories_call: Verbinden, Anfrageliste und Genehmigung, Zugriffsliste, Trennen und eingeschränktes hosted_rpc. Die Verbindung wird durch hosted_status geprüft, entsprechend GET /v1/session; zurückgegeben werden aktueller Tresor, Umfang, Rolle, Ablaufzeit und Lese-/Schreib-/Löschfähigkeiten, keine Token. hosted_rpc unterstützt Auflisten, Lesen, Suchen, Löschen, Kartentypen, Wissenskartenerstellung sowie Feld- und Zugangsdatenoperationen; put unterstützt memory, card und credential. Vollständige Positivliste und Geräteschnittstellen siehe Mobile verwaltete Schnittstellen. Nicht jede FFI-Operation hat eine entsprechende Flutter-Seite.

Im verwalteten Modus kann der Server lesen: Der Store wird verschlüsselt auf Datenträger gespeichert, aber der Betreiber besitzt das Entsperrpasswort und kann verwaltete Inhalte lesen. Die App zeigt „Server kann lesen“. Aktive Token hält der Rust-Client im Speicher; Flutter speichert Verbindungsinformationen je Modus im sicheren Systemspeicher. Versiegelte Geheimnisse zwischen Geräten besitzen eine unabhängige Ende-zu-Ende-Schutzgrenze; siehe nächsten Abschnitt.

Ende-zu-Ende-Synchronisierung (E2E) von Geheimnissen zwischen Geräten

Gewöhnliche Inhalte auf einem verwalteten Center sind serverseitig lesbar. Für Geheimnisse, die der Server nicht sehen darf, koppeln Sie Geräte und senden versiegelte Umschläge (X25519-Verschlüsselung, Ed25519-Signatur des Absenders). Center speichert nur öffentliche Schlüssel und Chiffretext.

Kopplungsablauf: 1. Computer: memories device hosted init --backend … erzeugt eine Geräteidentität in der Schlüsselverwaltung des Systems. 2. Computer (Mitgliedstoken): memories device hosted pair --vault V. Center erstellt eine Berechtigungsanfrage mit Gerätefingerabdruck und gibt einen einmaligen Kopplungscode sowie QR-Code-Inhalt (einschließlich Center-id) zurück. Der Kopplungscode verfällt nach 5 Minuten. Der im Terminal (stderr) ausgegebene QR-Code enthält ebenfalls den einmaligen Kopplungscode und kann vom Telefon gescannt werden; stdout-JSON bleibt unverändert. Erneutes Koppeln eines aktiven Geräts liefert 409; nach Widerruf kann derselbe Schlüssel erneut gekoppelt werden. 3. Telefon (Administrator): Kopplungscode eingeben/scannen, um den öffentlichen Geräteschlüssel abzurufen (nur einmal abrufbar; zu viele Fehler führen zur Begrenzung). 4. Das Telefon genehmigt über /v1/requests/{id}/approve und fügt einen mit seinem Ed25519-Schlüssel signierten Gerätenachweis (attestation) bei. 5. Computer: memories device hosted claim --request-id ID holt die Geräteberechtigung einmalig ab. Das Token wird in der Schlüsselverwaltung des Systems gespeichert; Center speichert nur den Hash. 6. SAS vergleichen: Das Telefon zeigt ihn vor der Genehmigung gruppiert an, etwa 123 456. Nach Genehmigung muss memories device hosted sas --pairing-id P auf dem Computer dieselben Ziffern anzeigen. Bei Abweichung Gerät widerrufen und erneut koppeln.

Der mobile Scanner lehnt QR-Codes ab, die keine Memories-Kopplungscodes sind, deren Center-id nicht zur aktuellen Verbindung passt oder deren Gerätefingerabdruck abweicht. Berechtigungen: Android CAMERA (Kamera ist optional), iOS NSCameraUsageDescription. Bei verweigerter Kameraberechtigung fordert das Telefon zur Aktivierung in den Systemeinstellungen auf; manuelle Codeeingabe bleibt möglich. CLI und Telefon wandeln Center-Statuscodes in handlungsorientierte Hinweise um (404 abgelaufen/verwendet/anderer Center, 409 bereits bearbeitet oder gekoppelt, 403 keine Berechtigung oder Gerät widerrufen, 422 e2e-Inhalt abgelehnt, 429 zu viele Anfragen).

SAS-Definition: Die ersten 8 Bytes von SHA-256("memories/device-sas/v1\0" ‖ 手机公钥 ‖ "\0" ‖ 电脑公钥 ‖ "\0" ‖ pairing_id) werden als Big-Endian-Ganzzahl interpretiert, modulo 10^6 genommen und mit Nullen auf 6 Stellen aufgefüllt. Eine Abweichung bedeutet ersetzte öffentliche Schlüssel; widerrufen Sie sofort.

Regeln: Geräteberechtigungen sind an Gerät und Mitgliedsgeneration gebunden, Delegationstiefe ≤ 2. Geräte dürfen keine Berechtigungen ausstellen oder Anfragen genehmigen. Mitgliedsänderungen machen Geräte ungültig und löschen ihre Umschläge. Karten mit e2e: true lehnen Klartextgeheimnisse auf verwaltetem Center ab. Zugriffslisten enthalten Geräte. MCP bietet device_list und sealed_reveal, das ausdrücklich erklärte Absicht (intent: "reveal_plaintext" + Begründung) benötigt.

Bedrohungsmodell: Center kann versiegelte Geheimnisse nicht lesen, sieht aber Metadaten und kann Umschläge zurückhalten. Widerruf kann bereits an Geräte ausgelieferten Klartext nicht zurückholen – wechseln Sie nach Widerruf das Geheimnis an seiner Quelle.

E2E-Härtung (P2)

• e2e-Markierung kann nicht unbemerkt entfernt werden: Sobald eine Karte e2e: true hat, werden Schreibvorgänge zum Entfernen der Markierung abgelehnt (422). Nur eine Owner-Berechtigung (keine Geräteberechtigung) darf sie durch einen Schreibvorgang ohne jegliche Geheimnisse entfernen.
• OTP-Parameter: Versiegelte OTPs können Base32-Seeds (SHA1/6 Stellen/30 Sekunden) oder vollständige otpauth://totp/...-URIs sein. sealed-get --otp berücksichtigt algorithm (SHA1/SHA256/SHA512), digits (6/8) und period (30/60) daraus. device hosted pair gibt den Kopplungs-QR-Code im Terminal (stderr) aus.
• Neuverschlüsselung nach Widerruf: Widerrufen eines Geräts löscht dessen Umschläge und markiert betroffene Karten als needs_rotation (sichtbar in sealed-Listen, /v1/sealed/rotation, Zugriffslisten und der mobilen Neuverschlüsselungsseite). Ausgelieferter Klartext kann nicht zurückgerufen werden. Wechseln Sie zuerst das Geheimnis an der Quelle und wählen Sie dann mobil „Für alle Geräte neu verschlüsseln“; dies sendet nur an aktuell genehmigte Geräte und entfernt die Markierung.
• Mobile Identitätswiederherstellung: Center speichert niemals die mobile Identität. Bei der ersten Erstellung wird einmalig ein Wiederherstellungscode angezeigt (Base32 aus 32 Bytes Seed + 2 Bytes Prüfsumme, Gruppen zu je 4 Stellen). Schreiben Sie ihn ab; „Mit Wiederherstellungscode wiederherstellen“ stellt dieselbe Identität wieder her.
• Identitätsrotation: „Zu neuem Telefonschlüssel migrieren“ erzeugt eine neue Identität und übermittelt einen gemeinsam mit altem und neuem Schlüssel signierten Rotationsdatensatz (nur Administratormitglieder dürfen ihn übermitteln; mindestens ein Gerät muss dem alten Schlüssel bereits vertrauen). Die CLI fixiert bei erster Nutzung den öffentlichen Schlüssel des genehmigenden Telefons (hosted-device-trust.json) und akzeptiert nur Signierende, die von dieser Wurzel über eine verifizierte Rotationskette erreichbar sind.
• Hardwarespeicherung: Der mobile Seed wird mit den stärksten integrierten Optionen von flutter_secure_storage gespeichert: iOS/macOS-Schlüsselbund passcode (nur lokal, keine Synchronisierung, Gerätepasswort erforderlich); Android-Keystore-Umhüllung mit biometrischer oder Geräteauthentifizierung, resetOnError: false. Einschränkung: Für Signieren/Verschlüsseln muss der Seed weiterhin in den Anwendungsspeicher gelangen (Secure Enclave/StrongBox unterstützen X25519/Ed25519 nicht). Geschützt wird nur die Speicherung im Ruhezustand.
• Transparenzlog: Center führt ein nur anhängendes, hashverkettetes Gerätelog (Kopplung, Genehmigung, Identitätsrotation, Widerruf), GET /v1/devices/log. memories device hosted log --verify prüft Kette, alle Signaturen und ob das Log den zuletzt geprüften Kettenkopf fortsetzt (hosted-device-log.json).

Mobile Biometrie und Gerätesperre

Nach Entsperren des Speichers im Einzelgerätemodus können Sie im Menü „Mehr“ die Option „Mit Biometrie/Gerätesperre entsperren“ aktivieren. Dies verlangt zunächst eine Systemauthentifizierung. Dieser Sicherheitsschalter gilt auch für sensible Operationen wie verwaltete Genehmigungen.

• Android: Verwendet den System-BiometricPrompt (Fingerabdruck/Gesicht) mit Rückfall auf Geräte-PIN, Muster oder Passwort. Das Speicherpasswort für schnelles Entsperren wird unter einem an Android Keystore gebundenen Schlüssel gespeichert, der Benutzerautorisierung verlangt (setUserAuthenticationRequired) und beim Hinzufügen oder Entfernen von Fingerabdruck/Gesicht automatisch ungültig wird (setInvalidatedByBiometricEnrollment(true)).
• iOS: Verwendet Face ID/Touch ID (mit Rückfall auf Gerätepasswort). Der Schlüsselbundeintrag ist nur nutzbar, wenn ein Gerätepasswort eingerichtet ist.
• Geschützte Operationen: Speicher entsperren, Zugangsdaten im Klartext anzeigen oder kopieren, geschützte Karten verwenden/OTP erzeugen, gekoppelte Geräte genehmigen, verwaltete Anfragen genehmigen, Versiegeln (seal) und erneut Versiegeln (re-seal).
• Änderung biometrischer Informationen: Die App meldet ungültige Schlüssel ausdrücklich; Speicher und Daten werden nicht gelöscht. Nach Authentifizierung mit Gerätezugangsdaten und einmaliger Eingabe des Speicherpassworts wird der Schlüssel neu erstellt.
• Keine Biometrie oder deaktivierter Schalter: Ohne verfügbare Biometrie/Gerätesperre oder bei ausgeschaltetem Schalter bleibt der bisherige Passwortablauf. Das Ausschalten löscht gespeicherte Schnellentsperrinformationen.

Neue Inhalte erstellen (mobil)

Neue Erinnerungen, Zugangsdaten und verwaltete Center-Einträge verwenden denselben Editor. Dateiimport ist möglich (Dateiname als Standardtitel, änderbar). Konfigurationsinhalte wie .env wechseln automatisch zur mehrzeiligen Festbreitendarstellung (auch manuell umschaltbar). Der Name darf zunächst leer bleiben; beim Speichern wird er zuerst aus dem Dateinamen, dann aus der ersten nicht leeren Textzeile abgeleitet. Erst wenn er weiter leer ist, wird eine Eingabe verlangt.

Wissenskarten verwenden ein Vollbildformular mit festem Speicherknopf unten. „Text bearbeiten“ öffnet den gemeinsamen Texteditor mit Dateiimport, Handschrift und Scannen. Erinnerungen und Wissenskarten schließen erst nach erfolgreichem Speichern; bei Fehler bleibt der Entwurf für einen erneuten Versuch erhalten, doppelte Übermittlung wird verhindert. Überschreiben vorhandenen Textes durch Import und Verlassen ungespeicherter Inhalte erfordern Bestätigung. Entwürfe liegen nur im Arbeitsspeicher und werden nach Hintergrundsperre nicht wiederhergestellt. Beim Bearbeiten lokaler Karten und verwalteter gewöhnlicher Karten bleiben Tags, Quellen, Beziehungen und benutzerdefinierte Felder erhalten. Verwaltetes Erstellen bietet nur Metadaten, die die aktuelle Erstellungsschnittstelle akzeptiert.

Zugangsdaten mit mehreren Feldern

Ein Zugangsdatenobjekt kann mehrere unabhängige, jeweils leere Felder enthalten: Benutzername/Konto, Passwort, OTP (otpauth://-URI oder base32-Seed und Parameter), API Key, URL, Notizen und benutzerdefinierte Felder (als geheim markierbar). Passwort, OTP, API Key und geheime benutzerdefinierte Felder liegen ausschließlich im verschlüsselten Inhalt. Benutzername, URL, Notizen und nicht geheime benutzerdefinierte Felder sind direkt sichtbar.

memories credential set VAULT [ASSET] --username 我 --url https://example.com --password --otp --field 团队=core --secret-field PIN
memories credential show VAULT ASSET
memories credential get VAULT ASSET --field username
memories credential get VAULT ASSET --field password --reveal
memories credential copy VAULT ASSET --field api_key
memories credential otp VAULT ASSET
memories credential migrate VAULT ASSET

Geheime Werte werden ausschließlich verborgen eingegeben, nicht als Befehlszeilenargumente. Ältere Einfeldzugangsdaten bleiben direkt lesbar: otpauth:// oder Titel mit Präfix OTP: werden OTP zugeordnet, Einträge mit HTTP-Authentifizierung oder erlaubten Hosts einem API Key, die übrigen einem Passwort. Die erste Änderung mit credential set (oder credential migrate) schreibt das strukturierte Format; alte Versionen bleiben im Verlauf, Daten gehen nicht verloren. Bisherige Funktionen mit nur einem Geheimnis (HTTP-Einspeisung, Ausführungsbindung, Kopieren ohne --field) verwenden das „Hauptgeheimnis“: zuerst Passwort, danach API Key, OTP und das erste geheime benutzerdefinierte Feld.

Mehrfeldzugangsdaten: MCP, verwalteter Center und Ende-zu-Ende-Synchronisierung

• MCP credential_fields (Leserecht) gibt nur nicht geheime Felder und Namen geheimer Felder zurück. credential_reveal (allow_all-Berechtigung) benötigt intent: "reveal_plaintext" und Begründung; Rückgabe und Audit erfolgen feldweise.
• Verwalteter Center: Ende-zu-Ende-Zugangsdaten (e2e) speichern im Center nur Beschreibungen; geheime Felder liegen ausschließlich in versiegelten Geräteumschlägen.
• Gekoppelte Geräte: memories device sealed-get --vault V --card C --field password --reveal; --otp erzeugt einen Prüfcode.
• Telefon: Neue Zugangsdaten verwenden ein gegliedertes Formular (Anmeldung, Einmalcodes, API, Mehr, benutzerdefinierte Felder); alle Felder dürfen leer bleiben. Kopieren geheimer Felder und Anzeigen aktueller Prüfcodes mit Countdown erfordern Systementsperrung.