CardanoWall Desktop : un client de messagerie local pour vos preuves d'existence

CardanoWall Desktop est un client de bureau open source pour Label 309 — un moyen de conserver vos records de preuve d'existence, vos identités et votre boîte de réception scellée sur votre propre machine plutôt que dans un onglet de navigateur. Il s'utilise comme un client de messagerie : une Boîte de réception des records scellés qui vous sont adressés, une vue Messages envoyés de tout ce que vous avez publié, un flux de composition pour de nouvelles preuves, un Explorateur local sur l'ensemble public des records sur la chaîne, des Contacts pour les adresses de réception, et la gestion locale des identités.

Cet article décrit son fonctionnement, afin que vous puissiez juger s'il correspond à votre façon de travailler.

L'enjeu ne se limite pas à « une application de bureau ». Il tient à trois propriétés qu'un navigateur ne peut pas vous offrir pleinement : elle est offline-first, elle est indépendante du fournisseur, et elle est conçue pour que vos clés privées ne quittent jamais l'appareil.

Quel problème l'application de bureau résout-elle ?

L'application web est le point de départ le plus simple. L'application de bureau s'adresse à celles et ceux qui veulent une maîtrise locale.

Un navigateur reste un bon endroit pour créer une preuve rapide, publier un record ou dérouler un flux de travail rattaché à un compte. Certaines personnes et certaines entreprises ont besoin d'aller plus loin :

un coffre d'identité local et chiffré ;
un accès hors ligne aux records déjà synchronisés ;
des fichiers chiffrés mis en cache localement ;
une boîte de réception privée découverte par déchiffrement local, et non par un routage côté serveur ;
un miroir local et consultable de l'ensemble public des records ;
des flux de travail sur de gros fichiers qui traitent les données en continu au lieu de charger les fichiers entiers en mémoire ;
la possibilité de pointer vers un gateway auto-hébergé ;
moins d'hypothèses figées autour d'un fournisseur hébergé unique.

CardanoWall Desktop est pensé pour ces personnes. Il amène le modèle Label 309 sur votre propre machine et traite l'état hors ligne comme un état normal, et non comme une erreur.

CardanoWall Desktop est-il un portefeuille Cardano ?

Non. Ce n'est pas un portefeuille, et il est conçu pour que vous ne confondiez jamais les deux.

Il n'a pas la garde de vos ADA. Il ne détient pas de phrase de récupération de portefeuille. Il ne construit ni ne soumet de transactions Cardano, et il ne détient aucune clé de chaîne ni de stockage.

La publication passe toujours par un gateway Label 309, qui possède le pipeline de publication : tarification, upload, construction et soumission de la transaction Cardano, confirmation, gestion des réorganisations, indexation et comptabilité du solde. L'application de bureau est un client. Elle conserve vos identités Label 309 localement, prépare les records, signe lorsque vous choisissez de signer, chiffre les contenus scellés, déchiffre les records scellés entrants, vérifie les preuves et dialogue avec le gateway de votre choix. Si vous voulez la même séparation depuis un script ou un terminal, l'outil en ligne de commande open source fait le même travail sans interface graphique.

Pourquoi l'application de bureau est-elle open source ?

Parce qu'un logiciel qui manipule des identités, des signatures, des fichiers chiffrés et des preuves de longue durée doit pouvoir être inspecté.

Si un outil touche à vos clés et à vos pièces, vous devez pouvoir lire comment il fonctionne, une équipe de sécurité doit pouvoir l'auditer, les développeurs doivent pouvoir construire dessus, et les opérateurs doivent pouvoir le pointer vers leur propre infrastructure. Le format de preuve est ouvert, le gateway est ouvert, et le client de bureau l'est aussi — sous la même licence Apache-2.0 que le reste du code Label 309. Un standard ne vaut que par les outils qui l'entourent, et ces outils ne devraient jamais faire de vous un client captif.

Que signifie « offline-first » ici ?

