context

Context (supa-media/context) est une passerelle MCP qui offre aux clients IA — ChatGPT, Claude, Codex, Notion AI et d'autres — un point d'accès unique via lequel ils peuvent lire et écrire dans une base de connaissances personnelle. La base de connaissances est constituée de fichiers Markdown simples stockés dans un compte contrôlé par l'utilisateur : Dropbox, Cloudflare R2, AWS S3, Backblaze B2 ou tout stockage compatible S3. Le README décrit trois unités liées : un **brain** (contexte personnel adressé par votre nom), un **workspace** (contexte partagé avec d'autres) et le **context** comme l'union de votre brain, des brains partagés avec vous et de vos workspaces. La connexion d'un seul point d'accès est destinée à éviter que chaque nouvel assistant n'ait à réapprendre vos projets, vos décisions et votre historique. ## Deux plans La conception sépare un plan de contrôle d'un plan de données, et le README traite cette scission comme le cœur du projet. - **Plan de contrôle** (`apps/convex`) — comptes, workspaces, autorisations OAuth et liaisons de stockage. Il est précisé qu'il ne contient que des métadonnées : pas de notes, pas de seconde copie. - **Plan de données** — le dossier Dropbox de l'utilisateur ou le bucket de stockage d'objets. La suppression du compte Context efface le plan de contrôle tandis que le plan de données reste intact. La passerelle MCP (`apps/mcp`) est décrite comme un Cloudflare Worker autonome que l'utilisateur peut déployer si le service hébergé disparaît, le bucket continuant de fonctionner. ## Revendications de stockage et de portabilité - Les fichiers simples sont canoniques : Markdown lisible dans Obsidian, greppable ou supprimable avec `rclone` ; aucune base de données propriétaire comme seule copie. - Le stockage conserve sa forme native — un dossier ordinaire dans Dropbox, une tenancy au niveau du bucket dans le stockage d'objets, sans réécriture de clés ni namespacing de chemins. Il est indiqué qu'un brain existant peut être connecté sans migration. - Les index (caches de recherche, embeddings) sont décrits comme des dérivés jetables pouvant être reconstruits à partir des fichiers. ## Outils et conventions **`orient`** est le premier outil que les clients connectés sont invités à appeler. Il renvoie la page d'accueil, les notes récemment modifiées et une carte des dossiers avec le nombre de notes. La majeure partie de sa sortie est dérivée du bucket et reconstruite à chaque appel. Le README note que cette instruction réside dans la connexion plutôt que dans le client, c'est pourquoi une instruction personnalisée côté client, un prompt système ou un fichier de règles est suggéré pour la rendre persistante. **`index.md`** est un fichier Markdown ordinaire à la racine du bucket, appartenant à l'utilisateur. La configuration écrit une version initiale ; les agents sont invités à y ajouter du contenu plutôt qu'à le remplacer et à énoncer les changements au préalable. Un fichier `index-private.md` optionnel peut être placé à côté pour le contenu destiné uniquement à une connexion personnelle. La connexion d'un bucket contenant déjà des notes n'écrase rien, donc un brain importé peut ne pas avoir d' `index.md` et `orient` le signalera. **`save_context`** est un outil appelé par l'agent à la fin de la session. Son comportement est défini par l'utilisateur via une section `## Save context` dans `index.md` avec une ligne `destination:` et toute procédure que l'utilisateur souhaite suivre. **Hook de fin de session** — `npx -y @supa-media/context-hook install` permet de se connecter une fois et d'ajouter un hook `SessionEnd` à Claude Code afin que les messages visibles par l'utilisateur d'une session atterrissent automatiquement dans `0-inbox/`. Le README précise qu'il demande uniquement l'accès à la capture, ne peut pas lire les notes, apparaît dans les Connexions et peut être révoqué séparément. Le code source se trouve dans `packages/hook`. ## Organisation La configuration met en place une structure de style PARA — `0-inbox/`, `1-projects/`, `2-areas/`, `3-resources/`, `4-archive/` — présentée comme une suggestion plutôt que comme un schéma. Les outils opèrent sur des chemins, donc une structure fournie par l'utilisateur fonctionnerait de la même manière. ## Confidentialité Chaque note est `private` ou `team`. Les valeurs par défaut des dossiers sont déclarées dans un manifeste `privacy.md` à la racine du bucket, visible par le propriétaire et appliqué côté serveur avant que le contenu ne soit renvoyé, avec la possibilité pour les notes individuelles de passer outre leur dossier dans un sens ou dans l'autre. `team` est défini comme des personnes nommées, jamais l'internet public ; il n'y a pas de niveau anonyme. ## Disposition du dépôt | Chemin | Objectif | | --- | --- | | `apps/convex/` | Plan de contrôle — comptes, workspaces, liaisons de stockage, autorisations | | `apps/mobile/` | App Expo (iOS, Android, web) — onboarding et tableau de bord | | `apps/mcp/` | Worker passerelle MCP — outils, moteur de confidentialité, adaptateur de stockage | | `packages/shared/` | Types et constantes partagés entre les applications | | `packages/hook/` | Le hook de fin de session installable via `npx` | ## Développement ```sh pnpm install npx convex dev # crée votre déploiement Convex pnpm dev # Convex + Expo ensemble cd apps/mcp && pnpm test # Le README cite 442 vérifications, sans dépendances, sans réseau ``` Le projet est indiqué comme étant construit sur supa-framework.