Guía del producto Memories

Memories es un sistema cifrado de recuerdos, archivos privados y credenciales. Por defecto, los datos se cifran localmente y las claves permanecen en los dispositivos del usuario. El Center alojado opcional guarda el contenido en una biblioteca cifrada del servidor, cuyo operador puede leer el texto sin cifrar cuando está desbloqueada; los secretos marcados como de extremo a extremo solo se descifran entre dispositivos. El programa de línea de comandos es memories, el relé WebSocket sin estado es memories-relay, el centro de autorización es memories-center y la biblioteca nativa que el móvil invoca mediante la ABI de C es memories_ffi.

Esta es una versión de desarrollo, con la versión 1 del formato de almacenamiento. Puede consultar la versión instalada con memories --version. El repositorio contiene código ejecutable y pruebas de regresión de seguridad. Todavía no ha pasado una revisión criptográfica independiente ni una auditoría de seguridad de aplicaciones. Superar las pruebas no constituye una certificación de seguridad para producción.

La documentación en inglés sigue en el repositorio: README.md y SECURITY.md en la raíz, y las guías temáticas de docs/. Este documento describe el producto según el comportamiento implementado actualmente, sin presentar capacidades pendientes como disponibles.

Elija primero qué quiere hacer

Por defecto, el conocimiento que se puede recuperar, los perfiles de persona compartidos entre clientes y los secretos protegidos residen en los dispositivos del usuario, con autorización por bóveda. Las unidades en la nube guardan texto cifrado y el relé conecta dispositivos en línea. El Center alojado, habilitado por separado, guarda contenido descifrable en el servidor, como se explica más adelante.

Conceptos fundamentales

Todas las tarjetas de conocimiento admiten tipos de tarjeta y campos personalizados: notas, contactos, enlaces, fragmentos de código, listas, fechas y eventos, credenciales y plantillas reutilizables dentro de la bóveda. Los campos admiten validación, ordenación y cambio de nombre; los valores sensibles se ocultan por defecto y mostrarlos requiere autorización y verificación explícitas.

unlock desbloquea el almacenamiento local y permite operaciones ordinarias dentro de los permisos; memories sudo usa la misma contraseña para crear una sesión breve de elevación destinada a contenido privado, archivos, credenciales y administración sensible. No otorga privilegios de administrador del sistema operativo ni elude los permisos de la bóveda.

El MCP ordinario se autoriza por bóveda, duración y alcance de lectura/escritura; no hereda la elevación del terminal ni permite acceder a contenido privado o credenciales. Existe además la CLI/MCP desatendida, habilitada explícitamente: solo local y de solo lectura, pero permite leer contenido privado, archivos originales y texto sin cifrar de credenciales solicitado explícitamente en las bóvedas autorizadas. No es el comportamiento predeterminado del MCP ordinario, y los clientes receptores y los registros pueden conservar secretos.

Capacidades implementadas

Bóvedas, recuerdos y tarjetas de conocimiento

El usuario inicializa una biblioteca con una contraseña local y crea bóvedas dentro de ella. Los recuerdos y tarjetas de conocimiento ordinarios se pueden escribir, leer, buscar, consultar en el historial y eliminar. Las tarjetas admiten etiquetas, fuentes, alias, notas, categorías, relaciones dirigidas y enlaces inversos, y permiten visualizar el grafo. Las tarjetas de mapa mental (brain) son conocimiento estructurado con resúmenes en texto plano y enlaces tipados entre bóvedas; los resúmenes se pueden buscar dentro de los permisos de la bóveda y no se convierten en secretos protegidos. Las tarjetas de persona (persona) guardan el texto central de identidad entre productos y archivos asociados (diarios, contratos, etc.) y permiten añadir eventos de comportamiento; la copia de la bóveda es la fuente de autoridad. Las tarjetas de flujo de trabajo (workflow) guardan pasos ordenados y sus estados en las revisiones; las plantillas de listas registran la persona asignada, la descripción y los objetivos, pueden copiarse como tareas y vincularse a otros flujos o recuerdos archivados. Las listas pueden filtrarse o agruparse por tipo o categoría; las bóvedas, personas y tipos habituales pueden guardarse como valores predeterminados del cliente. Los archivos privados pueden importarse y exportarse. El contenido marcado explícitamente como privado requiere elevación local para acceder a él y no participa en la búsqueda ordinaria.

Los comandos, MCP y el móvil utilizan ID hexadecimales cortos normales, generalmente de seis caracteres, como 0b0668. Los ID no tienen prefijo de tipo ni indican nivel de confidencialidad. Los ID existentes de ocho caracteres siguen siendo válidos. En caso de colisión, el ID devuelto aumenta de dos en dos caracteres hasta un máximo de 16. Las claves públicas de dispositivos y las huellas de seguridad no se acortan.

