Memories Produktbeschreibung

Memories ist ein verschlüsseltes System für Erinnerungen, private Dateien und Zugangsdaten. Standardmäßig werden Daten lokal verschlüsselt; die Schlüssel bleiben auf den Geräten des Benutzers. Der optionale gehostete Center speichert Inhalte in einem verschlüsselten Serverspeicher, dessen Betreiber den entsperrten Klartext lesen kann; als Ende-zu-Ende gekennzeichnete Geheimnisse werden weiterhin nur zwischen Geräten entschlüsselt. Das Kommandozeilenprogramm heißt memories, das zustandslose WebSocket-Relay memories-relay, die Autorisierungszentrale memories-center und die von der mobilen Anwendung über die C-ABI aufgerufene lokale Bibliothek memories_ffi.

Dies ist eine Entwicklungsversion mit Speicherformatversion 1. Die Version des installierten Programms lässt sich mit memories --version anzeigen. Das Repository enthält ausführbaren Code und Sicherheitsregressionstests. Eine unabhängige kryptografische Prüfung oder Anwendungssicherheitsprüfung hat noch nicht stattgefunden. Bestandene Tests sind keine Sicherheitszertifizierung für den Produktionsbetrieb.

Die englische Dokumentation bleibt im Repository verfügbar: README.md und SECURITY.md im Stammverzeichnis sowie die thematischen Leitfäden unter docs/. Dieser Text beschreibt das aktuell implementierte Produktverhalten und stellt unfertige Fähigkeiten nicht als verfügbar dar.

Zuerst die gewünschte Aufgabe wählen

Standardmäßig liegen durchsuchbares Wissen, clientübergreifende Persona-Daten und geschützte Geheimnisse auf den eigenen Geräten des Benutzers, mit Autorisierung pro Tresor. Cloud-Laufwerke speichern Chiffretext, das Relay verbindet online verfügbare Geräte. Ein separat aktivierter gehosteter Center speichert entschlüsselbare Inhalte auf dem Server, wie unten beschrieben.

Kernkonzepte

Alle Wissenskarten unterstützen Kartentypen und benutzerdefinierte Felder: Notizen, Kontakte, Links, Codeausschnitte, Checklisten, Daten und Ereignisse, Zugangsdaten sowie wiederverwendbare Vorlagen innerhalb des Tresors. Felder unterstützen Validierung, Sortierung und Umbenennung; sensible Werte sind standardmäßig verborgen und erfordern zur Anzeige eine ausdrückliche Autorisierung und Überprüfung.

unlock entsperrt den lokalen Speicher und erlaubt gewöhnliche Operationen im Berechtigungsumfang; memories sudo erstellt mit demselben Passwort eine kurze Sitzung mit erhöhten Rechten für private Inhalte, Dateien, Zugangsdaten und sensible Verwaltungsoperationen. Dies sind keine Betriebssystemadministratorrechte und die Tresorberechtigungen werden nicht umgangen.

Gewöhnliches MCP wird nach Tresor, Laufzeit und Lese-/Schreibumfang autorisiert, übernimmt keine erhöhten Terminalrechte und erlaubt keinen Zugriff auf private Inhalte oder Zugangsdaten. Daneben gibt es ausdrücklich aktiviertes unbeaufsichtigtes CLI/MCP: ausschließlich lokal und schreibgeschützt, aber mit Zugriff auf private Inhalte, Originaldateien und ausdrücklich angeforderten Zugangsdaten-Klartext autorisierter Tresore. Dies ist nicht das Standardverhalten gewöhnlichen MCP; empfangende Clients und Protokolle können Geheimnisse behalten.

Implementierte Fähigkeiten

Tresore, Erinnerungen und Wissenskarten

Benutzer initialisieren einen Speicher mit einem lokalen Passwort und erstellen darin Tresore. Gewöhnliche Erinnerungen und Wissenskarten lassen sich schreiben, lesen, suchen, in ihrer Historie anzeigen und löschen. Karten unterstützen Tags, Quellen, Aliasse, Anmerkungen, Kategorien, gerichtete Beziehungen und Rückverweise sowie eine Graphansicht. Wissensnetzkarten (brain) sind strukturierte Wissenskarten mit Klartextzusammenfassung und typisierten, auch tresorübergreifenden Links; die Zusammenfassung ist im Rahmen der Tresorberechtigungen durchsuchbar und wird nicht zum geschützten Geheimnis erhoben. Persona-Karten speichern produktübergreifenden Identitätskerntext und zugehörige Archive (Tagebücher, Vereinbarungen usw.) und erlauben das Anhängen von Verhaltensereignissen; die Tresorkopie ist die maßgebliche Quelle. Workflow-Karten speichern geordnete Schritte und deren Status in Revisionen; Checklistenvorlagen erfassen zugewiesene Personen, Übersicht und Ziele, können in Aufgaben kopiert und mit anderen Workflows oder archivierten Erinnerungen verknüpft werden. Listen können nach Typ oder Kategorie gefiltert oder gruppiert werden; häufig verwendete Tresore, Personas, Typen usw. können als Clientstandard gespeichert werden. Private Dateien lassen sich importieren und exportieren. Ausdrücklich als privat markierte Inhalte sind erst nach lokaler Rechteerhöhung zugänglich und werden nicht in die gewöhnliche Suche aufgenommen.

