Présentation du produit Memories

Memories est un système chiffré de souvenirs, de fichiers privés et d'identifiants. Par défaut, les données sont chiffrées localement et les clés restent sur les appareils de l'utilisateur. Le Center hébergé facultatif place le contenu dans un stockage chiffré sur le serveur, dont l'opérateur peut lire le texte en clair lorsqu'il est déverrouillé ; les secrets marqués comme chiffrés de bout en bout restent déchiffrables uniquement entre appareils. Le programme en ligne de commande est memories, le relais WebSocket sans état est memories-relay, le centre d'autorisation est memories-center et la bibliothèque locale appelée par le mobile via l'ABI C est memories_ffi.

Il s'agit d'une version de développement, dont le format de stockage est en version 1. La version du programme installé peut être consultée avec memories --version. Le dépôt contient du code exécutable et des tests de non-régression de sécurité. Il n'a pas encore fait l'objet d'une analyse cryptographique indépendante ni d'un audit de sécurité applicative. La réussite des tests ne constitue pas une certification de sécurité pour la production.

La documentation anglaise reste disponible dans le dépôt : README.md et SECURITY.md à la racine, ainsi que les guides thématiques dans docs/. Ce document présente le produit selon son comportement actuellement implémenté, sans présenter les capacités inachevées comme disponibles.

Choisir d'abord ce que vous souhaitez accomplir

Par défaut, les connaissances interrogeables, les profils de personnalité partagés entre clients et les secrets protégés résident sur les appareils de l'utilisateur, avec des autorisations par coffre-fort. Le stockage cloud conserve le texte chiffré ; le relais relie les appareils en ligne. Un Center hébergé activé séparément conserve sur le serveur du contenu déchiffrable, comme expliqué ci-dessous.

Concepts fondamentaux

Toutes les fiches de connaissances prennent en charge les types de fiches et champs personnalisés : notes, contacts, liens, extraits de code, listes, dates et événements, identifiants et modèles réutilisables dans un coffre-fort. Les champs peuvent être validés, triés et renommés ; les valeurs sensibles sont masquées par défaut, et leur affichage exige une autorisation et une vérification explicites.

unlock déverrouille le stockage local et permet les opérations ordinaires dans les limites des autorisations ; memories sudo utilise le même mot de passe pour établir une session d'élévation temporaire destinée au contenu privé, aux fichiers, aux identifiants et aux opérations d'administration sensibles. Il ne s'agit pas de privilèges administrateur du système d'exploitation et cela ne contourne pas les permissions du coffre-fort.

Le MCP ordinaire est autorisé par coffre-fort, durée et portée de lecture/écriture ; il n'hérite pas de l'élévation du terminal et n'ouvre pas l'accès au contenu privé ou aux identifiants. Un CLI/MCP sans surveillance, activé explicitement, existe également : local uniquement et en lecture seule, mais capable de lire le contenu privé, les fichiers bruts et les identifiants en clair explicitement demandés dans les coffres-forts autorisés. Ce n'est pas le comportement par défaut du MCP ordinaire ; le client destinataire et ses journaux peuvent conserver des secrets.

Capacités implémentées

Coffres-forts, souvenirs et fiches de connaissances

L'utilisateur initialise un stockage avec un mot de passe local, puis y crée des coffres-forts. Les souvenirs ordinaires et les fiches de connaissances peuvent être écrits, lus, recherchés, consultés dans leur historique et supprimés. Les fiches prennent en charge étiquettes, sources, alias, notes, catégories, relations orientées et liens entrants ; un graphe est également consultable. Les fiches brain sont des fiches de connaissances structurées avec résumé en texte brut et liens typés entre coffres-forts ; leur résumé est interrogeable dans les limites des permissions du coffre-fort, sans devenir un secret protégé. Les fiches persona conservent le texte du noyau d'identité commun à plusieurs produits et les dossiers associés (journaux, contrats, etc.), et permettent d'ajouter des événements comportementaux ; la copie du coffre-fort est la source faisant autorité. Les fiches workflow conservent dans leurs révisions des étapes ordonnées et leur état ; les modèles de listes enregistrent la personne affectée, l'aperçu et les objectifs, peuvent être copiés en tâches et liés à d'autres workflows ou à des souvenirs archivés. Les listes peuvent être filtrées ou regroupées par type ou catégorie ; les coffres-forts, personnalités et types fréquemment utilisés peuvent être enregistrés comme valeurs par défaut du client. Les fichiers privés peuvent être importés et exportés. Le contenu explicitement marqué comme privé exige une élévation locale pour être consulté et n'entre pas dans la recherche ordinaire.

