Files

T

Sylvain Duchesne ead5aececf docs: l'overlay est store-scopé ; retrait de la fausse piste "membership"

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

2026-07-27 12:07:24 +02:00

3.2 KiB

Raw Blame History

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).

3.2 KiB Raw Blame History

Vision & principes du polyfill @ng-eventually/client