Si vous avez déjà envoyé un lien à usage unique qui est arrivé mort chez votre collègue, c'est probablement la prévisualisation de la messagerie qui a ouvert le lien en premier et qui a cramé le secret accompagnant le lien.

La bonne nouvelle c'est que Oğuzhan Karacabay vient de publier une grosse mise à jour d' OTI , son service open source auto-hébergeable qui génère des liens de partage consultables une seule fois, avec chiffrement dans le navigateur.

Vous collez un mot de passe, une clé d'API ou un bout de config dans OTI, le navigateur chiffre, le serveur lui ne stocke que du charabia, et le destinataire reçoit une jolie URL qui ne fonctionnera bien qu'une fois.

Ce qui change, c'est que le lien ne meurt plus tout seul. En chargeant la page, votre destinataire voit un compte à rebours et un bouton "Decrypt Message", rien d'autre. Du coup, tant que personne ne clique, le message continue son roupillon.

Comme ça, un bot qui déroule les URLs pour fabriquer une jolie vignette repart bredouille. Après si c'est un vrai scanner de sécurité qui charge vraiment la page dans un navigateur automatisé, vous ne pourrez pas éviter le problème.

L'autre nouveauté dans OTI c'est à la création d'un nouveau lien. Le service vous génère en fait 2 liens. Il y a celui que vous envoyez et un second que vous gardez pour vous. Ce dernier vous permettra de consulter l'état du message sans jamais afficher son contenu.

Côté crypto, le contenu est chiffré en AES-256-GCM via WebCrypto, et cette clé AES est elle-même emballée dans une paire RSA-2048 générée dans votre navigateur. La clé privée voyage dans le fragment de l'URL, la partie après le #, que les navigateurs n'envoient jamais au serveur.

Le principe zero-knowledge utilisé par OTI est quasi le même que celui de PrivateBin ou d' Enclosed où la clé ne quitte jamais le navigateur.

Par contre, ça donne des liens obèses puisque le mien faisait 1825 caractères, dont 1728 rien que pour le fragment, et c'est déjà compressé en zlib. Bon courage donc pour le dicter au téléphone ^^ (il y a un QR code, heureusement !)

Le reste, c'est du confort... Fichiers .txt jusqu'à 100 Ko validés dans le navigateur avant chiffrement, mot de passe optionnel par-dessus, expiration au choix entre 5 minutes et 7 jours, limitation de débit via Redis et une tâche planifiée qui balaie les secrets périmés toutes les 30 minutes.

Pour l'héberger, c'est de l'AdonisJS 6 en TypeScript avec Dockerfile, docker-compose et migrations fournis, en licence MIT. Redis peut céder sa place au limiteur en mémoire si vous montez juste un petit truc perso.

Notez quand même que pour le moment, le projet n'a pas été audité et est maintenu par un gars tout seul, donc évitez de l'utiliser pour des secrets d'État.

La démo est en ligne si vous voulez essayer avant d'installer.

Hammer, l'outil dont je vais vous parler aujourd'hui, est né d'un manuscrit perdu. En septembre 2020, son développeur Adam Brown vivait dans un van et écrivait dans des coins souvent très isolés, avec un logiciel gratuit qui se présentait comme fonctionnant hors ligne. Mais malheureusement, au bout d'une semaine sans réseau, le soft a cessé de fonctionner.

De retour en ville quelques jours plus tard, il a alors remis la main sur une connexion, et le logiciel est reparti, mais son manuscrit avait disparu !

Alors, dégoûté, il s'est dit qu'il allait coder son propre éditeur offline pour éviter que ça se reproduise, car hé, on n'est jamais aussi bien servi que par soi-même ! Et c'est pourquoi quand vous écrivez avec Hammer , chaque scène est un fichier texte enregistré sur votre disque dans le répertoire que vous avez spécifiquement choisi. Et c'est pareil pour tout ce qui est contenu annexe comme les notes et les fiches d'encyclopédie qui accompagnent les scènes.

Grâce à Hammer, qui est un logiciel gratuit sous licence MIT, vos idées sont rassemblées sous la forme d'un projet d'écriture avec tout ce qu'il faut pour prendre des notes, mettre des tags, faire des liens...etc.

L'éditeur de Hammer, avec la scène, son plan et ses notes sur le même écran.

Pour autant ce n'est pas un bloc-notes déguisé. Les scènes se réordonnent au glisser-déposer, ce qui est pratique quand vous décidez que deux personnages doivent se croiser trois chapitres plus tôt. L'encyclopédie catalogue les personnages, les lieux et les événements avec leurs images, et Hammer lit vos scènes pour repérer tout seul qui apparaît où.

La synchronisation entre vos appareils, elle, est totalement optionnelle. Et depuis la dernière version, le serveur de sync a une image Docker officielle . Un petit docker compose up -d et c'est en route, avec un volume pour vos données et le PostgreSQL embarqué directement dans le conteneur.

Si vous débutez en auto-hébergement , sachez quand même que le serveur ne parle que HTTP en local alors que les clients Hammer exigent du HTTPS, donc il faudra mettre en place un reverse proxy ou un certificat devant.

Et si vous n'avez pas envie de gérer un serveur, sachez que l'instance officielle hammer.ink est utilisable si vous êtes abonné au Patreon du projet. Vous pouvez aussi vous en passer et poser le dossier dans Syncthing ou Dropbox, mais ça ne marchera qu'entre vos ordinateurs, car les clients mobiles (Android / iOS) Hammer supportent uniquement le protocole intégré.