Befehle, MCP und mobile Clients verwenden gewöhnliche kurze hexadezimale IDs, üblicherweise sechs Zeichen, etwa 0b0668. IDs haben kein Typpräfix und kennzeichnen keine Geheimhaltungsstufe. Bestehende IDs mit acht Zeichen bleiben gültig. Bei Kollisionen werden zurückgegebene IDs um jeweils zwei Zeichen verlängert, bis maximal 16 Zeichen. Öffentliche Geräteschlüssel und Sicherheitsfingerabdrücke werden nicht verkürzt.

Die Oberflächensprachen umfassen Englisch, vereinfachtes Chinesisch, Japanisch, Deutsch und Französisch. Mobile Anwendung und CLI können eine manuelle Auswahl speichern oder wieder der Systemsprache folgen.

Lokal können auch die Version und das Verzeichnis der ausführbaren Datei des Python-Interpreters im Tresor „Dieses Gerät“ gespeichert werden. Dieser Tresor ist nicht Teil von Geräteautorisierungspaketen, Sicherungen oder Synchronisierung.

Retrieval

Die gewöhnliche Suche segmentiert chinesischen Text und unterstützt mehrere Schlüsselwörter. Erweitertes Retrieval bietet für autorisierte gewöhnliche Erinnerungen und Wissenskarten Chunking, BM25, EmbeddingGemma-Vektoren im Prozess, hybride Rangfolge und Antworten mit Quellenverweisen. Modellgewichte werden separat durch memories rag model-install installiert oder über die Konfiguration aus einem lokalen Verzeichnis geladen. Alternativ können vom Kunden konfigurierte Endpunkte für Embeddings, Generierung und optionales Reranking verwendet werden. Zugangsdaten, private Inhalte und Datei-Assets werden nicht ins Retrieval aufgenommen.

Neben bestehender Suche und Lese-/Schreiboperationen bietet MCP memory_retrieve und memory_ask. KI-Clients können diese Werkzeuge über den mitgelieferten Skill verwenden. Skills lassen sich in Benutzer- oder Projektverzeichnisse von Codex, OpenCode und Claude Code installieren; memories skill generate kann außerdem AGENTS.md oder ein Skill-Verzeichnis mit Persona-Übersicht für ein Projekt erzeugen. MCP bietet auch Workflow- und Persona-Werkzeuge. Organisationen mit zentraler Autorisierung können einen Center konfigurieren. Im Ticketmodus stellt der Center Registrierungs- und MCP-Autorisierungstickets aus; Inhalte bleiben in den eigenen Speichern der Geräte.

Zugangsdaten und geschützte Karten

Zugangsdaten werden über verdeckte Eingabe, Pipes, die Standardausgabe von Befehlen, reguläre Ausdrücke oder JSON-Pointer erfasst und verschlüsselt gespeichert. SSH-Schlüssel oder TLS-Zertifikate können im Speicher erzeugt, öffentliche Schlüssel oder Zertifikate exportiert, Zugangsdaten anhand einer Host-Allowlist verwendet oder in einen Unterprozess mit genehmigtem Fingerabdruck injiziert werden. Der HTTPS-Adapter sendet Bearer-Token ausschließlich an erlaubte Hosts und liefert nur den Statuscode zurück.

Dokumente können exakte Schlüssel im Haupttext durch {{secret:标签}} ersetzen. Gewöhnliches Lesen, Suche und MCP sehen nur diese Referenz. Nach Autorisierung lässt sich der aktuelle Wert in die Systemzwischenablage kopieren, ohne ihn auszugeben.

Geschützte Karten speichern eine durchsuchbare Zusammenfassung und separate Zugangsdaten in demselben Commit:

