Reprise des commits 91f7f977 (PR #100 de Trombo38) et 1dfac0cf d'AJEAN.
Une vidéo jointe (mp4, webm, mov, mkv, avi) part au modèle en partie
input_video, et l'outil see_video charge une vidéo du disque, mais
seulement si le moteur actif sait la lire : preset llama.cpp local avec
projecteur (MMPROJ) et binaire dont l'aide annonce --video-fps
(videoInputSupported, aide relue quand le binaire change, chemin des
bibliothèques passé à la seule commande pour ne pas figer binHelp).
Strata et les API externes ignoraient la partie en silence : la vidéo
reste alors un fichier, annoncé avec la marche à suivre (ffmpeg puis
see_image), et see_video n'est pas proposé.
llama.cpp a --video-fps depuis la PR #24318 (fin août 2026) ; l'image
server-cuda officielle, base du conteneur, installe ffmpeg. La consigne
de repli dit quoi faire si ffmpeg manque (installation hors conteneur).
Adapté à Loki :
- la vidéo de see_video est toujours éphémère (jamais dans l'historique,
KEEP_TURN_IMAGES compris) ; même ordre de refus que see_image, sonde
/props en dernier, refus sur un poste distant ;
- une vidéo jointe est rangée par référence (loki-vid:, LOKI_HOME/chatvid,
chiffrée comme le fil), parties recopiées et non mutées comme les
images ; retirée d'un fil rouvert (stripImageParts, videoLostMarker) et
effacée par le ménage des médias ;
- marqueur de perte à la compaction, élision dans l'export JSON, relais
par l'API interne des outils (vision_video).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Les deux reprises d'AJEAN arrivées en parallèle du chiffrement écrivaient
en clair à côté de discussions chiffrées.
- Résultats complets des outils (« voir plus ») : bucket toolres ajouté à
encryptedBuckets, écrits et relus par putStoreBytes / getStoreBytesErr.
Mémoire verrouillée : rien n'est écrit, le flux porte le résultat entier.
Le nettoyage des orphelins ne tourne plus quand la mémoire est
verrouillée : l'index des discussions revenait vide et TOUT passait pour
orphelin.
- Images du fil (chatimg/) : même enveloppe que les pages mémoire ;
verrouillée, l'image reste en base64 dans le message. Elles n'étaient
jamais effacées : comme un fil rechargé perd ses images (stripImageParts),
celles de plus de 24 h partent au démarrage et à chaque bascule de
discussion.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Repris d'AJEAN 0.15.7 (chat_images.go et son test), adapté.
Une image jointe (ou une capture de web_screenshot) vivait en base64 dans
les messages de la conversation, et persist() réécrit la conversation
ENTIÈRE à chaque fin de tour : une photo de téléphone, c'étaient des Mo
remis sur disque à chaque réponse. Elle est désormais rangée une fois sous
$LOKI_HOME/chatimg/<empreinte>.<ext> (hors du dossier de travail, que l'IA
peut vider) ; l'historique n'en garde que « loki-img:<nom> ». Juste avant
l'envoi, expandImageRefs remet les octets exacts (cache mémoire borné à
64 Mo) : pour le modèle, rien ne change.
DEUX ÉCARTS AVEC L'AMONT
- Copie à l'écriture : l'amont remplace l'URL en place. Chez nous, persist
peut tourner pendant qu'un runChat sérialise ces mêmes maps (compactage
en vol, bascule de projet) — « concurrent map read and map write », fatal.
Les parties modifiées sont donc recopiées.
- Le rechargement reste éphémère : stripImageParts retire toujours les
images d'une conversation rouverte (garde-fou contre un modèle sans vision
qui lirait le base64 comme du texte). L'amont, lui, les garde ; on
pourra le suivre plus tard si l'on veut.
Pas de migration des archives : une conversation rouverte est allégée par
stripImageParts, comme avant.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
MichaelandClaude Opus 5.5