Pour un projet, je dois mettre en place un système de sauvegarde sécurisé (WORM).
Ici, "sécurisé" signifie :

• qui empêche la suppression accidentelle ou intentionnelle des données ;
• une protection contre les ransomwares.

Pour cela, j'ai décidé de sauvegarder ces données chez deux fournisseurs d'Object Storage :

• Scaleway Object Storage
• Backblaze

Je viens de publier le playground append-only-backup-playground qui m'a permis de tester la configuration de bucket Backblaze et Scaleway.

Object Storage append-only backup playground

In this "playground" repository, I explore different methods to configure object storage services in append-only or write-once-read-many (WORM) mode.

source

J'ai testé deux méthodes qui interdisent la suppression des données :

• 1. La première, basée sur une clé d'accès avec des droits limités : l'interdiction de supprimer des fichiers. Si un attaquant parvient à s'infiltrer sur un serveur qui effectue des sauvegardes, la clé ne lui permettra pas d'effacer les anciennes sauvegardes.
• 2. La seconde méthode plus stricte utilise la fonctionnalité object lock en mode GOVERNANCE ou COMPLIANCE.

Je vous recommande d'être vigilant avec le mode COMPLIANCE, car il vous sera impossible de supprimer les fichiers avant leur date de rétention, sauf si vous décidez de supprimer entièrement votre compte client !

Personnellement, je recommande d'utiliser la méthode 1 pour tous les environnements de développement.
En général, je pense que la méthode 1 est suffisante, même pour les environnements de production. Mais si les données sont vraiment critiques, alors je conseille le mode GOVERNANCE ou COMPLIANCE.

Le repository append-only-backup-playground contient 4 playgrounds :

• Pour tester la méthode 1 :
  • /scaleway/ : configuration d'un bucket Scaleway Object Storage et une clé qui ne peut pas supprimer de fichier. L'option de versionning est activée.
  • /backblaze/ : configuration d'un bucket Backblaze et une clé qui ne peut pas supprimer de fichier. L'option de versionning est activée.
• Pour tester la méthode 2 :
  • /scaleway-object-lock/ : la même chose que /scaleway/ avec en plus la configuration de object lock en mode GOVERNANCE avec une durée de rétention définie à 1 jour.
  • /backblaze-object-lock/ : la même chose que /backblaze/ avec en plus la configuration de object lock en mode GOVERNANCE avec une durée de rétention définie à 1 jour.

J'ai récupéré l'archive de mes posts, je vais sans doute les publiers avec l'un des outils listés dans Awesome Mastodon - Archiving.

source

Voilà, je viens de publier mon archive de mon ancien compte Mastodon : http://archives.sklein.xyz/mamot.fr/.

Pour réaliser cette archive, j'ai utilisé Posty (https://posty.1sland.social/).

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 :

• https://github.com/stephane-klein/sklein-convarchive (pas encore créé)

Ressources :

• Aggregator - Backup Numeric Conversation System — note d'origine du projet
• Une extension browser pour exporter ses threads Claude.ia et ChatGPT — piste d'export browser explorée