Hvordan mintbot håndterer filer¶
Når du sender et foto, dokument, voice-memo, regneark, screenshot eller en PDF til din mintbot-agent — via Telegram, web-panelet eller API'et — så passerer filen ikke mintbots centrale infrastruktur på vej til sprogmodellen. Den lander direkte på din agents egen VPS, bliver dér så længe du vil, og LLM'en får en kopi, der er optimeret til den.
Det er et stille designvalg med højlydte konsekvenser. Det er værd at få stavet ud, for det er et af de større steder, hvor mintbot adskiller sig fra forbruger-LLM-chat.
Flowet fra ende til ende¶
-
Uploadet ankommer til agentens VPS. Et foto fra Telegram, en PDF trukket ind i web-panelet, et voice-memo, et screenshot indsat i chatten. Agentens lokale API tager imod byten, snuser til magic-headeren for at regne ud, hvad filen i virkeligheden er (telefoner og browsere mærker dem overraskende ofte forkert), hasher den med SHA-256 og skriver den til
/var/lib/mintbot-agent/uploads/<shard>/<sha256>.<ext>på din egen agents VPS. En række ryger ind i et lokalt katalog med kilde (telegram / panel / api), uploader-ID, MIME-type og oprindeligt filnavn. -
Originalen er hellig. Fra dette punkt rører intet inden i mintbot nogensinde den gemte fil igen. Adaptere, der gør den klar til LLM'en, udsender kun arbejdskopier — nedskalerede JPEG'er, omkodet tekst, udtrukne thumbnails. Byte-for-byte-originalen ligger på disken, indtil du sletter den via agentens filhåndtering. Der er ingen central bucket, ingen retention-timer, ingen lækage mellem agenter: hver agent-VPS kender kun sin egen ejers uploads.
-
Modellen får en LLM-optimeret version. Når agenten beslutter at vise filen til LLM'en, vælger en lille dispatcher den rette adapter ud fra MIME-type og filendelse, og adapteren udsender indholdsblokke, modellen kan læse:
Adapter Håndterer Output Image JPG, PNG, WebP, GIF, HEIC (iPhone), AVIF og alt andet, Pillow kan åbne Skaleret til 1568 px lang kant, omkodet som JPEG q85, base64-inlined i modelkonteksten PDF .pdf≤ 32 MBBase64-inlined som native PDF (Anthropic-modeller læser den direkte) Text .md,.csv,.json,.yaml, kildekode (.py,.js,.ts,.go,.rs, …), logs, diffsUTF-8-afkodet (latin-1 som fallback), inlined som tekst op til en størrelsesgrænse Audio .mp3,.ogg,.opus,.m4a,.wav,.flacTelegrams voice-memos transskriberes allerede inline af botten; direkte uploads får for nu en pladsholder, og Whisper STT kommer i en senere bølge Video .mp4,.mov,.webm,.mkvPladsholder for nu; ffmpeg-keyframe + lyd-transskript-udtrækning kommer i en senere bølge Office docs .docx,.xlsx,.pptx,.odt,.ods,.odpPladsholder for nu; native tekst-udtrækning (python-docx / openpyxl / python-pptx) kommer i en senere bølge Unknown Alt andet Tekstpladsholder: "brugeren vedhæftede en <mime>-fil, den ligger på disken med upload-ID<id>" — så modellen i det mindste kan ræsonnere om, hvad der blev sendtHver transformation cackes ved siden af originalen som
<sha256>.cache/v<N>.json, så anden gang modellen har brug for den fil, er det en øjeblikkelig load. At hæve adapter-versionen invaliderer cachen automatisk. -
Ingen udløbende URL'er i modelkonteksten. Når et billede eller en PDF går til LLM'en, indlejres det base64-inline i samme tur — ingen URL der kan blive 404 senere, intet signeret link med timer. For større filer, hvor modellen kun behøver en pointer, er URL'en en intern
https://agent<id>.<domain>/<panel_token>/api/local/uploads/<upload_id>/raw— beskyttet af din egen agents panel-token, gyldig så længe filen ligger på disken.
Hvorfor dette slår forbruger-LLM-chat-oplevelsen¶
Når du uploader et foto til ChatGPT eller en PDF til Claude.ai, ryger filen ind i udbyderens lager, knyttes til den samtale, og udbyderens retention-politik bestemmer, hvornår den forsvinder. Forbi en bestemt alder er filen væk, selvom du stadig kan se den samtale, den boede i. At skifte fra én udbyder til en anden betyder at starte forfra.
En klassisk Telegram-bot-fælde gør kontrasten konkret. Telegram selv beholder et permanent file_id for hvert foto, men tredjeparts-bots, der henter et Telegram-file_id, får en midlertidig URL, der udløber efter 24 timer. Ældre bots, der refererer til gårsdagens foto, serverer en 404. Mintbot løser dette én gang for alle: første gang den ser en Telegram-fil, henter den byten igen via det evigt gyldige file_id og kopierer dem ind i din agents arkiv. Fra det øjeblik er fotoet dit.
Tre ting følger af dette design:
- Filerne tilhører dig, ikke LLM-udbyderen. Skifter du fra Claude til GPT-5 næste måned, følger din filhistorik med, urørt, fordi den ligger på din VPS — ikke i en leverandørs bucket.
- Du kan spørge igen senere. "For tre måneder siden analyserede du en kontrakt for mig — kan du sammenligne den med dette nye udkast?" virker, fordi originalen stadig ligger på disken. I forbruger-chatten er den ældre fil typisk væk.
- Modellen får altid den version, den bedst kan bruge. Vision-modeller får den nedskalerede JPEG, tekstlæsere får UTF-8, PDF-læsere får native PDF. Telefoner kan uploade HEIC, og det bare virker — Pillows HEIF-plugin loades ved opstart, og magic-byte-sniffen fanger telefoner, der mærker uploadet forkert som
application/octet-stream.
Hvor du administrerer dine filer¶
Agentens web-panel har en filhåndtering i topbaren. Den browser hele agent-VPS'en, og upload-arkivet under /var/lib/mintbot-agent/uploads/ er den del, som dine samtaler fylder. Derfra kan du:
- Omdøbe, slette eller flytte uploadede filer
- Browse efter dato, kilde eller filnavn
- Drag-and-droppe nye uploads (chunkede, understøtter filer på flere gigabytes)
- Redigere små tekstfiler inline
At slette en fil fra panelet fjerner både selve blobben og katalog-rækken. Agenten kan så ikke længere vise den til LLM'en. Det er det, der gør originalen "din": du er den eneste med sletteret.
Bundlinjen¶
De fleste LLM-chatprodukter behandler dine uploads som flygtig samtalekontekst. Mintbot behandler dem som dine data — gemt på din VPS, ejet af dig, formatkonverteret efter behov til præcis den form, modellen lige nu bedst kan bruge. Mange af mintbots mere interessante evner hviler på dette fundament.