Les commandes, le MCP et le mobile utilisent des ID hexadécimaux courts ordinaires, généralement de six caractères, par exemple 0b0668. Les ID n'ont pas de préfixe de type et n'indiquent pas un niveau de confidentialité. Les ID existants de huit caractères restent valides. En cas de collision, l'ID renvoyé est allongé par incréments de deux caractères, jusqu'à 16 caractères. Les clés publiques des appareils et les empreintes de sécurité ne sont pas raccourcies.

Les langues de l'interface comprennent l'anglais, le chinois simplifié, le japonais, l'allemand et le français. Le mobile et la ligne de commande peuvent mémoriser un choix manuel ou suivre à nouveau la langue du système.

Localement, la version de l'interpréteur Python et le répertoire de son exécutable peuvent aussi être enregistrés dans le coffre-fort « Cet appareil ». Ce coffre-fort est exclu des paquets d'autorisation des appareils, des sauvegardes et de la synchronisation.

Recherche

La recherche ordinaire segmente le chinois et accepte plusieurs mots-clés. La recherche avancée fournit, pour les souvenirs ordinaires et les fiches de connaissances autorisés, un découpage en fragments, BM25, des vecteurs EmbeddingGemma dans le processus, un classement hybride et des réponses avec citations. Les poids du modèle sont installés séparément avec memories rag model-install, ou un répertoire local est indiqué dans la configuration. Il est aussi possible d'utiliser des adresses d'embedding, de génération et éventuellement de reclassement configurées par le client. Les identifiants, le contenu privé et les fichiers sont exclus de la recherche.

Outre la recherche et la lecture/écriture existantes, le MCP fournit memory_retrieve et memory_ask. Les clients IA peuvent utiliser ces outils grâce au skill fourni. Le skill peut être installé dans le répertoire utilisateur ou de projet de Codex, OpenCode et Claude Code ; memories skill generate peut aussi générer pour un projet un AGENTS.md ou un répertoire de skill contenant un aperçu de personnalité. Le MCP fournit également des outils de workflow et de personnalité. Les organisations ayant besoin d'autorisations centralisées peuvent configurer un centre d'autorisation. En mode tickets, le Center émet les tickets d'enregistrement et d'autorisation MCP, tandis que le contenu reste dans le stockage propre à chaque appareil.

Identifiants et fiches protégées

Les identifiants sont capturés par saisie masquée, canal, sortie standard de commande, expression régulière ou pointeur JSON, puis conservés sous forme chiffrée. On peut générer dans le stockage des clés SSH ou des certificats TLS, exporter des clés publiques ou des certificats, utiliser des identifiants selon une liste d'hôtes autorisés, ou injecter des identifiants dans un sous-processus dont l'empreinte a été approuvée. L'adaptateur HTTPS n'envoie des jetons Bearer qu'aux hôtes autorisés et ne renvoie que le code d'état.

Les documents peuvent remplacer une clé exacte dans le corps du texte par {{secret:标签}}. La lecture ordinaire, la recherche et le MCP ne voient que cette référence. Après autorisation, la valeur actuelle peut être copiée dans le presse-papiers du système sans être imprimée.

Les fiches protégées placent un résumé interrogeable et un identifiant distinct dans une même validation :

