Kartentypen und benutzerdefinierte Felder

Wissenskarten in Memories unterstützen geordnete, typisierte Felder zusätzlich zu ihrem bestehenden Titel, Dokumentinhalt, ihren Tags und Links. Die integrierten Typen sind note, contact, link, snippet, checklist, event und credential. Ein Typ stellt anfängliche Felder bereit und schränkt nicht ein, welche zusätzlichen Felder eine Karte enthalten darf.

Schema

Content.card_type ist eine optionale Zeichenfolge: der Name eines integrierten Typs oder die ID einer benutzerdefinierten Vorlage. Content.fields ist ein geordnetes Array:

{"id":"work-email","name":"Work email","kind":"email","value":"name@example.com"}

Feld-IDs bleiben bei Umbenennungen und Änderungen der Reihenfolge stabil. Unterstützte Feldarten:

null bedeutet leer (oder maskiert bei einem sensiblen Feld). Auswahlarten erfordern ein nicht leeres options-Array mit eindeutigen Einträgen; bei anderen Arten muss options entfallen. Eine Karte hat höchstens 64 Felder mit eindeutigen IDs sowie begrenzten Namen und Werten.

Verschlüsselung und Autorisierung

Jede Revision verschlüsselt den vollständigen Content mit der bestehenden Tresorverschlüsselung. Sensible Werte gewöhnlicher Karten werden aus fields entfernt und im internen field_body gespeichert, einem base64url-kodierten strukturierten Inhalt innerhalb dieser verschlüsselten Revision, analog zu Zugangsdateninhalten. Base64url selbst ist keine Verschlüsselung. field_body wird bei normalen Lese-, Auflistungs- und Anzeigeoperationen niemals zurückgegeben, und sensible Feldwerte erscheinen als null. Dokumentinhalte bleiben unverändert und durchsuchbar; sensible Werte werden weder im Dokumentinhalt noch im Abrufcache abgelegt. Diffs zeigen nur Deskriptoren und nicht sensible Felder.

Ein gezielter Aufruf von card_fields mit reveal: true erfordert eine verifizierte CLI-/Mobil-Berechtigungserhöhung oder eine MCP-Capability mit allow_all. Die Auslieferungsabsicht wird vor der Rückgabe von Klartext im Audit protokolliert und dauerhaft gespeichert. MCP-Capabilities erben niemals eine Berechtigungserhöhung des Terminals. Die Anzeige typisierter Felder auf Mobilgeräten erfordert zusätzlich eine erfolgreiche biometrische/PIN-Prüfung des Systems, auch wenn die optionale Schnellentsperrung deaktiviert ist; abgebrochene oder nicht verfügbare Prüfungen rufen keine sensiblen Werte ab. Der Browsereditor auf dem Desktop besitzt bewusst keinen Endpunkt zum Anzeigen von Geheimnissen oder Passwörtern; verwenden Sie für sensible Werte die verifizierte native App oder CLI.

Wiederverwendbare Vorlagen

Vorlagen sind private, verschlüsselte, signierte Kartenrevisionen mit type_template: {id, name, fields}. Sie verwenden den bestehenden Revisionsverlauf, die Tresor- Autorisierung, Konfliktbehandlung und verschlüsselte Geräte-/Cloud-Synchronisierung statt einer unsignierten separaten Datenbank. Sie werden aus gewöhnlichen Kartenlisten und Abrufen ausgeschlossen. Integrierte Typen können weder geändert noch gelöscht werden. Eine benutzerdefinierte Vorlage kann aus einer bestehenden Karte erstellt werden; sensible Standardwerte sind immer maskiert. Das direkte Erstellen einer Vorlage mit einem sensiblen Standardwert ungleich null wird abgelehnt.

Das Aktualisieren oder Löschen einer Vorlage schreibt bestehende Karten nicht um. Karten behalten ihre eigenen Felder und können nach dem Löschen ihrer Vorlage weiterhin bearbeitet werden.

CLI

Starten Sie den Daemon mit demselben dedizierten Home-Verzeichnis, das die Clients verwenden:

memories daemon
memories type list VAULT
memories type create VAULT Project --from-card CARD
memories type show VAULT TYPE
memories type update VAULT TYPE Project --fields template-fields.json
memories type delete VAULT TYPE
memories card create VAULT --title Ada --type contact
memories card put VAULT --title Notes --type note --input notes.md
memories card field add VAULT CARD Team --id team --kind text --value Core
memories card field add VAULT CARD Status --kind single_select --option Open --option Done
memories card field set VAULT CARD team Platform
memories card field rename VAULT CARD team "Working team"
memories card field mv VAULT CARD team 0
memories card field rm VAULT CARD team
memories card field list VAULT CARD
memories sudo
memories card field add VAULT CARD Key --kind sensitive
memories card field list VAULT CARD --reveal