« Offline-first » signifie que l'application locale reste utile lorsque le réseau est indisponible, parce que c'est une base de données locale — et non le réseau — qui fait foi pour ce que vous voyez.

L'application conserve un état local : records synchronisés, correspondances de la boîte de réception, records envoyés, contacts, identités, texte chiffré mis en cache et (uniquement si vous y consentez) fichiers déchiffrés mis en cache. Hors ligne, vous pouvez encore :

parcourir les records déjà synchronisés ;
lire votre boîte de réception ;
déchiffrer les fichiers scellés mis en cache ;
vérifier les records mis en cache ;
effectuer une recherche dans vos données locales ;
préparer un brouillon de preuve à publier plus tard.

Hors ligne ne veut pas dire que toute action aboutit. Publier une nouvelle preuve nécessite toujours un gateway et une connexion réseau. Récupérer un texte chiffré que vous n'avez jamais mis en cache nécessite toujours un accès au stockage. Mais les données déjà synchronisées ne s'évanouissent pas parce que le Wi-Fi a sauté. (Pour les cas où le mode hors ligne est précisément l'objectif — hachage et signature sur une machine isolée — voir les preuves hors ligne.)

Comment fonctionne la Boîte de réception de l'application de bureau ?

La Boîte de réception est une vue locale des records scellés que vos identités peuvent ouvrir — et le serveur n'apprend jamais quels records sont les vôtres.

Un gateway expose un flux public de chaque record Label 309. L'application de bureau synchronise ce flux dans un miroir local. Pour chacune de vos identités, elle tente localement d'ouvrir les emplacements de clé scellés à l'aide des clés de réception de cette identité. Si un emplacement s'ouvre, le record apparaît dans la Boîte de réception de cette identité.

Il ne s'agit délibérément pas d'une boîte aux lettres côté serveur. Le flux du gateway est aveugle au destinataire : il ne contient aucun champ par destinataire, il ne peut donc pas dire à qui s'adresse un record scellé. Votre client le découvre par lui-même, par déchiffrement à l'essai. C'est exactement pour cela qu'un client local convient si bien à la preuve d'existence scellée — la machine qui détient vos clés d'identité est le seul endroit où la boîte de réception peut être assemblée.

Que suit la vue Messages envoyés ?

La vue Messages envoyés suit les records que vous publiez, tout au long de leur cycle de vie — et elle vérifie le résultat au lieu de lui faire confiance.

Une preuve n'est pas terminée à l'instant où vous cliquez sur « soumettre ». Elle traverse plusieurs étapes : brouillon, devis, upload, publication, soumission, confirmation en cours, confirmée — ou échouée et remboursée automatiquement si la publication ne peut aboutir. L'application de bureau garde ce cycle de vie visible localement. Elle peut montrer quel gateway a été utilisé, quelle identité a signé le record, si le record était scellé, quels destinataires ont été sélectionnés, quand la transaction a été confirmée, et si le vérificateur local confirme que le record sur la chaîne correspond à ce que l'application a préparé.

Ce dernier point est le plus important. « Confirmée » ne devrait pas vouloir dire « le gateway l'a affirmé ». Le gateway construit et soumet la transaction, ce n'est donc pas une chose à prendre pour argent comptant — un gateway bogué ou hostile pourrait signaler une transaction différente ou décrire faussement la confirmation. Aussi, dès qu'une empreinte de transaction existe, l'application récupère le record sur la chaîne et le compare octet par octet au record exact qu'elle a publié, avant de marquer quoi que ce soit comme confirmé. C'est la vérification autonome appliquée à votre propre dossier d'envois.

Comment les identités sont-elles stockées sur le bureau ?

Chaque identité est stockée dans un coffre local et chiffré, et la graine secrète ne quitte jamais le cœur en Rust au centre de l'application.

Chaque identité Label 309 prend racine dans une seule graine d'identité de 32 octets. À partir de cette graine, l'application dérive la clé de signature et les clés de réception de l'identité. La graine elle-même reste à l'intérieur du cœur local : elle n'est jamais transmise à la webview qui dessine l'interface, et elle n'est jamais transmise à un quelconque gateway. L'interface ne voit jamais que des projections publiques — labels, empreintes, clés publiques, adresses de réception et statut. Tant que le coffre est déverrouillé, la graine réside dans une mémoire à remise à zéro, effacée dès que vous verrouillez l'application ou qu'elle se verrouille automatiquement après une période d'inactivité.

Cette séparation, c'est tout le principe de conception : la graine est la sauvegarde portable et ce qui mérite d'être protégé, elle est donc traitée comme le joyau de la couronne. Si vous voulez comprendre pourquoi c'est une graine — et non un compte ni un mot de passe — qui constitue la véritable identité, voir votre identité est une graine, et pour le principe qui consiste à la garder sur l'appareil, pourquoi les clés ne quittent jamais l'appareil.

Une limite qu'il faut reconnaître : garder les secrets dans le cœur local protège contre une interface malveillante ou boguée, et contre un fichier de coffre volé mais verrouillé. Cela ne vient pas à bout d'un système d'exploitation entièrement compromis. Tant que l'application est déverrouillée, un logiciel malveillant présent sur la même machine pourrait en principe lire les secrets en mémoire — des fenêtres de déverrouillage courtes, le verrouillage automatique et un minimum de dépendances réduisent cette exposition sans pouvoir l'effacer, exactement la même réserve que pour n'importe quel portefeuille de bureau.

Puis-je utiliser mon propre gateway ?

Oui — et c'est l'une des principales raisons d'être de l'application de bureau.

Elle fonctionne avec n'importe quel gateway Label 309 compatible. Pointez-la vers le gateway officiel CardanoWall pour plus de commodité, vers un gateway auto-hébergé que votre entreprise opère, ou vers un gateway placé derrière le produit de quelqu'un d'autre. Le gateway officiel n'est au mieux qu'une entrée pratique accessible en un clic ; ce n'est jamais une valeur par défaut que vous n'auriez pas choisie. Vous fournissez l'URL de base du gateway et une clé de compte, et l'application sonde le point d'accès pour confirmer qu'il parle bien le standard avant que vous ne vous appuyiez dessus.

La répartition est nette : le gateway possède le pipeline de publication, l'application de bureau possède l'expérience client locale. C'est cette séparation qui empêche tout verrouillage. Votre application locale, vos identités locales, votre cache local et vos records standard ne devraient jamais dépendre d'une seule interface hébergée.

Que voit le gateway, et que ne voit-il jamais ?

Un gateway voit ce dont il a besoin pour publier et faire tourner le service — et rien qui lui permettrait de lire vos fichiers scellés ou de se faire passer pour vous.

Il peut voir votre justificatif de compte, les devis de prix, les uploads, le texte chiffré, votre solde, le statut des transactions, les octets publics des records et des métadonnées opérationnelles. Il ne voit pas votre graine d'identité, il ne voit pas vos clés privées de destinataire, et il ne peut pas déchiffrer vos fichiers scellés. L'application de bureau prépare et utilise chaque secret localement ; le gateway ne fait que publier des records standard et servir le flux public.

Cela ne veut pas dire qu'un gateway ne peut jamais mal se comporter. Il peut retarder, échouer, retenir un record ou mal rapporter un statut. C'est précisément pour cela que la vérification compte : une preuve valide se vérifie à partir du record public sur la chaîne et d'un explorateur Cardano public, et non parce que l'interface d'un gateway l'affirme.

Que puis-je faire avec mes fichiers lorsque je suis hors ligne ?

Cela dépend de ce que vous avez synchronisé et mis en cache — et l'application indique clairement quels fichiers peuvent être conservés sans danger.

Le texte chiffré peut être mis en cache sans réserve, puisqu'il est déjà chiffré ; rouvrir un fichier reçu est alors instantané et fonctionne hors ligne. Les fichiers déchiffrés sont plus sensibles : tout cache de fichiers déchiffrés est donc optionnel, désactivé par défaut, et lui-même chiffré. Le comportement par défaut consiste à conserver le texte chiffré et à déchiffrer à la demande, en mémoire.

Un modèle mental utile :

les métadonnées publiques des records peuvent être mises en miroir en local ;
le texte chiffré peut être mis en cache pour un accès hors ligne ;
les fichiers déchiffrés sont manipulés avec précaution et ne sont écrits sur disque qu'aux endroits où vous les enregistrez explicitement ;
la graine d'identité reste protégée dans le coffre ;
la vérification s'exécute localement pour les records et fichiers mis en cache.

Vous bénéficiez ainsi des avantages concrets du travail hors ligne sans prétendre que les fichiers déchiffrés sont sans risque. Et un fichier déchiffré reste un simple fichier : une fois enregistré, quiconque le reçoit de votre main peut le lire. Une preuve scellée garde le contenu confidentiel pour les détenteurs de clés ; elle ne rend pas un destinataire digne de confiance.

À qui s'adresse l'application de bureau ?

Elle s'adresse aux personnes et aux organisations qui travaillent avec des preuves assez régulièrement pour qu'un onglet de navigateur cesse d'être l'outil adapté.

Parmi les bons profils :

les équipes juridiques et de conformité qui reçoivent des pièces scellées ;
les journalistes et leurs sources qui manipulent des records confidentiels ;
les entreprises qui publient des preuves de conformité récurrentes ;
les développeurs et les équipes plateforme qui utilisent Label 309 dans l'automatisation ;
les équipes d'IA qui préservent des engagements sur des jeux de données et des sorties ;
les créateurs qui conservent des preuves signées de leur travail original ;
les auditeurs qui ont besoin d'un accès local à des dossiers de pièces ;
toute personne qui préfère une infrastructure auto-hébergée ou neutre vis-à-vis des fournisseurs.

Si vous ne publiez qu'une preuve de temps à autre, l'application web reste la voie la plus simple, et l'outil en ligne de commande open source vous permet déjà aujourd'hui de travailler sans le site web. L'application de bureau est faite pour un travail soutenu.

Ce que vous obtenez

C'est un produit local avant tout, qui se comporte comme un véritable logiciel de gestion de preuves, et non comme un gadget léger. Ce qu'il vous offre :

des invites de sauvegarde d'identité claires, pour ne jamais perdre une identité par accident ;
aucune confusion avec la phrase de récupération d'un portefeuille ;
des états de vérification transparents ;
un statut de confirmation lisible ;
une gestion soignée, hors bande, des adresses de réception ;
une recherche locale dans vos records et vos fichiers ouverts ;
un aperçu de fichier intégré et sûr ;
plusieurs identités au même endroit ;
des contacts aux empreintes vérifiables ;
un libre choix du gateway ;
des états d'erreur honnêtes plutôt que des échecs silencieux.

Le standard vous donne le modèle de preuve. L'application de bureau vous donne l'environnement de travail qui l'entoure. Vous pouvez la télécharger depuis le code open source.

En résumé

CardanoWall Desktop est le client local de Label 309. Il synchronise l'ensemble public des records, conserve vos identités localement, découvre les éléments scellés de la boîte de réception par déchiffrement à l'essai local, suit les preuves que vous envoyez (et les vérifie sur la chaîne), fonctionne hors ligne avec les données déjà synchronisées, et se connecte à n'importe quel gateway compatible.

L'application web vous donne la commodité. L'application de bureau vous donne le contrôle local.

Pour aller plus loin

Le standard Label 309 : label309.org
Le code open source, les SDK et l'outil en ligne de commande : github.com/cardanowall
Ce qu'est un gateway Label 309 et ce que CardanoWall peut voir
Comment recevoir des records scellés et utiliser le CLI dans l'automatisation