TOTP et HOTP prennent tous deux en charge SHA-1, SHA-256, SHA-512 et 6 ou 8 chiffres. La période TOTP est de 30 ou 60 secondes. HOTP utilise un compteur persistant, incrémenté dans la même validation à chaque génération de code. La ligne de commande peut importer un otpauth://totp/... ou otpauth://hotp/... unique, ainsi que le format otpauth-migration://offline?data=... de Google Authenticator. card otp-import --image lit ces deux types d'URI depuis une image de code QR avec un décodeur entièrement en Rust. La génération d'un code à usage unique exige une élévation locale ; le code lui-même n'est pas enregistré dans l'audit. La recherche et le MCP ne génèrent pas de codes et ne renvoient pas de graines.

Le daemon peut maintenir des sessions SSH, FTP, TCP, MySQL, Redis et PostgreSQL. Chaque instruction est d'abord proposée, puis approuvée avec APPROVE, et exécutée une seule fois. SSH, MySQL, Redis et PostgreSQL peuvent aussi ouvrir un proxy de boucle locale n'écoutant que sur 127.0.0.1, permettant aux programmes locaux de se connecter sans obtenir le mot de passe ou la clé privée enregistrés.

Opérations cryptographiques pour le courrier et les applications

memories crypto utilise les identifiants du stockage et les outils locaux désignés par l'utilisateur pour signer, chiffrer et déchiffrer en S/MIME et OpenPGP, ainsi que pour signer des APK/AAB Android. Sur macOS, il peut également signer une .app iOS disposant déjà d'un profil de provisionnement. Le plan peut être prévisualisé avant exécution ; l'exécution réelle exige une élévation locale et l'approbation de l'empreinte exacte du plan. Ces opérations n'envoient pas de courrier et ne publient pas d'applications. Le MCP et la FFI mobile ne peuvent pas les appeler.

Rôles, autorisations et demandes d'accès

Les rôles du coffre-fort sont Reader, Editor, Admin et Owner. Leurs portées maximales respectives sont read, read_write, read_write_delete et allow_all. Une portée omise vaut read. Reader et Editor ne peuvent pas émettre d'autorisations. Admin et Owner peuvent en émettre et en déléguer ; l'émission locale exige un coffre-fort déverrouillé, sans élévation du terminal. Une autorisation ne peut dépasser ni le rôle de l'émetteur ni la portée de l'autorisation détenue par l'appelant, et ne peut couvrir plusieurs coffres-forts ; sa durée est de 1–60 minutes et la délégation comporte au maximum deux niveaux. Le destinataire doit déjà être membre du coffre-fort et son rôle ne peut dépasser celui de l'émetteur. Le maximum est de 10000 autorisations actives simultanément, avec la même limite pour le daemon local et le Center hébergé. Le jeton n'apparaît qu'une fois, lors de l'émission ou du retrait ; seul son hachage est stocké. Le verrouillage suspend les autorisations sans les révoquer. Les autorisations sont exclues de la synchronisation et des sauvegardes.

Tout membre actuel peut demander une portée plus large pour lui-même. Localement, il peut aussi demander un rôle ; les demandes au Center hébergé ne concernent que la portée. L'approbation enregistre seulement les limites, sans émettre de jeton ; le demandeur le retire ensuite une fois avec ses propres identifiants de membre. Un demandeur ne peut ni approuver ni refuser sa propre demande. Le maximum de demandes en attente est de 20 par personne et par coffre-fort, et de 200 par coffre-fort. Elles expirent après 7 jours et sont supprimées 30 jours après la décision.

Le MCP ordinaire dispose des outils d'autorisation correspondants, mais n'hérite toujours pas de l'élévation du terminal et n'ouvre pas l'accès au contenu privé ou aux identifiants. La FFI mobile locale n'expose pas la gestion des autorisations ni les demandes d'accès.

Center hébergé et secrets scellés

En mode tickets, le Center n'émet que des tickets d'enregistrement, d'autorisation MCP et de déverrouillage. Les tickets de déverrouillage autorisent seulement le déverrouillage local avec le mot de passe propre à l'appareil, sans accorder sudo ni d'élévation au MCP.

