La section listait quatre « besoins » — nommer, donner à lire, faire trouver,
joindre. C'était confondre ce qu'un acte FAIT avec ce dont son résultat dépend.
Un émetteur ne fait que deux choses, et tout cas d'usage est l'une des deux :
- transmettre la RÉFÉRENCE (`access` vide) : le destinataire peut nommer le
document — et le lire si celui-ci se trouve dans un store public. Même valeur
transmise, résultat différent, décidé par l'endroit où est le document et non
par ce qu'on a envoyé.
- transmettre la référence ET la clé : le destinataire lit. Irréversible.
« Faire trouver » n'était donc pas un troisième acte, mais le premier appliqué à
un document en store public. Et « joindre » n'est pas un acte du tout : le
locator dit si la référence est assez COMPLÈTE pour être résolue par un
inconnu — cela relève du destinataire.
D'où la conséquence pour tout ce que cette bibliothèque expose : un appel
remet la clé ou ne la remet pas, et ce doit être l'intention explicite de
l'appelant — jamais l'effet de bord d'une demande de référence.
Où en est la bibliothèque, acte par acte : transmettre la référence est couvert
sans appel dédié (toutes les références rendues sont nues) ; transmettre
référence et clé l'est par `inbox.share`. Et une propriété du modèle n'est PAS
émulée : un document en store public est lisible depuis une référence nue, là où
`mayReach` exige toujours un cap détenu. L'écart va dans le sens sûr — nous
sous-accordons — mais une app ne peut pas exprimer « je diffuse largement, la
référence suffit », et son seul contournement serait de remettre la clé, ce qui
casse la confidentialité composable.
Section redondante supprimée, et le mot banni retiré des exemples.
Sylvain Duchesne
32ef756b0b