Bref, un super outil pour les écrivains, les journalistes et autres producteurs de contenu qui aiment bosser offline. Et si Hammer s'arrête de fonctionner un jour, votre roman sera encore avec vous.

Un import qui affiche "terminé" et qui a mangé une partie de vos mails au passage, c'est le genre de bug qu'on ne voit jamais venir... Hé bien Open Archiver vient d'en corriger quatre d'un coup.

Open Archiver c'est une plateforme d'archivage d'emails auto-hébergée développée par Weishest, dont la seule et unique mission est d'aspirer vos boîtes et de les stocker en .eml sur votre serveur.

Mais attention, le mot "archivage" a son importance, parce que ce n'est pas un backup. Je m'explique... l'idée c'est de garder un dépôt consultable et inaltérable de tout ce qui est passé par vos boîtes, ce qui intéresse surtout les structures ou les personnes comme moi qui doivent pouvoir retrouver un échange trois ans plus tard parce qu'on leur demande tout un tas de trucs tout le temps ^^.

Côté sources, il avale de l'IMAP, du Google Workspace, du Microsoft 365, des fichiers PST, des .eml zippés et du mbox. Ensuite, vos mails archivés finissent chez vous, sur votre disque ou dans un bucket S3, chacun accompagné de son empreinte SHA256 pour repérer une altération.

La grosse news de cette nouvelle release, c'est la recherche avancée. En effet, un panneau de filtres est apparu à côté du champ de mots-clés. Vous restreignez à une source d'ingestion, à une boîte précise, à une fenêtre de dates, aux mails qui ont une pièce jointe ou à ceux qui n'en ont pas et expéditeurs et destinataires s'excluent autant qu'ils s'incluent.

Le panneau de filtres de la recherche avancée, ajouté en v0.5.2

Le mot-clé, lui, peut viser une partie précise du message. Chercher "facture" dans les noms de pièces jointes ne remonte plus tous les mails qui prononcent le mot, juste ceux qui transportent un fichier facture.pdf. Et comme la recherche entière vit dans l'URL, une requête se met en favori et se rejoue à l'identique. L'API suit, avec un GET /v1/search qui accepte les mêmes paramètres que l'interface.

Attention quand même si vous faites la MAJ, faudra relancer un reindex . Et comme les mails existants sont marqués "déjà indexés" à la montée de version, c'est une reconstruction complète qu'il vous faut, pas le simple rattrapage des trous.

Puis surtout, ces notes de version annoncent que plusieurs correctifs "ferment des chemins où un import pouvait sauter ou dupliquer des messages tout en signalant un succès". Le cas le plus vicieux vient d'un composant qui découpe le fichier en messages et qui rendait la main trop tôt. Node recollait alors les morceaux et plusieurs mails arrivaient soudés et finissaient archivés comme un seul. Les imports PST, eux, fabriquaient des messages malformés que les lecteurs affichaient de travers, et une simple re-synchronisation ré-archivait le fichier entier en doublons.

Le plus spectaculaire reste quand même le nom de pièce jointe trop long. Au-delà de 255 octets, l'écriture sur le disque échouait et emportait l'email complet avec elle. Bref, beaucoup de soucis quoi...

Donc si vous tournez déjà dessus, la question à se poser, c'est de savoir si votre archive est déjà foireuse ou pas car un reindex ne la réparera pas. Comme il reconstruit l'index de recherche à partir de ce qui est sur le disque, un message jamais écrit ne réapparaîtra pas. Mais bon, voilà, le découpeur de mbox journalise maintenant son nombre de messages, ce qui rend l'écart visible entre le fichier source et l'archive. Pour le reste, il faudra réimporter ce qui manque

Pour le faire fonctionner, comptez 4 Go de RAM, ou 2 Go si vous branchez PostgreSQL, Valkey et Meilisearch en externe. Le cœur est en AGPL, ça se lance avec un docker compose up, et une démo publique tourne en ligne si vous voulez tâter le truc avant. Pour ma part, je pense que c'est intéressant en entreprise, mais clairement, une usine à gaz, si vous avez juste un compte Gmail à archiver. A la place, je vous avais déjà montré Eonvelope et Bichon , qui sont deux archiveurs autrement plus légers !

Et si c'est pour faire de la recherche, ce que je vous conseille, c'est de faire comme moi, c'est-à-dire un RAG qui indexe tous vos emails en local et qui vous permet de chercher dedans facilement avec n'importe quel LLM qui supporte les outils MCP. Moi je fais ça avec LEANN et ça marche très bien .

Open Archiver est à découvrir ici !

Si vous avez un Navidrome qui tourne dans un coin et un serveur Ollama qui passe ses journées à ne rien faire, vous ne vous êtes jamais dit que les deux pourraient bosser ensemble ? C'est en tout cas ce qu'a flairé Parminder Klair qui a branché l'un sur l'autre et en a sorti une vraie station de radio, avec un DJ qui parle entre les morceaux.

Son DJ baptisé Subwave ne fait pas de la lecture aléatoire. À chaque tour, le modèle utilise des outils qui lui permettent de fouiller la bibliothèque, regarder ce qui vient de passer, consulter la grille des programmes, lire la météo. Il choisit le titre suivant avec une raison, écrit une intro courte, la synthèse vocale la lit, et Liquidsoap baisse la musique sous la voix.