Los idiomas de la interfaz incluyen inglés, chino simplificado, japonés, alemán y francés. Tanto el móvil como la línea de comandos pueden recordar una selección manual o volver a seguir el idioma del sistema.

El equipo local también puede registrar la versión del intérprete Python y el directorio de su ejecutable en la bóveda «Este dispositivo». Esta bóveda no se incluye en paquetes de autorización de dispositivos, copias de seguridad ni sincronización.

Recuperación de información

La búsqueda ordinaria segmenta el chino y admite varias palabras clave. La recuperación avanzada ofrece fragmentación, BM25, vectores EmbeddingGemma dentro del proceso, clasificación híbrida y respuestas con citas sobre recuerdos y tarjetas de conocimiento ordinarios autorizados. Los pesos del modelo se instalan por separado con memories rag model-install o se configuran para apuntar a un directorio local. También pueden utilizarse direcciones de embeddings, generación y reclasificación opcional configuradas por el propio cliente. Las credenciales, el contenido privado y los archivos no participan en la recuperación.

Además de la búsqueda y lectura/escritura existentes, MCP ofrece memory_retrieve y memory_ask. Los clientes de IA pueden utilizar estas herramientas mediante la skill incluida. La skill se puede instalar en directorios de usuario o de proyecto de Codex, OpenCode y Claude Code; memories skill generate también puede generar un AGENTS.md o un directorio de skill con un resumen de persona para el proyecto. MCP también ofrece herramientas de flujos de trabajo y personas. Las organizaciones que necesiten autorización unificada pueden configurar un centro de autorización. En el modo de tickets, Center emite tickets de inscripción y autorización MCP, mientras el contenido permanece en las bibliotecas de cada dispositivo.

Credenciales y tarjetas protegidas

Las credenciales se capturan mediante entrada oculta, tuberías, salida estándar de comandos, expresiones regulares o punteros JSON y se guardan cifradas. Se pueden generar claves SSH o certificados TLS dentro de la biblioteca, exportar claves públicas o certificados, utilizar credenciales según listas de hosts permitidos o inyectarlas en un subproceso cuya huella esté aprobada. El adaptador HTTPS solo envía tokens Bearer a hosts permitidos y solo devuelve el código de estado.

Los documentos pueden sustituir claves exactas de su cuerpo por {{secret:标签}}. La lectura ordinaria, las búsquedas y MCP solo ven esta referencia. Con autorización se puede copiar el valor actual al portapapeles del sistema sin imprimirlo.

Las tarjetas protegidas guardan un resumen que se puede buscar y una credencial independiente en la misma confirmación:

TOTP y HOTP admiten SHA-1, SHA-256, SHA-512 y 6 u 8 dígitos. El periodo TOTP es de 30 o 60 segundos. HOTP utiliza un contador persistente que se incrementa en uno en la misma confirmación cada vez que se genera un código. La línea de comandos puede importar un otpauth://totp/... o otpauth://hotp/... individual, así como otpauth-migration://offline?data=... de Google Authenticator. card otp-import --image lee ambos tipos de URI desde imágenes QR con un decodificador escrito íntegramente en Rust. Generar códigos de un solo uso requiere elevación local; los códigos no se registran en la auditoría. La búsqueda y MCP no generan códigos ni devuelven semillas.

El daemon puede mantener sesiones SSH, FTP, TCP, MySQL, Redis y PostgreSQL. Cada instrucción se propone, se aprueba con APPROVE y se ejecuta una vez. SSH, MySQL, Redis y PostgreSQL también pueden abrir un proxy de bucle local que solo escucha en 127.0.0.1, para que los programas locales se conecten sin obtener la contraseña o clave privada guardada.

Operaciones criptográficas de correo y aplicaciones

memories crypto utiliza credenciales de la biblioteca y herramientas locales indicadas por el usuario para firmar, cifrar y descifrar S/MIME y OpenPGP, y firmar APK/AAB de Android. En macOS también puede firmar una .app de iOS que ya tenga un perfil de aprovisionamiento. El plan se puede previsualizar; ejecutarlo requiere elevación local y aprobar su resumen criptográfico exacto. Estas operaciones no envían correo ni publican aplicaciones. MCP y la FFI móvil no pueden invocarlas.

Roles, autorizaciones y solicitudes de permisos