TOTP und HOTP unterstützen SHA-1, SHA-256 und SHA-512 sowie 6 oder 8 Stellen. Der TOTP-Zeitraum beträgt 30 oder 60 Sekunden. HOTP verwendet einen persistenten Zähler, der bei jeder Codegenerierung im selben Commit um eins erhöht wird. Die CLI importiert einzelne otpauth://totp/... oder otpauth://hotp/... sowie Google Authenticators otpauth-migration://offline?data=.... card otp-import --image liest diese beiden URI-Arten mit einem reinen Rust-Decoder aus QR-Code-Bildern. Einmalcodes erfordern lokale Rechteerhöhung; die Codes selbst werden nicht im Audit protokolliert. Suche und MCP generieren keine Codes und geben keine Seeds zurück.

Der Daemon kann SSH-, FTP-, TCP-, MySQL-, Redis- und PostgreSQL-Sitzungen halten. Jeder Befehl wird zuerst vorgeschlagen, dann mit APPROVE genehmigt und anschließend einmal ausgeführt. SSH, MySQL, Redis und PostgreSQL können außerdem einen ausschließlich auf 127.0.0.1 lauschenden Loopback-Proxy öffnen, sodass lokale Programme Verbindungen herstellen können, ohne gespeicherte Passwörter oder private Schlüssel zu erhalten.

Kryptografische Aufträge für E-Mail und Anwendungen

memories crypto verwendet Zugangsdaten aus dem Speicher und vom Benutzer ausgewählte lokale Werkzeuge für S/MIME- und OpenPGP-Signierung, Verschlüsselung und Entschlüsselung sowie Android-APK/AAB-Signierung. Unter macOS können auch iOS-.app-Pakete mit bereits vorhandenem Provisioning-Profil signiert werden. Der Plan lässt sich vorab ansehen; die tatsächliche Ausführung erfordert lokale Rechteerhöhung und die Genehmigung des exakten Plan-Digests. Diese Operationen versenden keine E-Mails und veröffentlichen keine Anwendungen. MCP und mobile FFI können sie nicht aufrufen.

Rollen, Berechtigungen und Berechtigungsanträge

Tresorrollen sind Reader, Editor, Admin und Owner. Ihre maximal ausstellbaren Umfänge sind jeweils read, read_write, read_write_delete und allow_all. Ohne Umfangsangabe gilt read. Reader und Editor können keine Berechtigungen ausstellen. Admin und Owner können ausstellen und weiterdelegieren; lokal muss der Tresor entsperrt sein, Terminalrechteerhöhung ist nicht erforderlich. Eine Berechtigung darf weder die Rolle des Ausstellers noch den Umfang der vom Aufrufer gehaltenen Berechtigung überschreiten, nicht tresorübergreifend gelten und läuft 1–60 Minuten; Delegation ist auf zwei Ebenen begrenzt. Der Empfänger muss bereits Tresormitglied sein und darf keine höhere Rolle als der Aussteller haben. Höchstens 10000 Berechtigungen dürfen gleichzeitig gültig sein; lokaler Daemon und gehosteter Center verwenden dieselbe Grenze. Token erscheinen nur einmal beim Ausstellen oder Abholen; im Speicher liegen nur Hashes. Sperren pausiert Berechtigungen, widerruft sie aber nicht. Berechtigungen werden weder synchronisiert noch gesichert.

Jedes aktuelle Mitglied kann für sich einen größeren Umfang beantragen. Lokal können auch Rollen beantragt werden; Anträge beim gehosteten Center betreffen nur den Umfang. Eine Genehmigung erfasst lediglich die Grenze und stellt kein Token aus; der Antragsteller holt es danach einmal mit seinen Mitgliedszugangsdaten ab. Antragsteller können ihren eigenen Antrag weder genehmigen noch ablehnen. Maximal offen bleiben 20 Anträge pro Person und Tresor sowie 200 pro Tresor. Nach 7 Tagen werden sie ungültig, 30 Tage nach der Entscheidung gelöscht.

Gewöhnliches MCP bietet entsprechende Autorisierungswerkzeuge, übernimmt weiterhin keine erhöhten Terminalrechte und erlaubt keinen Zugriff auf private Inhalte oder Zugangsdaten. Die lokale mobile FFI stellt weder Berechtigungsverwaltung noch Berechtigungsanträge bereit.

Gehosteter Center und versiegelte Geheimnisse

Der Center im Ticketmodus stellt ausschließlich Registrierungs-, MCP-Autorisierungs- und Entsperrtickets aus. Entsperrtickets erlauben nur lokales Entsperren mit dem geräteeigenen Passwort und gewähren weder sudo noch erhöhte MCP-Rechte.