Le mode hébergé exécute un stockage chiffré sur le serveur avec memories-center --data. Lorsque la configuration contient exactement un mode = "saas", les requêtes de contenu du daemon sont transférées à ce Center et le stockage local cesse de servir de backend de contenu. Le jeton administrateur de l'opérateur gère le verrouillage, le déverrouillage et les membres ; il ne permet pas de lire ou écrire directement le contenu. Le contenu hébergé est visible par l'opérateur.

Pour les secrets qui doivent rester invisibles au serveur, il faut d'abord appairer le CLI avec le téléphone d'un administrateur du coffre-fort, puis les placer dans des enveloppes scellées. Le téléphone peut scanner un code QR d'appairage valable 5 minutes ou recevoir un code saisi manuellement, avec vérification des empreintes et d'un SAS à 6 chiffres. Le Center ne conserve que les clés publiques et le texte chiffré. Les appareils ne peuvent ni émettre des autorisations ni approuver des demandes. La révocation supprime les enveloppes de cet appareil ; le texte en clair déjà transmis ne peut pas être récupéré : il faut d'abord remplacer le secret, puis le sceller à nouveau pour les appareils toujours approuvés.

Cette procédure est distincte de l'appairage d'appareils d'un coffre-fort local. L'appairage local utilise toujours des invitations, la vérification d'empreintes et des fichiers d'approbation, sans caméra. Les codes QR OTP otpauth ne peuvent pas non plus être importés avec la caméra du téléphone ; la ligne de commande continue à utiliser card otp-import --image.

Appareils, cloud et restauration

L'appairage d'appareils concerne un nouvel appareil de la même personne : après initialisation avec son propre mot de passe, il rejoint l'identité existante par invitation, vérification d'empreintes et approbation. L'invitation d'un membre concerne une autre personne : elle lui accorde un rôle dans le coffre-fort désigné, dans les limites du rôle de l'approbateur, sans transformer cette personne en appareil personnel. Admin peut gérer Admin, Editor et Reader, mais ne peut ni ajouter, supprimer ou modifier Owner, ni révoquer des appareils. Chaque coffre-fort possède exactement un propriétaire, et une invitation ne peut pas en ajouter un ; le propriétaire actuel doit transférer la propriété à un membre existant avec memories member transfer VAULT_ID USER_PUBLIC_KEY, après quoi il devient administrateur. La révocation d'un appareil s'applique par coffre-fort et seul le propriétaire peut l'effectuer.

Un coffre-fort peut être exporté dans un fichier chiffré ou transmis intégralement en ligne via le relais WebSocket de l'utilisateur. Le relais ne conserve pas de ressources en clair et ne met pas les données en attente pour les appareils hors ligne. Les modifications concurrentes conservent plusieurs têtes et doivent être résolues explicitement. Les écritures inconnues d'un ancien epoch sont placées en quarantaine, puis signées à nouveau localement.

Sur le bureau, l'utilisateur peut se connecter à OneDrive ou Google Drive avec sa propre application OAuth enregistrée. Les jetons sont conservés localement sous forme chiffrée et sont exclus des sauvegardes et des échanges entre appareils. memories cloud sync téléverse et télécharge des objets chiffrés immuables via le dossier d'application correspondant.

Ces trois chemins ont des usages distincts : sync export/import et sync send/receive par relais sont des échanges explicites de coffres-forts complets ; cloud sync PROVIDER synchronise des objets cloud avec des files persistantes ; les RPC du daemon distant exécutent des opérations sur l'hôte sans importer le coffre-fort dans le stockage local de l'appelant. Le relais ne fournit pas de stockage hors ligne, et la validation de la synchronisation cloud avec des comptes réels n'est pas encore terminée.

Les sauvegardes utilisent un mot de passe distinct. La restauration crée un coffre-fort indépendant dans un nouveau répertoire de données et conserve l'historique signé original dans une archive en lecture seule.

Bureau, mobile et clients IA

Windows propose une icône dans la zone de notification, et macOS une application de barre de menus. Toutes deux, ainsi que memories webui sur Linux, ouvrent une page locale d'état en lecture seule indiquant le verrouillage, le nombre de coffres-forts, les connexions et la file de synchronisation cloud, sans afficher le contenu. La page d'état n'écoute que sur 127.0.0.1.

