Le produit fonctionne de bout en bout : dessiner, valider, miner, afficher.

• Fait
  Pipeline complet dessin → candidat → votes → bloc → écransArchitecture pull : aucun ESP n’est contacté directement.
• Fait
  Pod Studio : page de dessin pixel-exacte (Essentiel / Studio / Pro)Moteur pur, replay identique à l’image, brouillon local.
• Fait
  Chaîne de blocs liée par SHA-256, conservée sans expirationRegistre unique dans Redis (voir « Décentralisation »).
• Fait
  Écrans : OLED, e-ink 2,7″ / 2,9″, TFT 1,8″ / 2,8″Le TFT 2,8″ tactile a voté en v2 (blocs #100, #103, #118). La station UNO R4 + TFT 1,8″ + capteurs (r4tft18-2.3) est intégrée mais seulement partiellement observée : voir « Station R4 ».
• Fait
  Cartes : ESP8266 et UNO R4 WiFiMêmes protocoles, firmwares par famille.
• Fait
  Profils d’artistes, appairage des écrans, autorisation d’un autre équipement
• Fait
  Page Réseau en direct (constellation, flux observés ou reconstitués)Les flux reconstitués sont signalés par une astérisque.
• Fait
  Outil « Ancien ➜ Nouveau » pour migrer les blocs d’une carte reflashée
• En cours
  Cercles privés d’artistes : invitations avec consentement, droits côté serveur, messages texteLivré et testé en mémoire ; à essayer avec deux profils réels. Aucun média.
• À faire
  Partage d’images dans les cercles (PNG, JPEG, GIF)Demande un stockage objet privé (jamais Redis) : service et coût à choisir.
• En cours
  Remix : œuvre dérivée d’un bloc (filiation engagée dans le hash) et reprise d’un dessin rejetéLivré et testé côté serveur et studio ; pas encore essayé avec un vrai vote en production. Aucune animation pour l’instant.

Une animation est un bloc comme un autre, avec son atelier de création.

• Fait
  Animations dans le consensus (clip PBC1, bloc kind: animation, galerie)
• Fait
  Lecture sur TFT 2,8″, TFT 1,8″ et OLEDMultiscreen : animation sur l’OLED, image fixe sur l’e-ink, vérifié. Station R4 + TFT 1,8″ (clip PBC1 lu depuis la carte SD) : intégrée et compilée, jamais observée sur la carte.
• Fait
  Atelier d’animation refait : plein écran, 3 modes, 7 brosses, fantôme, retour/annulerVérifié dans l’aperçu ; essai sur téléphone réel à faire.
• À faire
  Canvas maître 256×128 exporté par écran avec trameSans reflash. Étape suivante de l’atelier.
• À faire
  Animations VALIDÉES par calcul (racine, empreinte et métriques par image)Spécification relue par l’audit et référence de calcul livrée (TypeScript et C++ identiques sur plus de 200 clips) ; l’automate de lecture du clip est aussi compilé pour l’ESP8266 et l’UNO R4 (moins de 2 Ko de RAM, jamais essayé sur carte) ; aucun firmware ne l’utilise encore : aujourd’hui les animations sont encore votées en v1, écho du score serveur. Depuis le 28/10 un vote v1 « écho » est de nouveau admis pour les animations seulement (ANIM_V1_VOTE, transitoire) : ce n’est pas une validation du contenu.

Les cartes recalculent l’image et signent : fini l’écho du score du serveur (images fixes).

• Fait
  Métriques entières « pod-metrics-2 » (entropie, transitions, runs)Identiques sur serveur, ESP8266 et R4 au ppm près (test différentiel C++/TypeScript).
• Fait
  Vote v2 : SHA-256 du contenu + métriques + verdict, signé Ed25519
• Fait
  Votes atomiques (script Redis) et refus v2 non bloquants pendant le canari
• Fait
  Vote v2 sur ESP8266 (e-ink 2,9″, multiscreen, TFT 1,8″) et R4 (e-ink 2,9″, 2,7″, 2,7″+OLED, TFT 1,8″)Essai réel à 4 appareils, 06/10/2026 ; le 14/10/2026, R4 e-ink 2,9″, R4 TFT 2,8″, ESP8266 e-ink 2,9″ et multiscreen ont voté en v2 sur la carte (blocs #100, #101, #103).
• Fait
  Réseau de vote réel : seuls les firmwares qui savent voter en v2 comptent, reçoivent et votentEn production le 14/10/2026 : un vote « écho » v1 ne suffit plus à miner (au moins un vote v2 exigé), les appareils non appairés, inactifs, capteurs ou à l’ancien firmware sont exclus du quorum et du vote. Interrupteur de retour arrière documenté. Le 27/10/2026 l’électorat réel ne comptait qu’un appareil (animations impossibles à voter depuis le 14/10, seuil d’exclusion à un seul manque) : fiabilisation en cours, voir « Toute carte capable vote tout dessin ».
• En cours
  Toute carte capable de valider vote sur tout dessin, quel que soit son écranLe serveur invite déjà tous les appareils capables, sans filtrer l’écran. Corrections locales non flashées (28/10) : candidat conservé quand une image arrive, tampon pris à la demande, refus « blank » R4 corrigé pour les fonds colorés, quorum à trois manques consécutifs, électorat figé dans le candidat. Les capteurs seuls restent exclus du quorum aujourd’hui ; les validateurs sans écran passeront par une capacité explicite (non implémentée). Plan : docs/PLAN_RESEAU_VALIDATEURS_ET_STATION_R4_2026_10_28.md.
• En cours
  BWR + OLED : écran capteur propre et animations du réseau sur l’OLEDInstallé le 29/10/2026 chez le porteur (eink29bwr-2.13) : la mise à jour a fonctionné, mais l’OLED n’a encore reçu aucune animation (aucune animation n’a été minée). Remix d’une animation corrigé (l’animation entière se rouvre dans l’atelier), l’OLED apparaît comme second écran dans la vue réseau, qui rejoue la boucle des écrans animés. Chantier suspendu (28/10/2026) : la carte du cousin est figée depuis la réception de la première animation, en attente de son redémarrage ; la cible reste un BWR qui déclare lui-même ses deux écrans comme le 2,7″ + OLED.
• En cours
  Vote v2 sur l’ESP8266 e-ink 2,7″ « seul »Firmware eink27bw-2.1 compilé ; essai sur la carte à faire.
• Fait
  Vote v2 sur R4 + TFT 2,8″ tactileVote v2 observé sur la carte le 14/10/2026 (blocs #100 et #103 : R4 + TFT 2,8″ parmi les validateurs). Historique : un canari SANS vote avait été préparé (client TLS borné, JSON et carte SD sur piles dédiées, instrument de pile) : compilé et vérifié sur l’hôte, jamais essayé sur la carte ; le vote, lui, reste à reprendre dans un lot suivant (marge de pile encore trop étroite).
• Fait
  Ed25519 sur les cartes UNO R4 : calcul sur une pile dédiéeValidé sur carte : Ed25519 sur pile dédiée (PodEd), plus aucun appel direct hors de cette enveloppe ; marge relevée à chaque signature.
• Fait
  Réseau sécurisé (TLS) des cartes UNO R4 : transactions sur une pile dédiéeValidé sur carte (UNO R4) : toute transaction TLS tourne sur une pile dédiée, client TLS borné (PodBoundedSSL), appels Wi-Fi enveloppés ; les marges sont relevées sur chaque firmware R4 compilé.
• À faire
  Archiver une trace série par variante (octets, hash, métriques, verdict)Preuve reproductible à joindre aux notes de canari.

Rendre un bloc vérifiable par n’importe qui, sans faire confiance au serveur.

• En cours
  Conserver les votes signés dans le bloc, liés au parentHashCode livré derrière un interrupteur, éteint par défaut, pas encore essayé sur le réseau réel : aujourd’hui les votes sont supprimés après le minage. La liaison au parentHash attend le vote v3 (firmware).
• En cours
  Vérificateur public (recalcule hash, métriques, signatures, comité)Vérificateur et outil en ligne de commande livrés (hash, reçus, signatures, contenu) ; le comité et un second vérificateur indépendant restent à faire.
• En cours
  Un vote par profil, auteur exclu, appairage exigé pour voterCode livré derrière un interrupteur, éteint par défaut ; à essayer en mode « ombre » avant de l’activer. Aujourd’hui un appareil non appairé peut encore voter.
• À faire
  Preuve de possession de la clé à l’enregistrement, épinglage et récupération par le profil
• En cours
  Comité déterministe de 7 profils, seuil 2/3, mineur rejouableCode livré derrière un interrupteur, éteint par défaut, pas encore essayé sur le réseau réel ; remplacera le quorum de 51 % et le tirage aléatoire. Verrouillé deux fois (un accusé explicite du risque est exigé) : la tolérance aux profils malhonnêtes ne doit pas être annoncée tant que le tirage reste calculable à l’avance par l’auteur.
• À faire
  Règles N2 versionnées, motif de refus signé, revérifiées par le serveur
• En cours
  Réputation par profil sur mensonges objectivement prouvablesCompteurs livrés derrière l’interrupteur du comité (observation seulement, aucun effet bloquant) ; aucun taux de menteurs n’est affiché ni annoncé.
• En cours
  Simulation avec une fraction d’appareils malhonnêtes (taux de tolérance mesuré)Simulateur en mémoire livré ; il montre qu’un auteur peut choisir son comité si la graine est calculable à l’avance : la tolérance ne doit pas être annoncée avant une balise aléatoire postérieure à la soumission.
• À faire
  Ancrage périodique de la tête de chaîne (dépôt public ou horodatage)

Séparer la gestion des écrans du consensus, pour que d’autres appareils puissent participer.

• En cours
  Extraire un noyau portable sans écran ni réseau (flux → hash + métriques + message de vote)Noyau C++ livré (règles, hash salé, vote v3, reçus, comité, mineur, bloc) et identique à la référence TypeScript ; aucun firmware ne l’utilise encore, l’adoption se fera au grand reflash.
• En cours
  Vecteurs de test officiels exécutés sur TypeScript, ESP8266, R4 et PCPlus de mille vérifications générées par la référence TypeScript et retrouvées à l’identique par le noyau C++ sur PC ; ESP8266 et R4 : l’auto-test compile, il n’a jamais tourné sur une carte.
• En cours
  Adaptateurs ESP8266, R4, ESP32 et PC/Raspberry PiAdaptateurs de calcul SHA-256 pour PC, ESP8266 et R4 livrés (compilés, jamais essayés sur carte) ; l’automate d’animation y est compilé avec ses budgets mémoire mesurés à la compilation ; ESP32 et Raspberry Pi natif restent à faire.
• À faire
  Nœuds de validation sans écran (rôle validator)Aujourd’hui un profil capteur seul est EXCLU du quorum. Cible décidée : une capacité de validation explicite et déclarée, sans écran ; non implémentée.
• À faire
  Publication ouverte (spécification, licence, exemples) en version expérimentaleAprès gel du protocole v3.

Un seul reflash groupé, puis des mises à jour à distance signées.

• Fait
  Identifiants Wi-Fi hors du binaire (portail de configuration)Parcours à deux QR observé sur ESP8266 (TFT 1,8″, e-ink 2,9″ BWR, multiscreen) et sur UNO R4 e-ink 2,9″ ; la matrice de compatibilité donne le niveau de preuve par profil.
• En cours
  Mises à jour à distance signées (manifeste dans /api/pull, anti-retour arrière, déploiement par vagues)Prouvée sur certaines familles ESP8266 (tft18 2.7→2.8, eink29bwr 2.4→2.5, multiscreen 2.6→2.7). UNO R4 : le produit complet r4tft18 a été mis à jour UNE fois en laboratoire (clés de test, serveur HTTP local) ; aucune OTA R4 distribuée sur Internet n’est prouvée.
• En cours
  Cartels e-ink : zone sûre puis réglage par appareil (superposé / cadre / masqué)Livré : l’éditeur hachure les bandes du cartel (ce que l’écran efface) et prévient avant l’envoi. Reste le réglage par appareil (superposé / cadre / masqué), qui demande le grand flash.
• À faire
  Génération des clés avec une source d’aléa matérielle (ESP8266)
• À faire
  Connexions TLS authentifiées (empreinte ou certificat)
• En cours
  Station UNO R4 + TFT 1,8″ + DHT22 + SGP40 + microSD (r4tft18-2.3)Observé sur la carte : DHT22, SGP40 (brut), SD, enregistrement et pull ; un refus signé « blank » (corrigé localement). Intégré mais jamais observé : affichage d’une œuvre du réseau, ACK, animation depuis la SD, vote d’acceptation, indice COV Sensirion face à une référence.
• À faire
  Hash salé par appareil et signature spatiale de l’imageRecherche : détecter copies et réponses recopiées.

Passer d’une chaîne centralisée à témoins signés à un réseau de nœuds qui la répliquent.

• À faire
  Nœuds Raspberry Pi : miroir de la chaîne, vérification complète, validateurs puissants
• À faire
  Auditeurs de geste : rejouer le dessin pour vérifier qu’il est fait à la main
• À faire
  Co-signature de la tête de chaîne par le comité
• À faire
  PoDScan : explorateur public de blocs, de votes signés et de validateursÉquivalent d’un explorateur de chaîne.
• À faire
  Réplication de la chaîne au-delà d’un registre unique