Im gehosteten Modus betreibt memories-center --data einen verschlüsselten Serverspeicher. Ist genau ein mode = "saas" konfiguriert, werden Inhaltsanfragen des Daemons an diesen Center weitergeleitet; der lokale Speicher ist dann nicht mehr das Inhaltsbackend. Das Administratortoken des Betreibers verwaltet Sperren, Entsperren und Mitglieder und kann nicht direkt zum Lesen oder Schreiben von Inhalten verwendet werden. Gehostete Inhalte sind für den Betreiber sichtbar.

Für Geheimnisse, die der Server nicht sehen darf, werden zuerst CLI und das Telefon des Tresoradministrators gekoppelt; anschließend werden die Geheimnisse in versiegelte Umschläge gelegt. Das Telefon kann einen 5 Minuten gültigen Kopplungs-QR-Code scannen oder einen Kopplungscode manuell eingeben und Fingerabdruck sowie 6-stellige SAS prüfen. Der Center speichert nur öffentliche Schlüssel und Chiffretext. Geräte können keine Berechtigungen ausstellen oder genehmigen. Widerruf löscht die Umschläge für dieses Gerät; bereits zugestellter Klartext lässt sich nicht zurückholen. Das Geheimnis muss zuerst ersetzt und anschließend erneut für die weiterhin genehmigten Geräte versiegelt werden.

Dies ist ein anderer Weg als die Gerätekopplung lokaler Tresore. Lokale Kopplung verwendet weiterhin Einladungen, Fingerabdruckprüfung und Genehmigungsdateien, keine Kamera. Auch OTP-otpauth-QR-Codes lassen sich nicht mit der Telefonkamera importieren; die CLI verwendet weiterhin card otp-import --image.

Geräte, Cloud und Wiederherstellung

Gerätekopplung ist für neue Geräte derselben Person gedacht: Nach Initialisierung mit eigenem Passwort treten sie über Einladung, Fingerabdruckprüfung und Genehmigung der bestehenden Identität bei. Mitgliedseinladungen gelten anderen Personen: Sie gewähren eine Rolle im angegebenen Tresor innerhalb der Rollengrenze des Genehmigenden, machen die andere Person aber nicht zum eigenen Gerät. Admin kann Admin, Editor und Reader verwalten, Owner weder hinzufügen, entfernen noch ändern und keine Geräte widerrufen. Jeder Tresor hat genau einen Eigentümer; Einladungen können keinen weiteren hinzufügen. Der aktuelle Eigentümer muss mit memories member transfer VAULT_ID USER_PUBLIC_KEY das Eigentum an ein bestehendes Mitglied übertragen und wird danach Administrator. Gerätewiderruf gilt pro Tresor und ist ausschließlich dem Eigentümer erlaubt.

Tresore lassen sich als verschlüsselte Dateien exportieren oder online vollständig über ein eigenes WebSocket-Relay übertragen. Das Relay speichert keinen Asset-Klartext und puffert nicht für offline verfügbare Geräte. Gleichzeitige Bearbeitungen behalten mehrere Köpfe und erfordern ausdrückliche Auflösung. Unbekannte Schreibvorgänge aus abgelaufenen Epochen werden quarantänisiert und anschließend lokal neu signiert.

Desktopclients können sich mit einer selbst registrierten OAuth-Anwendung bei OneDrive oder Google Drive anmelden. Token werden lokal verschlüsselt gespeichert und sind nicht Teil von Sicherungen oder Geräteaustausch. memories cloud sync lädt unveränderliche Chiffretextobjekte über die jeweiligen Anwendungsordner hoch und herunter.

Diese drei Wege haben unterschiedliche Zwecke: sync export/import und Relay-sync send/receive sind ausdrücklicher Austausch vollständiger Tresore; cloud sync PROVIDER synchronisiert mit Cloudobjekten und persistenten Warteschlangen; Remote-Daemon-RPC führt Operationen auf dem Host aus und importiert den Tresor nicht in den lokalen Speicher des Aufrufers. Das Relay bietet keinen Offlinespeicher; die Validierung der Cloudsynchronisierung mit echten Konten ist weiterhin unvollständig.

Sicherungen verwenden ein separates Passwort. Eine Wiederherstellung erstellt in einem neuen Datenverzeichnis einen unabhängigen Tresor und bewahrt die ursprüngliche signierte Historie in einem schreibgeschützten Archiv.

Desktop, Telefon und KI-Clients

Windows bietet ein Tray, macOS eine Menüleistenanwendung. Beide und memories webui unter Linux öffnen eine lokale schreibgeschützte Statusseite mit Sperrstatus, Tresoranzahl, Verbindungsanzahl und Cloudsynchronisierungswarteschlange, ohne Tresorinhalte anzuzeigen. Die Statusseite lauscht nur auf 127.0.0.1.