Les clients Android et iOS utilisent le même service Rust, avec recherche locale en texte intégral, sélection de fichiers, fichiers d'approbation des membres, transferts en ligne par relais, historique et audit. Un facteur local conservé dans le stockage sécurisé de la plateforme complète le mot de passe. La biométrie ou le verrouillage de l'appareil facultatifs ne déverrouillent que le stockage local et ne transmettent pas les clés de l'appareil au Center. Lorsque l'application passe en arrière-plan, elle efface les autorisations et ferme les dialogues de contenu. Android bloque les captures d'écran et iOS masque les aperçus dans le sélecteur d'applications.

Au premier lancement, le mobile propose les modes autonome, Center ou SaaS, que l'on peut ensuite changer dans l'écran principal. Le mode autonome utilise le stockage local chiffré ; Center se connecte au serveur hébergé construit par le client ; SaaS se connecte à l'adresse fixe https://memories.ivjn.us. Ces deux derniers modes n'exigent pas la création préalable d'un stockage local et enregistrent chacun l'adresse du service et le jeton de membre ; changer de mode ne déplace pas les données.

Center / SaaS proposent les listes de connaissances hébergées, la recherche, les détails, l'édition des connaissances ordinaires, la création et la suppression avec confirmation, ainsi que l'approbation des demandes d'accès et la gestion des appareils appairés. Les comptes en lecture seule peuvent consulter, ceux en écriture seule peuvent créer, et la suppression nécessite l'autorisation correspondante ; les fiches structurées et de bout en bout doivent être modifiées avec les éditeurs dédiés. Bien que le Store hébergé soit chiffré sur disque, l'opérateur possède le mot de passe et peut lire le contenu ; l'interface indique « lisible par le serveur ». Le code QR d'appairage est scanné avec la caméra ; si l'accès à celle-ci est refusé, un code peut être saisi. Un échec d'édition conserve le brouillon pour réessayer ; quitter du contenu non enregistré exige une confirmation, et le verrouillage en arrière-plan efface les brouillons. Voir les étapes dans Choisir et changer le mode mobile.

Capacités actuellement indisponibles

Les éléments suivants n'ont pas encore été livrés comme capacités utilisables :

• Validation du consentement, du renouvellement, de la déconnexion, de la convergence entre deux appareils, des nouvelles tentatives hors ligne et de la révocation avec de vrais comptes OneDrive ou Google Drive. La connexion sur le bureau et cloud sync sont implémentés et testés avec des fixtures locales ; la validation avec des comptes réels reste une condition de publication.
• Interface mobile de recherche par modèles. Le mobile ne dispose ni de configuration des modèles ni d'interface d'inférence. La recherche vectorielle, hybride et les questions-réponses avec citations utilisent le daemon de bureau configuré. Le mobile bénéficie d'une recherche par mots-clés améliorée et de BM25.
• Icône native dans la zone de notification sous Linux. Linux peut utiliser le CLI, le daemon, le relais, la bibliothèque FFI et memories webui. L'icône native n'est actuellement disponible que sous Windows et macOS.
• Synchronisation mobile en arrière-plan. Cette version ne l'active pas.
• Importation d'OTP par la caméra mobile. L'appairage d'appareils hébergés peut scanner des codes QR d'appairage. otpauth:// et otpauth-migration:// utilisent toujours la commande memories card otp-import --image PATH, ou un URI fourni directement. Le mobile ne peut pas lire ces deux types de codes QR OTP avec sa caméra.

Par ailleurs, la synchronisation en ligne par relais est un transfert explicite du coffre-fort complet, pas une synchronisation incrémentale automatique ; elle est distincte du chemin de synchronisation d'objets cloud de cloud sync. Le relais ne peut pas conserver les paquets pour les appareils hors ligne. L'expiration des cookies, le renouvellement des JWT et la connexion automatique ne sont pas implémentés.

Composants

Pour les étapes pratiques, voir le Guide d'utilisation. Les limites du stockage, des autorisations, de la recherche, de la synchronisation cloud et de l'état du bureau sont décrites dans la Documentation technique.