Memories

Memories / Dokumentation

Auf dieser Seite

Desktop-Tray und WebUI

Die Tray-App für Windows und die Menüleisten-App für macOS bieten einen schnellen Überblick über den lokalen Memories-Daemon. Sie verwenden ein gemeinsames eingebettetes Status-Dashboard und einen eingeschränkten Editor für gewöhnliche Karten, ohne externe Schriftarten, Skripte oder Analysedienste. Das Dashboard unterstützt Englisch, Chinesisch, Japanisch, Deutsch und Französisch und passt sich an schmale Fenster an.

Die Statusdarstellung bleibt schreibgeschützt. Im entsperrten Zustand nimmt der Karteneditor eine Tresor-ID entgegen und bietet eine Typauswahl, typisierte Felder, Umbenennen und Entfernen sowie eine Änderung der Reihenfolge per Drag-and-drop und die Erstellung wiederverwendbarer Vorlagen. Sein authentifizierter, auf den Ursprung geprüfter POST /api/cards leitet über die zugehörige CLI ausschließlich gezielt zugelassene Karten und Typen weiter. Er kann weder entsperren noch Berechtigungen erhöhen, Programme ausführen oder vertrauliche Werte offenlegen. Für vertrauliche Vorgänge ist eine native Verifizierung über die mobile App oder CLI erforderlich; im Browser gibt es keine Einrichtung von Biometrie oder PIN. Siehe Kartentypen.

Starten

  • Windows: Entpacken Sie die Release-ZIP-Datei und doppelklicken Sie auf memories-tray.exe. Lassen Sie die Datei neben memories.exe liegen. Das Startprogramm öffnet kein Konsolenfenster.
  • macOS: Öffnen Sie Memories.app aus dem macOS-Paket. Die App erscheint in der Menüleiste, ohne Dock-Fenster. Das Anwendungspaket enthält die zugehörige CLI.
  • Im Terminal: memories tray öffnet den nativen Tray und das Dashboard; memories webui öffnet nur das Browser-Dashboard und bleibt im Vordergrund. Linux kann webui verwenden; die native Tray-Unterstützung ist auf Windows und macOS beschränkt.
memories --home /path/to/development-home tray
memories --home /path/to/development-home webui --no-open --port 0
memories-tray --home /path/to/development-home --no-open

--home / MEMORIES_HOME verwendet denselben Speicher wie die CLI. Ohne abweichende Vorgabe verwendet das Startprogramm storage_dir aus der ausgewählten Konfiguration oder das übliche benutzerspezifische Memories-Verzeichnis. --config PATH / MEMORIES_CONFIG wählt eine TOML-Datei aus; siehe Konfiguration. --port 0 (der Standardwert) wählt einen freien Loopback-Port; ein ausdrücklich angegebener Port muss ebenfalls frei sein. Der im Vordergrund ausgeführte webui-Befehl gibt seine lokale Capability-URL einschließlich eines Fragment-Tokens aus. --no-open unterdrückt das automatische Öffnen des Browsers. Der Tray-Menüpunkt Status-Dashboard öffnen kann es später öffnen, auch wenn in der Konfiguration desktop.open_browser = false gesetzt ist; --open überschreibt diese Einstellung ausdrücklich. --lang wählt die Sprache des Trays; der Browser folgt zunächst seiner eigenen Spracheinstellung und bietet eine Sprachauswahl.

Status und Dienstlebenszyklus

Das Tray-Menü meldet die Zustände offline, Einrichtung erforderlich, gesperrt oder entsperrt. Daemon starten startet den Daemon der zugehörigen CLI, wenn er nicht verfügbar ist. Dabei wird weder der Speicher initialisiert oder entsperrt noch eine Erhöhung der Berechtigungen angefordert. Verwenden Sie wie gewohnt memories init, memories unlock und memories sudo im Terminal.

