doctrine: Festipod treats @ng-eventually/client as a finished NextGraph SDK
Enforce the project boundary: Festipod is written as if NextGraph were a mature, finished SDK; @ng-eventually/client IS that SDK. NO current-NextGraph-state, simulation, polyfill, shim, mono-store, store-id or broker-internal knowledge remains in this repo — it now lives in the @ng-eventually/client repo. - Dissolved the `nextgraph-platform` concept entirely (12 leaves — all current-state/simulation, now in the lib's docs/). Rescued the genuine domain parts into functional-domain/knowledge_data-scopes-and-discovery.md (which entity → which scope; product-level discovery/notification intent), framed as SDK usage with no mechanism. - data-layer re-anchored to "how Festipod persists via the SDK": stripped mono-store/private_store_id/RepoNotFound/DataCloneError/FESTIPOD_MULTISTORE. Deleted the current-SDK compensation leaves (private-store-scope, multistore, the 2026-03-17 ADRs, conditional-ng-init). Kept/reworded the domain + app leaves; caveat_participation-deletion reduced to the domain contract. - app-security reworded (isolation delegated to the SDK; app trusts it). - AGENTS.md: dropped the nextgraph-platform row, reworded data-layer/ functional-domain/app-security, added the "Frontière SDK NextGraph" note. - Fixed dangling [[links]]; concept lint clean (43 leaves). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Sylvain Duchesne
@@ -1,8 +1,8 @@
|
||||
---
|
||||
type: _overview
|
||||
summary: Modèle produit Festipod — le point de rencontre greffé sur un événement public comme unité de valeur, ses acteurs et ses concepts métier
|
||||
summary: Modèle produit Festipod — le point de rencontre greffé sur un événement public comme unité de valeur, ses acteurs, ses concepts métier, et les périmètres de confidentialité (public/protected/private) par entité
|
||||
triggers:
|
||||
keywords: [point de rencontre, rencontre, greffe, greffer, événement, déclarant, hôte, inscrit, inscription, communauté, connexion, festival, déduplication]
|
||||
keywords: [point de rencontre, rencontre, greffe, greffer, événement, déclarant, hôte, inscrit, inscription, communauté, connexion, festival, déduplication, découverte, périmètre, scope, public, protected, privé]
|
||||
paths: ["src/modules/*/features/**"]
|
||||
---
|
||||
|
||||
@@ -16,13 +16,14 @@ Le **domaine fonctionnel** de Festipod : ce que le produit promet et le vocabula
|
||||
|
||||
Festipod laisse les utilisateurs créer des **points de rencontre** qui se *greffent* sur des **événements publics** existants. L'événement (festival, conférence…) n'est qu'un *prétexte* et un point d'ancrage spatio-temporel ; la valeur produite, c'est le point de rencontre. **On s'inscrit à un point de rencontre, jamais à un événement.**
|
||||
|
||||
## Périmètre & sécurité
|
||||
## Périmètre & confidentialité
|
||||
|
||||
Le modèle d'**autorisations / confidentialité** (qui voit quoi : « données personnelles = réseau seulement », anonymat via inbox, capabilities) n'est pas encore implémenté — il vit aujourd'hui comme incubation dans [[brief_2026-05-18_authorization-matrix]] (concept `nextgraph-platform`). Il graduera en règles/`behavior_` quand le multi-user atterrira. C'est la raison pour laquelle il n'y a pas encore de concept `app-security` distinct.
|
||||
Le modèle produit de **qui voit quoi** — données personnelles réservées au réseau, événements/PdR publics, notification d'inscription identifiée-ou-anonyme — est un fait métier : voir [[knowledge_data-scopes-and-discovery]]. La matrice d'autorisations détaillée (acteur × verbe) et son incubation vivent dans le concept `app-security` ([[brief_2026-05-18_authorization-matrix]]).
|
||||
|
||||
## Liens
|
||||
|
||||
- [[knowledge_business-model]] — l'inversion événement / point de rencontre
|
||||
- [[knowledge_actors-and-concepts]] — référence des acteurs et concepts métier
|
||||
- [[knowledge_data-scopes-and-discovery]] — périmètres public/protected/private par entité + découverte
|
||||
- [[knowledge_roadmap]] — fonctionnalités actuelles vs évolutions à venir
|
||||
- [[brief_2026-06-15_event-deduplication]] — défi ouvert de déduplication des événements en P2P
|
||||
- `nextgraph-platform` — où vit la dérivation de la structure de données cible (authz matrix, multi-store)
|
||||
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
type: knowledge
|
||||
summary: Modèle produit de confidentialité et de découverte — chaque entité vit dans un SCOPE (public / protected / private) selon qui doit la voir ; événements & points de rencontre = public, profil réseau & participations = protected (réseau), settings = private ; connexions bilatérales = scope dialog ; la découverte lit un index global d'événements
|
||||
---
|
||||
|
||||
# Périmètres de données et découverte
|
||||
|
||||
Le modèle **produit** de qui voit quoi, et comment on trouve les événements. C'est du **domaine** : le *comment* technique (documents, capabilities, index) est assuré par le SDK de données `@ng-eventually/client` — l'app décrit seulement **l'intention métier**.
|
||||
|
||||
## Trois périmètres (scopes) par donnée
|
||||
|
||||
Chaque entité est stockée dans le **scope** correspondant à qui doit pouvoir la lire :
|
||||
|
||||
| Entité | Scope | Qui lit |
|
||||
|---|---|---|
|
||||
| Événement (l'ancrage) | **public** | tout le monde |
|
||||
| Point de rencontre (PdR) | **public** | tout le monde |
|
||||
| Profil réseau (nom, avatar, bio, ville, intérêts) | **protected** | le titulaire + ses connexions |
|
||||
| Participation / inscription à un PdR | **protected** | l'inscrit + ses connexions |
|
||||
| Index des connexions | **protected** | le titulaire + ses connexions |
|
||||
| Profil privé (settings, email, préférences) | **private** | le titulaire seul |
|
||||
| Connexion A↔B (lien bilatéral, + messagerie future) | **dialog** | les deux utilisateurs |
|
||||
|
||||
Principe directeur : **le statut « public » (PdR, événement) et « personnel » (profil, participations, connexions) coexistent dans un même utilisateur.** Les informations personnelles sont réservées au **réseau** (connexions bilatérales), jamais visibles d'un utilisateur lambda.
|
||||
|
||||
- **PdR / événement = publics universels.** Tout utilisateur peut lire et s'abonner ; créer un PdR rend hôte, créer un événement rend déclarant (aucun prérequis).
|
||||
- **Hôte = seul détenteur des droits d'écriture** sur son PdR ; le déclarant n'a aucun droit particulier sur les PdR greffés sur son événement.
|
||||
- **Connexion bilatérale** : `DemandeDeConnexion` (unilatérale, transitoire) → `Connexion` (bilatérale, persistante) — cette dernière ouvre l'accès aux données *protected* de l'autre.
|
||||
|
||||
Festipod **place chaque entité dans le store de son scope** ; l'isolation entre scopes est **assurée par le SDK de données**, pas par du code applicatif (cf. concept `app-security`).
|
||||
|
||||
## Découverte des événements
|
||||
|
||||
Un utilisateur découvre les événements qu'il n'a pas créés via un **index global** : le SDK lit cet index, qui donne les références (NURIs) des documents-événements, puis synchronise et interroge en local. La découverte **primaire** passe par cet index ; un **axe secondaire** relationnel s'y superpose (les participations *protected* des connexions : « mes amis participent à… »).
|
||||
|
||||
> **Notification d'inscription (intention produit).** S'inscrire à un PdR notifie son hôte : identifié si l'inscrit fait partie des connexions de l'hôte, **anonyme sinon**. Ce « identifié si connu, anonyme sinon » est une propriété du modèle de données — l'app y compte, le mécanisme est fourni par le SDK.
|
||||
|
||||
## Questions ouvertes (métier)
|
||||
|
||||
- **Modèle d'écriture de l'événement** : propriétaire (déclarant seul) / wiki (tous) / immuable ? Central pour la déduplication ([[brief_2026-06-15_event-deduplication]]).
|
||||
- **Identité de l'hôte vis-à-vis d'un lambda** : un PdR est lisible par tous, mais faut-il que son hôte soit identifiable ? (pseudonyme par défaut, carte de visite par PdR, ou anonymat révélé aux seules connexions.)
|
||||
- **Champs modifiables d'une inscription** ; **découvrabilité « amis d'amis »**.
|
||||
|
||||
> La matrice d'autorisations détaillée par acteur × verbe vit dans le concept `app-security` ([[brief_2026-05-18_authorization-matrix]]).
|
||||
@@ -15,11 +15,11 @@ summary: Ce qui est implémenté aujourd'hui (cycle événement + point de renco
|
||||
- Profil utilisateur, mise à jour, partage de profil
|
||||
- Liste d'amis (connexions), profil d'un autre utilisateur
|
||||
|
||||
> MAJ T02.b/c (2026-07-03) : l'inscription/désinscription au PdR est **réellement branchée** côté données. `joinEvent` **persiste une Participation** + **dépose dans l'inbox de l'hôte** + **crée une Notification** (shape SHEX réelle) ; `leaveEvent` **supprime autoritativement** via `SPARQL DELETE-WHERE` (le bug CRDT de désinscription est résolu). Ce ne sont plus des no-ops. La **découverte publique cross-compte** fonctionne aussi (fan-out, T02.e — un utilisateur voit un événement public d'un autre sans connexion). Détail lib : [[decision_2026-06-17_eventually-library]] §Inbox émulée.
|
||||
> L'inscription/désinscription au point de rencontre est **réellement branchée** côté données : `joinEvent` persiste une Participation, notifie l'hôte du PdR et crée une Notification ; `leaveEvent` supprime la Participation de façon autoritative (cf. concept `data-layer`, [[caveat_participation-deletion]] côté data-layer). La découverte publique — un utilisateur voit un événement public d'un autre — fonctionne aussi.
|
||||
|
||||
## Évolutions identifiées (non implémentées)
|
||||
|
||||
- **Abonnement à une communauté d'intérêt** pour découvrir ses événements (discovery distribué).
|
||||
- **Abonnement à un utilisateur** pour suivre ses déclarations sans être ami.
|
||||
- **Listes curated** — créer/partager des sélections éditorialisées.
|
||||
- **Multi-utilisateurs collaboratif** : aujourd'hui chaque utilisateur a ses données isolées dans son wallet. Le passage collaboratif (un point de rencontre vu par plusieurs) suppose un refactor de la couche données — voir [[brief_2026-05-17_multi-store-refactor]].
|
||||
- **Multi-utilisateurs collaboratif** : le partage effectif d'un point de rencontre vu par plusieurs utilisateurs, appuyé sur les périmètres public/protected/private (cf. [[knowledge_data-scopes-and-discovery]]).
|
||||
|
||||
Reference in New Issue
Block a user