docs(concepts): NextGraph multi-user design — ng-eventually polyfill, discovery, apps/services

Captures the design worked out this session:
- decision: ng-eventually generic polyfill library (external repo) encapsulates all
  multi-user compensation; @ng-eventually/client is SDK-identical, app depends only on it.
- decision: discovery via a single global index fed through its inbox (owned doc,
  materialized) — no Group store; index owner = open question (singleton app, deferred).
- knowledge: NextGraph apps/services are mono-user with no global data (corrects the
  earlier 'index service with its own wallet' model).
- reconciled shared-wallet-shim brief (per-entity docs, login flow, polyfill terminology),
  authorization-matrix (no Group store), data-layer stack (ng-eventually indirection).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Sylvain Duchesne
2026-06-22 16:35:58 +02:00
parent 222658a75d
commit 3ca2d10c49
6 changed files with 224 additions and 36 deletions
@@ -127,6 +127,8 @@ Le doc PdR (dans le `public_store` de l'hôte) a une **inbox** native : reçoit
Sur le périmètre validé, **aucune donnée ne demande de Group store**. Tout tient dans : 3 stores natifs par utilisateur + Dialog stores + inboxes natives. Les Group stores ne deviennent nécessaires que si le modèle d'écriture événement est « wiki », ou si communautés/suivi/collaboration multi-hôte reviennent dans le périmètre.
> **Note (2026-06-17) — la découverte n'impose PAS de Group store.** On a un instant cru qu'un **index global des événements** exigerait un document à écriture ouverte (= Group store). La [[decision_2026-06-16_discovery-model]] a finalement retenu un index **possédé** (lecture publique) **alimenté via son inbox** (le créateur y *dépose* une référence ; le propriétaire matérialise). Comme l'**inbox est une primitive native de tout document**, l'index tient dans un `public_store` ordinaire → **« aucun Group store » reste vrai**. Les Group stores ne redeviennent nécessaires que pour communautés / collaboration multi-écrivains réels.
### Implication pour [[brief_2026-05-17_multi-store-refactor]]
Ce brief y propose une structure à 4 niveaux de Group stores. **Cette analyse dérive une structure différente** (3 stores natifs + Dialog, sans Group) parce que les concepts qui justifient les Group stores ont été mis hors périmètre. À reconcilier à l'exécution.