Reconnexion/festipod
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs(concept): réserve durable sur le pseudonyme permanent de l'overlay

Browse Source 
app-security/caveat_stable-overlay-pseudonym (nouveau) — toute référence
cap-less vers un document protected expose le `✌️` du store, identique partout
et pour toujours. BLAKE3 non inversible le rend OPAQUE, d'où la tentation de le
croire INOFFENSIF : ce sont deux choses différentes. C'est la constance qui
expose, pas la lisibilité. Un seul recoupement, une seule fois, et tout
l'historique bascule — y compris ce qui a été publié des années plus tôt.

Aucune porte de sortie, vérifié sur quatre axes : pas de rotation d'overlay,
store id généré une fois pour toutes, aucune migration de contenu, aucune forme
de référence n'évitant d'exposer l'overlay. Le renouvellement de capabilities
ne toucherait que l'inner ; l'outer y survit.

Placé en app-security et non dans le brief inscriptions : un brief se dissout à
sa graduation, la réserve doit lui survivre. Le brief n'en garde qu'un résumé
et pointe dessus. Déclencheurs élargis (anonymat, pseudonyme, traçage,
corrélation, overlay, cap-less) pour qu'elle remonte quand on s'apprête à
concevoir de l'« anonyme ».

Consigne pratique qui en découle : ne jamais présenter une action comme
« anonyme » si elle fait circuler une référence cap-less — c'est pseudonyme,
et le pseudonyme est permanent.

Dédup par `✌️` validée par le PO ; le brief le note.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014GbGgNEHRejVKoREvFuDFg
This commit is contained in:
Sylvain Duchesne
2026-07-27 12:31:55 +02:00
parent 42dbfd0c34
commit ab077d8080
3 changed files with 50 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.project/concepts/data-layer/brief_2026-07-20_attendance-set-model.md
+4 -2
View File
@@ -33,13 +33,15 @@ Vérifiés par lecture de `nextgraph-rs`. Le détail et les pointeurs vivent cô
## La dédup : sur quoi exactement
**Hypothèse de travail — à confirmer par le PO.** Le mécanisme que j'identifie derrière « il a normalement assez d'informations pour dédupliquer » :
**Validé par le PO (2026-07-27).** Le mécanisme derrière « il a normalement assez d'informations pour dédupliquer » :
Le segment `:v:` d'un NURI ne vient **pas du document** mais de **son store** (`ProtectedStore(id) → outer(id)`). Or une personne a **un seul** store protected. Donc **toutes ses Participations portent le même `:v:`**, quel que soit le nombre d'objets qu'elle crée. Le créateur déduplique là-dessus : deux références de même `:v:` dans le Set d'un même événement = la même personne. **Sans jamais savoir qui.**
Conséquence de conception : le Set est **indexé par `:v:`** — au plus une référence par `:v:`. `Set.size` = nombre de `:v:` distincts = nombre de personnes distinctes.
### La contrepartie, à connaître avant de la découvrir plus tard
### La contrepartie — réserve durable, à ne pas perdre
> **Elle vit dans `app-security/caveat_stable-overlay-pseudonym`**, pas ici. Ce brief a vocation à être dissous à sa graduation ; la réserve, elle, doit survivre. Résumé ci-dessous, référence là-bas.
Ce `:v:` 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. Il ne dit pas *qui* (`BLAKE3(store_id)` n'est pas inversible), mais c'est un **handle constant**, le même partout et pour toujours.