Sylvain Duchesne
ead5aececf
readcap-and-nuri-model — nouvelle section sur l'OVERLAY, le concept qui manquait à la référence. C'est l'espace réseau d'un STORE : deux formes (outer = BLAKE3 public du store_id, calculable par tous ; inner = BLAKE3 keyed par le ReadCapSecret, réservé aux détenteurs de la clé). Le `✌️` d'un NURI de DOCUMENT porte l'overlay de son store — VÉRIFIÉ de bout en bout, avec une contre-preuve mécanique : dans Store, get/put/del/has passent tous `&self.overlay_id`, donc tous les documents d'un store partagent le namespace de blocs et un overlay par-document est structurellement impossible. Conséquence documentée, qui contraint tout modèle de présence anonyme : le `✌️` est un pseudonyme stable et permanent de la personne, présent dans toute référence cap-less vers n'importe lequel de ses documents protected. Le même bit d'information sert à dédupliquer sans lire ET à tracer — indissociables. vision — correction d'une forme fausse. Le document affirmait « écriture = membership/permissions », en miroir de « lecture = possession de clé ». Faux : il n'y a pas de notion d'appartenance dans le modèle, uniquement des clés et des URLs. Toute forme en member/role/permission est une MAUVAISE forme. brief caps — la section « périmètre élargi : WriteCap = membership » est retirée, conservée barrée comme garde-fou, avec la leçon de méthode qui vaut plus qu'elle : lire l'état courant de nextgraph-rs pour en DÉDUIRE la forme cible est une erreur — le source contient de l'échafaudage inerte (AddMember, PermissionV0, verify_sig jamais appelé hors tests). Le source sert à vérifier un mécanisme, jamais à inférer une intention. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014GbGgNEHRejVKoREvFuDFg
62 lines
3.2 KiB
Markdown
62 lines
3.2 KiB
Markdown
# 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)
|
|
|
|
- **Tout est clés et URLs.** Il n'y a **pas** de notion d'appartenance, de rôle ni
|
|
de liste d'autorisation dans le modèle : uniquement de la cryptographie
|
|
symétrique et asymétrique, des URIs, et qui détient quelle clé. Toute forme
|
|
exposée qui ressemble à une ACL, un `member`, un `role` ou une `permission` est
|
|
une **mauvaise forme**, quel que soit l'échafaudage qu'on peut lire par ailleurs
|
|
dans l'état courant de NextGraph.
|
|
- **Lecture = possession de la clé de lecture** (ReadCap = `{id, clé}`). Un id nu
|
|
(un `did` sans ReadCap) ne lit pas.
|
|
- **Écriture = possession de la clé d'écriture** — une clé **distincte** de celle
|
|
de lecture, donc un axe distinct, mais **de la possession elle aussi**.
|
|
- **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).
|