Sensible Werte werden über verborgene Terminal-Eingabeaufforderungen eingegeben, niemals als Befehlszeilenwerte. Zahlen, Kontrollkästchen und Mehrfachauswahlwerte verwenden JSON-Syntax. Verwenden Sie die kurzen IDs, die die CLI bei Auflistung und Anzeige zurückgibt, einschließlich der IDs benutzerdefinierter Typen. --fields akzeptiert ein JSON-Feldarray.

Daemon, FFI und MCP

Die gemeinsame JSON-/C-ABI unterstützt type_list, type_show, type_create, type_update, type_delete, card_create, card_fields und card_field. card_field.operation verwendet action: add|remove|reorder|rename|set mit dem jeweiligen Feld, der ID, dem nullbasierten Index, dem neuen Namen oder Wert. Beim Speichern nativer Formulare wird auch replace verwendet, um ein geordnetes Feldarray atomar zu speichern und dabei maskierte bestehende sensible Werte zu erhalten. Diese Operationen hängen signierte Revisionen an und behalten die ursprüngliche Asset-Art bei.

MCP-Tools verwenden dieselben Namen für Vorlagen, card_fields für eine maskierte Einsicht und card_field_add|remove|reorder|rename|set für Änderungen. card_field_reveal erfordert eine einzelne field-ID, intent: "reveal_plaintext", einen kurzen reason und den Geltungsbereich allow_all. MCP kann keine Auslieferung sämtlicher Geheimnisse einer Karte anfordern. Normale Schreibvorgänge erfordern einen Schreib-Geltungsbereich; das Löschen eines Typs erfordert einen Lösch-Geltungsbereich. Änderungen sensibler Werte erfordern eine unabhängig verifizierte MCP-Capability mit allow_all; dadurch wird weder eine Sitzung mit erhöhten Terminalberechtigungen erstellt noch werden private gewöhnliche Karten offengelegt.

Flutter verwendet die bestehende JSON-ABI memories_call: Es ist keine Änderung der ABI-Symbole nötig. Der generische Editor umfasst die Typauswahl, Eingaben je Feldart, das Umbenennen und Entfernen von Feldern sowie das Ändern der Reihenfolge durch Ziehen. Der gehostete Einstieg verwendet dasselbe Formular und behält den Warnhinweis zur Lesbarkeit durch den Server bei.

Gehostete und geräteversiegelte Karten

Hosted-SaaS-RPC stellt diese Operationen innerhalb des Tresors und Geltungsbereichs des Bearer-Tokens bereit. Für den Server lesbare gehostete Karten verwenden weiterhin die Tresorverschlüsselung im Ruhezustand. Eine e2e-Karte darf weder sensible Felder ungleich null noch einen internen field_body enthalten; sowohl rohe Put-Operationen als auch Feldänderungen lehnen sensible Klartextwerte ab. Nicht sensible Deskriptoren können bearbeitet werden, ohne sensible Werte an Center zu senden.

Das mobile Versiegelungsformular für gekoppelte Geräte sendet ausschließlich einen verschlüsselten Umschlag. Generische Karten verwenden diesen Umschlag-Klartext, der auf dem Client aufgebaut wird:

{"memories.card":1,"meta":{"card_type":"contact","fields":[
  {"id":"key","name":"Key","kind":"sensitive","value":null}
]},"body":{"text":"notes","sensitive":{"key":"value"}}}

Center erhält den Umschlag, nicht diesen Klartext. memories device sealed-get --vault V --card C --field key --reveal liest ein einzelnes Feld auf einem vertrauenswürdigen gekoppelten Gerät. Ältere Umschläge für rohe Geheimnisse und strukturierte Zugangsdaten werden weiterhin unterstützt.

Kompatibilität

Fehlende Typ- und Feldmember werden mit Standardwerten deserialisiert. Bestehende untypisierte Karten werden als note behandelt, ohne ihre Inhalte umzuschreiben. Ältere Zugangsdaten werden als credential behandelt; nicht sensible Metadaten werden beim Lesen auf nicht sensible Felder und Werte des geheimen Inhalts auf sensible Felder abgebildet. Änderungen an Zugangsdatenfeldern behalten den bestehenden strukturierten Zugangsdateninhalt bei, damit Verbraucher für Kopieren, OTP und Einfügen weiterhin funktionieren. Binäre ältere Zugangsdaten lehnen die Migration zu generischen Textfeldern ab, anstatt ihre Bytes zu verwerfen. Frühere signierte Revisionen bleiben im Verlauf erhalten.

Aktualisieren Sie alle Geräte, bevor Sie das neue Schema austauschen: Ältere ausführbare Programme, die unbekannte JSON-Member ablehnen, verstehen die neuen Revisionen typisierter Karten nicht.