Android- und iOS-Clients arbeiten über denselben Rust-Dienst und bieten lokale Volltextsuche, Dateiauswahl, Mitgliedsgenehmigungsdateien, Online-Relay-Übertragung, Historie und Audit. Ein lokaler Faktor im sicheren Plattformspeicher ergänzt das Passwort. Optionale Biometrie oder Gerätesperre entsperrt nur den lokalen Speicher und übergibt keine Geräteschlüssel an den Center. Beim Wechsel in den Hintergrund werden Berechtigungen gelöscht und Inhaltsdialoge geschlossen. Android verhindert Screenshots, iOS verdeckt die Vorschau im App-Umschalter.

Beim ersten Start kann die mobile Anwendung zwischen Standalone, Center und SaaS wählen; diese Modi lassen sich auch auf der Hauptoberfläche wechseln. Standalone verwendet einen lokalen verschlüsselten Datenspeicher; Center verbindet sich mit einem kundeneigenen gehosteten Server; SaaS verbindet sich fest mit https://memories.ivjn.us. Die letzten beiden erfordern keinen vorherigen lokalen Speicher, speichern jeweils Dienstadresse und Mitgliedstoken und verschieben beim Wechsel keine Daten.

Center / SaaS bietet gehostete Wissenslisten, Suche, Details, Bearbeitung gewöhnlichen Wissens, Erstellung und bestätigtes Löschen sowie Genehmigung von Berechtigungsanträgen und Verwaltung gekoppelter Geräte. Nur-Lese-Konten können browsen, Nur-Schreib-Konten können erstellen, und Löschen erfordert die entsprechende Berechtigung; strukturierte und Ende-zu-Ende-Karten müssen mit speziellen Editoren geändert werden. Der gehostete Store ist zwar auf Datenträger verschlüsselt, aber der Betreiber besitzt das Passwort und kann Inhalte lesen; die Oberfläche kennzeichnet dies als „Server kann mitlesen“. Kopplungs-QR-Codes werden mit der Kamera gescannt; bei verweigertem Kamerazugriff kann stattdessen der Kopplungscode eingegeben werden. Fehler beim Bearbeiten behalten den aktuellen Entwurf für einen erneuten Versuch; das Verlassen ungespeicherter Inhalte erfordert Bestätigung. Hintergrundsperren löscht Entwürfe. Schritte siehe Auswahl und Wechsel des mobilen Modus.

Derzeit nicht verfügbar

Folgendes wurde noch nicht als nutzbare Fähigkeit ausgeliefert:

• Validierung von Zustimmung, Aktualisierung, Abmeldung, Zusammenführung zweier Geräte, Offlinewiederholungen und Widerruf mit echten OneDrive- oder Google-Drive-Konten. Desktopanmeldung und cloud sync sind implementiert und mit lokalen Fixtures getestet; die Validierung echter Konten bleibt eine Freigabebedingung.
• Eine mobile Oberfläche für modellgestütztes Retrieval. Mobil gibt es weder Modellkonfiguration noch Modellinferenzoberfläche. Vektor- und hybrides Retrieval sowie Fragen mit Quellenverweisen verwenden den konfigurierten Desktopdaemon. Mobil verfügbar sind verbesserte Schlüsselwortsuche und BM25-Retrieval.
• Ein natives Linux-Tray. Linux kann CLI, Daemon, Relay, FFI-Bibliothek und memories webui verwenden. Ein natives Tray gibt es derzeit nur unter Windows und macOS.
• Mobile Hintergrundsynchronisierung. Diese Version aktiviert sie nicht.
• OTP-Import mit der Telefonkamera. Gehostete Gerätekopplung kann Kopplungs-QR-Codes scannen. otpauth:// und otpauth-migration:// verwenden weiterhin die CLI memories card otp-import --image PATH oder direkt übergebene URIs. Die Telefonkamera kann diese beiden OTP-QR-Code-Arten nicht lesen.

Außerdem ist Online-Relay-Synchronisierung eine ausdrückliche vollständige Tresorübertragung, keine automatische inkrementelle Synchronisierung; sie entspricht nicht dem Cloudobjektpfad von cloud sync. Das Relay kann keine Pakete für offline verfügbare Geräte aufbewahren. Cookie-Ablauf, JWT-Aktualisierung und automatische Anmeldung sind nicht implementiert.

Komponenten

Bedienungsschritte siehe Benutzeranleitung. Grenzen von Speicherung, Autorisierung, Retrieval, Cloudsynchronisierung und Desktopstatus siehe Technische Dokumentation.