Die Seite aktualisiert sich alle zwei Sekunden. Im entsperrten Zustand zeigt sie die Anzahl der Bibliotheken, aktiven Proxys und Remote-Sitzungen; die konfigurierten Cloud-Anbieterarten; die Anzahl ausstehender Uploads und Downloads; angewendete und abgelehnte Übertragungen; sowie Bibliotheken, die auf eine Synchronisierung warten. Die Statusdarstellung zeigt keine Erinnerungstexte, Bibliotheksnamen, Zugangsdaten, Kontoidentitäten, Dateipfade oder Tokens. Bibliotheks- und Synchronisierungsdetails werden gelöscht, wenn der Daemon gesperrt wird oder nicht mehr verfügbar ist. Das Abfragen des Status hält den Tresor nicht entsperrt.

Die zuletzt angezeigten Änderungen sind Beobachtungen, die gemacht wurden, während die aktuelle Browserseite geöffnet war, und kein dauerhaftes Sicherheits-Auditprotokoll. Ein Offline-Status kann bedeuten, dass der Daemon gestoppt ist, länger als die Prüffrist beschäftigt ist oder inkompatibel ist. Aktualisieren Sie CLI und Daemon gemeinsam und starten Sie den Daemon nach der Aktualisierung neu.

Tray beenden entfernt das Symbol und beendet den Listener dieses Dashboards. Der Daemon läuft weiter, auch wenn er über das Menü gestartet wurde. Bei der WebUI im Vordergrund schließt Ctrl+C ihren Listener. Es wird kein automatischer Start bei der Anmeldung eingerichtet. Separate Starts verwenden separate Ports und Tokens. Um ein Dashboard nach einem Neustart erneut zu öffnen, verwenden Sie das Tray-Menü anstelle einer alten URL aus den Lesezeichen.

Grenzen des Browserzugriffs

Das Dashboard ist ausschließlich an 127.0.0.1 gebunden und für denselben Computer vorgesehen. Jeder Start verwendet ein neues zufälliges Zugriffstoken. Der Browser entfernt es aus der Adressleiste und speichert es nur für die Sitzung des Tabs. Statusanfragen benötigen dieses Token und müssen die Host/Origin-Prüfungen bestehen. Der Editor für gewöhnliche Karten verwendet dieselben Prüfungen und eine abgeschlossene Liste zulässiger Vorgänge; es gibt keine HTTP-Endpunkte zum Entsperren, zur Erhöhung von Berechtigungen, zur Bereitstellung von Zugangsdaten, zur Befehlsausführung oder für generisches IPC. Das beim Start ausgegebene JSON meldet read_only: false, status_read_only: true und card_editor: true, um Schreibzugriffe auf Karten von der schreibgeschützten Statusdarstellung zu unterscheiden. Siehe Sicherheit.

Build und Paketierung

cargo build --workspace --release --locked erstellt memories-tray zusammen mit CLI, Relay und FFI. Windows-Pakete werden aus einem sauberen, committeten Checkout erstellt:

pwsh -File scripts/package-windows.ps1

Auf einem macOS-Rechner mit Rust, Xcode Command Line Tools und Python 3:

bash scripts/package-macos.sh

Das macOS-Skript erstellt den Build für die Architektur des Rechners (Apple Silicon oder Intel) und paketiert Memories.app, CLI-/Relay-/FFI-Dateien, alle von Git erfassten Dateien unter docs/, Schriftlizenzen, ein Build-Manifest mit Einträgen für jede Datei sowie eine Archivprüfsumme. Es signiert oder notarisiert die App nicht für die Verteilung. Windows-Builds validieren nicht das Laufzeitverhalten unter macOS. Unter Validierung erfahren Sie, was für die einzelnen Releases tatsächlich geprüft wurde.

Auf einem Linux-GNU-Rechner erstellt bash scripts/build-linux.sh den Release-Build des Workspaces; bash scripts/package-linux.sh erstellt aus einem sauberen, committeten Checkout ein CLI-/Relay-/FFI-Archiv im Format .tar.gz. Siehe die Linux-Voraussetzungen. Verwenden Sie memories webui für das Dashboard; das Linux-Paket enthält das nicht unterstützte native Tray-Startprogramm nicht.