Sylvain Duchesne
1791c31f42
vision.md — la charte : le polyfill n'est PAS une couche de sécurité (wallet
partagé + pas de crypto = insécurité ACCEPTÉE) ; seul objectif = exposer la
BONNE FORME des primitives futures pour que les consommateurs n'aient rien à
réécrire. Invariant tenu par une simulation crypto légère : un `did` nu (sans
ReadCap) ne permet PAS de lire ; un NURI avec ReadCap est suffisant et requis.
readcap-and-nuri-model.md — le vrai modèle, VÉRIFIÉ par lecture de
`nextgraph-rs` : ReadCap = ObjectRef {id BLAKE3, clé ChaCha20} = possession de
clé, PAS une ACL ; grant = sceller la clé à l'inbox du destinataire ;
révocation = re-key grossier et non-rétroactif ; grammaire NURI cap-less vs
cap-porteur (le segment `:k:` est le discriminant) ; table des divergences avec
l'émulation `caps.ts` (aujourd'hui une ACL — l'inversion exacte).
briefs/2026-07-20-caps-emulation-alignment.md — le chantier d'alignement :
spike P0 keyless-resolve (verdicts vérifiés : existence sans clé OUI,
détection de suppression sans clé NON, confidentialité OUI), puis P1 cap-less
vs cap-porteur, P2 possession, P3 re-key, P4 migration d'API. Inclut la revue
adverse (WriteCap = membership et non possession ; sans crypto la privacy de
lecture n'est pas applicable ; migration = re-architecture consommateur).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014GbGgNEHRejVKoREvFuDFg
2.7 KiB
Vision & principes du polyfill @ng-eventually/client
Raison d'être
Un stand-in fidèle en FORME des primitives futures de NextGraph. Objectif unique : que les consommateurs (Festipod) soient codés contre le modèle mental CORRECT — celui de NextGraph fini — et n'aient RIEN à réécrire quand NextGraph fournira les vraies primitives.
Ce que le polyfill n'est PAS
Une couche de sécurité. Le wallet partagé (tout le monde partage les mêmes clés) + l'absence de vraie crypto rendent l'émulation infiniment moins sécurisée qu'un wallet-par-utilisateur — c'est un véhicule de dev/staging, pas un but. L'insécurité est ACCEPTÉE. Un attaquant qui contourne l'émulation n'est pas notre problème.
Le seul critère : shape-fidelity, avec RIGUEUR
Les surfaces exposées doivent matcher exactement la FORME des primitives futures, même là où l'enforcement est simulé. Le mode d'échec à éviter : exposer la mauvaise forme → le consommateur code contre un modèle qui n'existera pas → réécriture. L'inversion ACL des ReadCaps était exactement ce défaut (une ACL là où le réel est possession de clé) — un manque de rigueur.
Simuler la crypto pour EMPÊCHER les raccourcis
Sans un minimum de simulation crypto, des raccourcis préjudiciables sont pris (on lit le clair, on retombe sur des ACLs). Le polyfill simule donc le mécanisme final, assez pour tenir cet invariant :
Un
did(id nu, SANS ReadCap) et un NURI (AVEC ReadCap) sont traités VRAIMENT différemment : le premier ne permet PAS de lire la donnée ; le second est SUFFISANT et REQUIS.
Concrètement : la donnée d'un document est stockée chiffrée (chiffrement symétrique par-doc, même léger) ; le ReadCap = la clé ; sans elle, impossible de déchiffrer/lire. Pas d'ACL, pas de clair accessible « à côté ». Obtenir la lecture = détenir la clé, exactement comme en cible.
Conséquences de forme (à respecter partout)
- Lecture = possession d'une clé (ReadCap =
{id, clé}). Un id nu ne lit pas. - Écriture = membership/permissions (primitif distinct — PAS de la possession).
- Partage d'un cap = le sceller à un destinataire (livraison durable, au moment du partage — PAS une ACL re-déclarée à chaque session).
- Révocation = re-key (nouvelle clé ; les anciens détenteurs gardent l'ancien état). Non-rétroactif.
- Référence cap-less (nommer/pointer sans lire) distincte de la référence cap-porteuse.
Voir readcap-and-nuri-model.md (le vrai modèle, vérifié dans nextgraph-rs) et
briefs/2026-07-20-caps-emulation-alignment.md (le chantier d'alignement).