Sylvain Duchesne
f378c71739
Lot F de la revue adverse. Chaque affirmation relue dans `nextgraph-rs` par symbole avant
d'être réécrite ; aucune ne s'est révélée exacte.
- `AddLink` / `RemoveLink` / `RepoLinkV0` étaient présentés comme **implémentés**. Leurs
arms de vérificateur sont des `Ok(())`, là où celui d'`AddRepo` fait un vrai travail, et
rien ne les construit. Le tableau dit désormais « déclaré, stubbé », et la conclusion qui
en déduisait « le registre existe, seule la livraison manque » est corrigée : **les deux
bouts** sont déclarés-et-stubbés.
- La table `inboxes` était dite « reconstruite vide à chaque session » — elle est
repeuplée au chargement, et la clé privée d'inbox est persistée par repo. L'argument de
sécurité qui s'appuyait dessus repose maintenant sur le bon motif : la table est **par
vérificateur**, pas éphémère.
- La citation de « `doc_create` laisse `inbox: None` » pointait un constructeur réservé aux
tests ; re-ciblée sur le chemin de production.
- `ExtObjectGet` était dit « le seul » primitif accessible à un non-membre et exigeant les
clés : il y en a trois, et sa structure n'a aucun champ de clé.
- L'en-tête de `public-store.ts` était marqué **VERIFIED** alors qu'il repose sur un
commentaire de doc, et la condition qu'il citait (« si les brokers pairs l'autorisent »)
disparaissait de la conclusion. Requalifié en **pari**, condition rétablie.
- Deux sur-restrictions corrigées (ce qu'écrit le traitement d'un `ContactDetails`, et le
prétendu « miroir 1:1 » de `NuriV0`, qui a dix champs).
**Sur la grammaire du ReadCap, une correction de MA correction.** J'avais écrit que la
forme `{target}:r:{cap}` était notre invention. Faux : le segment `r:` et son encodage sont
ceux d'amont, et l'auteur de NextGraph l'a énoncé. Ce qui est établi est plus étroit —
aucun parseur amont n'accepte aujourd'hui un NURI de repo qui le porte, et le segment est
produit comme valeur de champ. J'avais conclu d'une implémentation absente à ce que la
cible ferait, ce que la doctrine du projet interdit nommément. Seule « P1b remplace la
valeur, pas la forme » est corrigée, requalifiée en **pari**.
**Et la surface ne publie plus de type que personne n'utilise.** `export * from
"./model/types"` publiait huit types en bloc ; c'est une liste nommée de six. `ReadCap`
sort — aucune signature publiée ne le prend ni ne le rend, seules deux fonctions privées
de `inbox.ts` s'en servent — et `InboxScope` aussi. Un type n'est publié que si une
signature publiée l'utilise.
197 tests, 0 échec ; les trois typechecks propres ; `lint` sans erreur.
3.4 KiB
Vision & principles of the @ng-eventually/sdk polyfill
Purpose
A stand-in faithful in SHAPE to NextGraph's future primitives. Single objective: that consumers (Festipod) be coded against the CORRECT mental model — the one of finished NextGraph — and have NOTHING to rewrite when NextGraph provides the real primitives.
What the polyfill is NOT
A security layer. The shared wallet (everyone shares the same keys) plus the absence of real crypto make the emulation infinitely less secure than a wallet-per-user — it is a dev/staging vehicle, not a goal. Insecurity is ACCEPTED. An attacker who bypasses the emulation is not our problem.
The only criterion: shape-fidelity, with RIGOR
The exposed surfaces must match the exact SHAPE of the future primitives, even where enforcement is simulated. The failure mode to avoid: exposing the wrong shape → the consumer codes against a model that will not exist → rewrite. The ACL inversion of ReadCaps was exactly that defect (an ACL where the real thing is key possession) — a lack of rigor.
Simulating crypto to PREVENT shortcuts
Without a minimum of crypto simulation, damaging shortcuts get taken (reading the plaintext, falling back on ACLs). The polyfill therefore simulates the final mechanism, enough to hold this invariant:
A
did(bare id, WITHOUT a ReadCap) and a NURI (WITH a ReadCap) are treated GENUINELY differently: the former does NOT allow reading the data; the latter is SUFFICIENT and REQUIRED.
Concretely, in the target: a document's data is stored encrypted (per-doc symmetric encryption, however lightweight); the ReadCap = the key; without it, decrypting/reading is impossible. No ACL, no plaintext accessible "on the side". Obtaining read access = holding the key, exactly as in the target model.
Not yet true here, and saying so matters. The shape is in place — possession decides, every access is confined to the connected virtual user, caps are stored and read back — but the cap value is the constant
OKand nothing is encrypted. Per-document encryption is P1b, and it is one function (mintCap, inemulated-verifier/caps.ts— this saidnuri.tsuntil 2026-08-10). Until it lands, nothing this library does may be described as anonymous or private.
Shape consequences (to respect everywhere)
- Everything is keys and URLs. There is no notion of membership, role, or authorization list in the model: only symmetric and asymmetric cryptography, URIs, and who holds which key. Any exposed shape that looks like an ACL, a
member, arole, or apermissionis a wrong shape, whatever scaffolding one may otherwise read in the current state of NextGraph. - Reading = possession of the read key (ReadCap =
{id, key}). A bare id (adidwithout a ReadCap) does not read. - Writing = possession of the write key — a key distinct from the read key, hence a distinct axis, but possession too.
- Sharing a cap = sealing it to a recipient (durable delivery, at share time — NOT an ACL re-declared every session).
- Revocation = re-key (new key; former holders keep the old state). Non-retroactive.
- Cap-less reference (naming/pointing without reading) distinct from the cap-bearing reference.
See readcap-and-nuri-model.md (the real model, verified in nextgraph-rs) and briefs/2026-07-20-caps-emulation-alignment.md (the alignment effort).