Recherche effectué dans :

Filtre actif, cliquez pour en enlever un tag :

Cliquez sur un tag pour affiner votre recherche :

Résultat de la recherche (1 notes) :

Projet 39 - "sklein-convarchive" #storage, #archive, #project, #backup, #chat

Date de la création de cette note : 2026-08-03.

Cette note est une tentative de spécification technique plus approfondie de "Aggregator - Backup Numeric Conversation System". Elle est aussi en lien faible avec la note "Une extension browser pour exporter ses threads Claude.ai et ChatGPT".

Quel est l'objectif de ce projet ?

Projet d'un outil permettant l'archivage centralisé des conversations multi-sources (Mattermost, Signal, OpenCode, Claude.ai, etc.) vers S3.

Trois finalités identifiées :

  • Centraliser des échanges dispersés sur plusieurs plateformes
  • Réutiliser ce corpus à l'avenir pour un pipeline RAG (recherche, indexation, embeddings)
  • Archiver dans un format ouvert et pérenne, pensé pour la postérité

Nom retenu : sklein-convarchive

Décisions techniques (à date)

  • Format de stockage : JSONL (JSON Lines), retenu par défaut plutôt que du JSON englobant.
    • Append-only naturel : chaque nouveau message s'ajoute comme une nouvelle ligne en fin de fichier, sans réécrire les lignes existantes
    • Streamable, lisible en continu même avec un très grand nombre d'entrées
    • Facile à ré-ingérer dans un pipeline RAG (chunking, embeddings) sans dépendance lourde
  • Destination : Object Storage

Périmètre de la première version (MVP)

Pour le moment, je me concentre uniquement sur l'archivage des conversations Mattermost vers Object Storage. Ce service sera codé en Golang.

  • Source : API Mattermost
  • Format : JSONL (comme décrit plus haut)
  • Destination : Object Storage
  • Arborescence : raw/mattermost/<année>/<mois>/<jour>/<date>.jsonl
  • Un fichier JSONL par jour, append-only : les lignes s'ajoutent dans le fichier du jour
  • Append sur S3 : pas d'append natif sur un objet S3. Choisi : bufferiser les lignes du jour et monter l'objet en une fois en fin de lot
  • Architecture du dépôt : mono-repo sklein-convarchive, avec un connecteur par source à l'intérieur
  • Chaque ligne est normalisée vers le schéma commun (voir plus bas)

Arborescence Object Storage (MVP) :

conversations/
  raw/
    mattermost/2026/08/03/2026-08-03.jsonl
  data/                          ← à implémenter plus tard
    mattermost/2026/08/part-001.parquet

Une couche data/ en Parquet, interrogeable par DuckDB, est envisagée plus tard — elle n'est pas traitée dans le MVP. Le JSONL de raw/ reste la source de vérité.

Le reste — Signal, OpenCode, Claude.ai, Mail, l'interface web de consultation, le pipeline RAG — est mis de côté pour l'instant, à envisager dans des versions ultérieures.

Schéma commun

Schéma commun retenu avant ingestion RAG, pour que les sources hétérogènes (Mattermost, Signal, OpenCode, Claude.ai, Mail, etc) convergent vers une structure homogène : un tronc commun et un objet metadata spécifique à la source.

Champ Description
source Plateforme d'origine
timestamp Date et heure du message
author Auteur du message
content Contenu du message
thread_id Identifiant du fil de discussion (thread Mattermost, conversation Claude)
metadata Champs spécifiques à la source (voir exemples ci-dessous)
raw Optionnel, conserve la donnée brute d'origine

Exemples de metadata selon la source :

// Mattermost
{ "team": "dev", "channel": "général", "server_url": "https://chat.example.com" }

// Claude
{ "conversation_url": "https://claude.ai/chat/...", "model": "claude-..." }

// OpenCode
{ "project_path": "/workspace/foo", "session_id": "...", "tool_call": { "name": "...", "arguments": "...", "result": "..." } }

Description proposée (README/PKM)

Archive centralisée au format JSONL des conversations (Mattermost, Signal, OpenCode, Claude.ai, Mail, etc), pensée pour la pérennité et la réutilisation future (RAG, recherche, etc.)

Pourquoi je souhaite réaliser ce projet ?

Ma première motivation est de ne pas perdre l'historique de mes conversations Mattermost, Signal, OpenCode, Claude.ai, Mail, etc. Le format ouvert JSONL et la destination Object Storage garantissent que ces données resteront exploitables et lisibles sur le long terme.

Ma seconde motivation est d'avoir une interface web unique et minimaliste pour lire, parcourir et rechercher l'intégralité de mes conversations, orientée vitesse, en suivant les principes de sklein-utilitarian-ui-skill.

Au-delà de l'archivage, je souhaite utiliser ce corpus centralisé et unifié comme une matière première pour un futur pipeline RAG.

Je suis aussi assez enthousiaste et curieux d'utiliser, dans la prochaine itération, Parquet et DuckDB : deux technologies que je croise régulièrement depuis quelques années mais que je n'ai jamais mises en œuvre.

Repository de ce projet :

Ressources :

Dernière page.