Los roles de la bóveda son Reader, Editor, Admin y Owner. Los alcances máximos respectivos son read, read_write, read_write_delete y allow_all. Si se omite el alcance se utiliza read. Reader y Editor no pueden emitir autorizaciones. Admin y Owner pueden emitirlas y delegarlas; la emisión local requiere una bóveda desbloqueada, sin elevación del terminal. Una autorización no puede superar el rol del emisor ni el alcance de la autorización que posee el invocante, ni abarcar varias bóvedas; dura 1–60 minutos y admite hasta dos niveles de delegación. El destinatario debe ser miembro de la bóveda y no tener un rol superior al emisor. Puede haber como máximo 10000 autorizaciones válidas simultáneamente; el daemon local y el Center alojado comparten este límite. Los tokens aparecen una sola vez al emitirlos o recogerlos y la biblioteca solo guarda sus hashes. El bloqueo suspende las autorizaciones, sin revocarlas. No se incluyen en sincronización ni copias de seguridad.

Cualquier miembro actual puede solicitar un alcance mayor para sí mismo. Localmente también puede solicitar un rol; las solicitudes del Center alojado solo incluyen alcance. La aprobación únicamente registra los límites, sin emitir tokens; el solicitante recoge uno posteriormente con sus propias credenciales de miembro. Nadie puede aprobar ni rechazar su propia solicitud. El máximo pendiente es de 20 por persona y bóveda y 200 por bóveda. Caducan tras 7 días y se eliminan 30 días después de decidirse.

El MCP ordinario tiene herramientas de autorización correspondientes, sigue sin heredar la elevación del terminal y no permite acceder a contenido privado o credenciales. La FFI local del móvil no expone administración de autorizaciones ni solicitudes de permisos.

Center alojado y secretos sellados

En modo de tickets, Center solo emite tickets de inscripción, autorización MCP y desbloqueo. Los tickets de desbloqueo solo permiten desbloquear localmente con la contraseña del dispositivo; no conceden sudo ni elevación MCP.

El modo alojado ejecuta una biblioteca cifrada del servidor mediante memories-center --data. Cuando la configuración contiene exactamente un mode = "saas", las solicitudes de contenido del daemon se dirigen a ese Center y el equipo local deja de ser el backend del contenido. El token de administrador del operador gestiona bloqueo, desbloqueo y miembros, pero no permite leer o escribir contenido directamente. El operador puede ver el contenido alojado.

Para secretos que el servidor no deba ver, primero se emparejan la CLI y el teléfono del administrador de la bóveda y después se introducen en sobres sellados. El móvil puede escanear un QR de emparejamiento válido durante 5 minutos o introducir el código manualmente y verificar la huella y el SAS de 6 dígitos. Center solo guarda claves públicas y texto cifrado. Los dispositivos no pueden emitir autorizaciones ni aprobar solicitudes. La revocación elimina los sobres de ese dispositivo; el texto sin cifrar ya entregado no puede recuperarse, por lo que hay que cambiar el secreto y volver a sellarlo para los dispositivos que sigan aprobados.

Este proceso es distinto del emparejamiento de dispositivos para bóvedas locales. El emparejamiento local sigue usando invitaciones, comprobación de huellas y archivos de aprobación, sin cámara. Los QR OTP otpauth tampoco se pueden importar con la cámara del móvil; en la línea de comandos se sigue utilizando card otp-import --image.

Dispositivos, nube y recuperación

El emparejamiento de dispositivos sirve para un dispositivo nuevo de la misma persona: después de inicializarlo con su propia contraseña, se incorpora a la identidad existente mediante invitación, comprobación de huella y aprobación. Las invitaciones de miembros sirven para otra persona: le conceden un rol en una bóveda concreta dentro del límite del rol de quien aprueba, sin convertirla en un dispositivo propio. Admin puede gestionar Admin, Editor y Reader, pero no añadir, eliminar ni modificar Owner ni revocar dispositivos. Cada bóveda tiene exactamente un propietario, y las invitaciones no pueden añadir otro; el propietario actual debe transferir la propiedad a un miembro existente con memories member transfer VAULT_ID USER_PUBLIC_KEY, tras lo cual pasa a ser administrador. La revocación de dispositivos se aplica por bóveda y solo puede realizarla su propietario.

Las bóvedas pueden exportarse como archivos cifrados o enviarse completas en línea mediante el relé WebSocket del usuario. El relé no guarda activos en texto sin cifrar ni pone datos en cola para dispositivos desconectados. Las ediciones simultáneas conservan varias cabezas que deben resolverse explícitamente. Las escrituras desconocidas de épocas caducadas pasan a cuarentena para volver a firmarse localmente.

El escritorio permite iniciar sesión en OneDrive o Google Drive con una aplicación OAuth registrada por el propio usuario. Los tokens se guardan cifrados localmente y no se incluyen en copias de seguridad ni intercambios entre dispositivos. memories cloud sync sube y descarga objetos cifrados inmutables mediante la carpeta de aplicación correspondiente.

