Tsecret

Présentation

Tsecret — Envoie un secret. Il s'affiche une fois, puis disparaît.

Tsecret crée un lien chiffré pour partager un mot de passe, une clé API, un .env ou un message sensible. Tu colles ton texte, tu obtiens un lien : à la première ouverture le secret s'affiche puis s'autodétruit, et le lien devient définitivement mort. Le chiffrement se fait dans ton navigateur (AES-256) et la clé de déchiffrement vit dans le lien lui-même — jamais sur nos serveurs. On ne voit jamais ce que tu envoies. Zéro compte, gratuit, open source.

Le problème

Tu dois envoyer un mot de passe, une clé API ou un accès à quelqu'un. Tu le colles dans Slack, WhatsApp ou un mail — et il reste là pour toujours : dans l'historique, les backups, les notifications, le presse-papier. N'importe qui qui accède à la conversation (aujourd'hui ou dans deux ans) le récupère en clair. Il n'existe pas de moyen simple, sans compte et sans installer quoi que ce soit, d'envoyer un secret qui disparaît juste après avoir été lu.

Fonctionnalités

• Création en un écran : colle ton secret (mot de passe, clé API, .env, message), choisis une durée de vie, clique 'Générer le lien'. Chiffrement AES-256 dans le navigateur (Web Crypto API) — le serveur ne reçoit QUE le texte chiffré, jamais le contenu en clair (zero-knowledge)
• Clé de déchiffrement dans le fragment de l'URL (#) — techniquement jamais envoyée au serveur ni écrite dans les logs. Tout ce qu'il faut pour déchiffrer est dans le lien, et le déchiffrement se fait uniquement chez le destinataire
• Lecture unique auto-destructive : à la première ouverture le secret s'affiche, puis il est détruit côté serveur de façon atomique. Le lien devient définitivement mort — rouvrir affiche 'Ce secret a déjà été lu ou a expiré'
• Écran de révélation à clic (anti-preview) : le destinataire voit d'abord 'Un secret t'a été envoyé — Révéler', et le secret n'est consommé qu'au clic. Ça évite que les robots d'aperçu de lien (Slack, iMessage, WhatsApp, Discord) brûlent le secret avant que la personne l'ouvre
• Expiration automatique : même jamais lu, un secret expire selon la durée choisie (1h / 24h / 7j) puis est purgé de la base. Rien ne traîne indéfiniment
• Options de protection : passphrase optionnelle en plus de la clé du lien (le destinataire doit la connaître pour déchiffrer), pour les cas où l'on envoie le lien et la passphrase par deux canaux différents
• Partage en un clic : bouton 'Copier le lien', QR code du lien pour passer d'un appareil à l'autre, et un compte à rebours clair de l'expiration. Feedback visuel à chaque action
• Zéro compte, zéro friction : pas d'inscription, pas d'email, pas de mot de passe de compte. Tu arrives, tu crées un secret, tu partages le lien. Mobile-first
• Confiance & transparence : page 'Comment ça marche / notre modèle de sécurité' expliquée simplement, code 100% open source pour vérifier le chiffrement, bouton BuyMeACoffee. États vides / erreurs / responsive gérés

Pour qui

Devs, sysadmins, freelances tech, petites équipes produit et toute personne qui doit transmettre une info sensible (mot de passe, clé, token, code, accès client). Les devs en priorité — ils partagent des secrets tous les jours et détestent les laisser traîner dans un chat. Public sensible à la privacy et qui aime l'open source pour pouvoir vérifier le chiffrement.

Stack

Laravel + Livewire, Alpine.js et Tailwind CSS. Laravel + Livewire pour la coquille, les pages et la landing. Le COEUR crypto est côté navigateur en JavaScript (Web Crypto API), pas côté serveur — c'est ce qui garantit le zero-knowledge. FLUX : (1) à la création, le navigateur génère une clé aléatoire AES-256-GCM + un IV, chiffre le secret localement, et n'envoie au serveur QUE le blob chiffré (base64) + les métadonnées (durée de vie, hash optionnel de passphrase, nb de vues=1). Le serveur renvoie un id. Le front construit le lien : https://tsecret.app/s/{id}#{clé}. La clé est dans le FRAGMENT (#) : les navigateurs ne l'envoient jamais au serveur, donc elle n'est ni transmise ni loggée. (2) à la lecture, le destinataire ouvre le lien → écran 'Révéler' (gate anti-preview pour ne pas que les bots d'unfurl consomment le secret) → au clic, le front demande le blob au serveur ; le serveur le renvoie ET le supprime atomiquement (une seule fois, transaction/lock pour éviter la double-lecture en concurrence) ; le front lit la clé dans le fragment, déchiffre localement et affiche. Si passphrase, on la demande avant de déchiffrer. (3) un job planifié purge les secrets expirés (TTL) même jamais lus. BDD (SQLite self-host / MySQL hébergé) : table secrets (id public non devinable type ULID/random, ciphertext, iv, passphrase_hash nullable, expires_at, views_left, created_at) — AUCUNE donnée en clair, aucune IP, aucun email stocké. Rien à voler côté serveur : que du chiffré illisible sans la clé du lien. Le MÊME codebase tourne hébergé ou self-hosted (tout par variables d'env), repo public dès le lancement. Zéro coût d'API externe. Déploiement Forge.