Estas tres vías tienen fines distintos: sync export/import y sync send/receive por relé son intercambios explícitos de bóvedas completas; cloud sync PROVIDER sincroniza mediante objetos en la nube y colas persistentes; el RPC del daemon remoto ejecuta operaciones en el host sin importar la bóveda al almacenamiento local del invocante. El relé no ofrece almacenamiento sin conexión y la validación de sincronización en la nube con cuentas reales sigue pendiente.

Las copias de seguridad usan otra contraseña. La restauración crea una bóveda independiente en un directorio de datos nuevo y conserva el historial firmado original en un archivo de solo lectura.

Escritorio, móvil y clientes de IA

Windows ofrece una bandeja del sistema y macOS una aplicación de barra de menús. Ambas y memories webui en Linux abren una página local de estado de solo lectura que muestra el bloqueo, el número de bóvedas, las conexiones y la cola de sincronización en la nube, sin mostrar contenido de las bóvedas. La página solo escucha en 127.0.0.1.

Los clientes Android e iOS funcionan mediante el mismo servicio Rust e incluyen búsqueda local de texto completo, selección de archivos, archivos de aprobación de miembros, transferencia en línea por relé, historial y auditoría. Un factor local guardado en el almacenamiento seguro de la plataforma complementa la contraseña. La biometría o el bloqueo del dispositivo opcionales solo desbloquean la biblioteca local y no entregan las claves del dispositivo a Center. Al pasar a segundo plano, la aplicación borra autorizaciones y cierra los diálogos de contenido. Android impide capturas de pantalla e iOS oculta la instantánea del selector de aplicaciones.

En el primer inicio del móvil se puede elegir Autónomo, Center o SaaS, y cambiar desde la pantalla principal. Autónomo usa una biblioteca cifrada local; Center conecta con un servidor alojado por el cliente; SaaS conecta de forma fija a https://memories.ivjn.us. Los dos últimos no requieren crear primero una biblioteca local; guardan por separado la dirección del servicio y el token del miembro, y cambiar de modo no traslada datos.

Center / SaaS ofrecen listas de conocimiento alojado, búsqueda, detalles, edición de conocimiento ordinario, creación y eliminación con confirmación, además de aprobación de solicitudes de autorización y gestión de dispositivos emparejados. Las cuentas de solo lectura pueden navegar y las de solo escritura pueden crear; eliminar requiere la autorización correspondiente. Las tarjetas estructuradas y de extremo a extremo requieren editores específicos. Aunque el Store alojado está cifrado en disco, el operador posee la contraseña y puede leerlo; la interfaz indica «Legible por el servidor». El QR de emparejamiento se escanea con la cámara; si se deniega el acceso, puede introducirse el código. Si falla una edición, el borrador se conserva para reintentar; salir con cambios sin guardar requiere confirmación, y el bloqueo en segundo plano borra los borradores. Consulte Selección y cambio del modo móvil para los pasos.

Actualmente no disponible

Los siguientes elementos todavía no se han entregado como capacidades utilizables:

• Validación del consentimiento, renovación, cierre de sesión, convergencia entre dos dispositivos, reintentos sin conexión y revocación con cuentas reales de OneDrive o Google Drive. El inicio de sesión de escritorio y cloud sync están implementados y probados con fixtures locales; la validación con cuentas reales sigue siendo un requisito de publicación.
• Interfaz de recuperación mediante modelos en el móvil. El móvil no tiene configuración de modelos ni interfaz de inferencia. La recuperación vectorial e híbrida y las respuestas con citas utilizan el daemon de escritorio configurado. El móvil recibe búsqueda por palabras clave mejorada y recuperación BM25.
• Bandeja nativa de Linux. Linux permite utilizar CLI, daemon, relé, biblioteca FFI y memories webui. La bandeja nativa solo está disponible actualmente en Windows y macOS.
• Sincronización móvil en segundo plano. Esta versión no la habilita.
• Importación de OTP mediante la cámara móvil. El emparejamiento de dispositivos alojados puede escanear QR de emparejamiento. otpauth:// y otpauth-migration:// siguen utilizando la CLI memories card otp-import --image PATH o URI proporcionadas directamente. El móvil no puede leer estos dos tipos de QR OTP con la cámara.

Además, la sincronización en línea por relé es una transferencia explícita de la bóveda completa, no una sincronización incremental automática; es distinta de la vía de objetos en la nube de cloud sync. El relé no puede guardar paquetes para dispositivos desconectados. No están implementados la caducidad de cookies, la renovación de JWT ni el inicio de sesión automático.

Componentes

Consulte los pasos en la Guía de uso. Los límites del almacenamiento, autorización, recuperación, sincronización en la nube y estado del escritorio se explican en la Documentación técnica.