विषय पर बढ़ें

mintbot files को कैसे संभालता है

जब आप अपने mintbot agent को कोई photo, document, voice note, spreadsheet, screenshot या PDF भेजते हैं — Telegram, web panel, या API के ज़रिए — तो वह file language model तक पहुँचते-पहुँचते mintbot के central infrastructure से गुज़रती नहीं। वह सीधे आपके अपने agent के VPS पर उतरती है, जब तक आप चाहें वहीं रहती है, और LLM को वहीं से एक optimised copy मिलती है।

यह एक चुपचाप लिया गया design decision है, पर इसके नतीजे ज़ोरदार हैं। इसे खोल कर समझाने लायक है, क्योंकि यह उन सबसे बड़ी जगहों में से एक है जहाँ mintbot consumer LLM chat से अलग रास्ता पकड़ता है।

पूरा flow, सिरे से सिरे तक

  1. Upload agent VPS पर पहुँचती है। Telegram से एक photo, web panel में drag किया गया PDF, voice memo, chat में paste की गई screenshot। Agent का local API bytes स्वीकार करता है, magic header सूँघ कर पता लगाता है कि असल में यह कौन-सी file है (फ़ोन और browser आश्चर्यजनक बार ग़लत label लगाते हैं), उसे SHA-256 से hash करता है, और agent के अपने VPS पर /var/lib/mintbot-agent/uploads/<shard>/<sha256>.<ext> में लिख देता है। एक local catalog में source (telegram / panel / api), uploader ID, MIME type, और original filename के साथ एक row जुड़ जाती है।

  2. Original पवित्र है। इस पल के बाद mintbot के भीतर कोई भी चीज़ saved file को बदलती नहीं। जो adapters उसे LLM के लिए तैयार करते हैं वे केवल working copies निकालते हैं — resize किए हुए JPEGs, transcode की हुई text, निकाले गए thumbnails। Byte-for-byte original disk पर तब तक रहता है जब तक आप उसे agent के file manager से ख़ुद हटा न दें। कोई central bucket नहीं, कोई retention timer नहीं, agents के बीच कोई leakage नहीं: हर agent VPS को सिर्फ़ अपने मालिक की uploads पता हैं।

  3. मॉडल को LLM-optimised version मिलता है। जब agent तय करता है कि file को LLM को दिखाना है, तो एक छोटा dispatcher MIME type और extension के हिसाब से सही adapter चुनता है, और adapter ऐसी content blocks निकालता है जो मॉडल पढ़ सके:

    Adapter संभालता है Output
    Image JPG, PNG, WebP, GIF, HEIC (iPhone), AVIF, और बाक़ी सब जो Pillow खोल सके 1568 px long edge तक resize, JPEG q85 में re-encode, मॉडल context में base64 inline
    PDF .pdf ≤ 32 MB Native PDF के रूप में base64 inline (Anthropic मॉडल इसे सीधा पढ़ते हैं)
    Text .md, .csv, .json, .yaml, source code (.py, .js, .ts, .go, .rs, …), logs, diffs UTF-8 में decode (latin-1 fallback), size cap तक text के रूप में inline
    Audio .mp3, .ogg, .opus, .m4a, .wav, .flac Telegram voice notes को bot पहले से inline transcribe कर देता है; direct uploads को फ़िलहाल placeholder मिलता है, Whisper STT अगली wave में आएगा
    Video .mp4, .mov, .webm, .mkv फ़िलहाल placeholder; ffmpeg keyframe + audio transcript निकालना अगली wave में आएगा
    Office docs .docx, .xlsx, .pptx, .odt, .ods, .odp फ़िलहाल placeholder; native text extraction (python-docx / openpyxl / python-pptx) अगली wave में आएगा
    Unknown और सब कुछ Text placeholder: "user ने <mime> file attach की है, यह disk पर upload ID <id> के साथ सुरक्षित है" — ताकि मॉडल कम-से-कम इस बारे में सोच सके कि भेजा क्या गया था

    हर transformation original के बगल में <sha256>.cache/v<N>.json के रूप में cache हो जाती है, इसलिए दूसरी बार जब मॉडल को वही file चाहिए तो load instant होती है। Adapter की version bump करने पर cache अपने आप invalidate हो जाती है।

  4. मॉडल context में expire होने वाले URLs नहीं जाते। जब कोई image या PDF LLM को जाता है, तो उसी turn में base64 inline कर दिया जाता है — कोई ऐसा URL नहीं जो बाद में 404 हो जाए, कोई timer वाला signed link नहीं। बड़ी files के लिए, जहाँ मॉडल को सिर्फ़ pointer चाहिए, URL एक internal https://agent<id>.<domain>/<panel_token>/api/local/uploads/<upload_id>/raw होता है — आपके अपने agent के panel token से सुरक्षित, और जब तक file disk पर है तब तक valid।

क्यों यह consumer LLM chat experience से बेहतर है

जब आप ChatGPT में photo या Claude.ai में PDF upload करते हैं, तो file provider के storage में जाती है, उस conversation से जुड़ती है, और कब ग़ायब हो यह provider की retention policy तय करती है। एक तय उम्र के बाद file ख़त्म, भले ही आपको वह conversation अभी भी दिखे जिसमें वह थी। एक provider से दूसरे पर switch करने का मतलब है शुरुआत से शुरू।

एक आम Telegram-bot वाला झंझट इस फ़र्क़ को बहुत साफ़ कर देता है। Telegram ख़ुद हर photo के लिए एक स्थायी file_id रखता है, पर third-party bots जो Telegram file_id से file माँगते हैं उन्हें एक अस्थायी URL मिलता है जो 24 घंटे में expire हो जाता है। पुराने bots कल वाली photo पर 404 परोसते हैं। mintbot इसे एक ही बार में हल कर देता है: जब वह पहली बार कोई Telegram file देखता है, तो स्थायी रूप से valid file_id के ज़रिए bytes दोबारा खींच लाता है और आपके agent के archive में कॉपी कर देता है। उस पल से वह photo आपकी है।

इस design से तीन बातें निकलती हैं:

  • Files आपकी हैं, LLM provider की नहीं। अगले महीने Claude से GPT-5 पर switch करिए — आपका file history बिना छुए साथ चलता है, क्योंकि वह आपके VPS पर है, किसी vendor की bucket में नहीं।
  • आप बाद में दोबारा पूछ सकते हैं। "तीन महीने पहले आपने मेरे लिए एक contract analyse किया था — क्या आप उसे इस नए draft से compare कर सकते हो?" काम करता है, क्योंकि original अभी भी disk पर है। Consumer chat में पुरानी file आम तौर पर जा चुकी होती है।
  • मॉडल को हमेशा वही version मिलता है जिसे वह सबसे अच्छा use कर सकता है। Vision मॉडल को resize किया हुआ JPEG, text readers को UTF-8, PDF readers को native PDF। फ़ोन HEIC upload कर सकते हैं और बात बन जाती है — Pillow का HEIF plugin startup पर load होता है, और magic-byte sniffer उन फ़ोनों को पकड़ लेता है जो upload को application/octet-stream बताकर ग़लत label कर देते हैं।

अपनी files कहाँ manage करें

Agent web panel के topbar में एक file manager है। वह पूरे agent VPS को browse करता है, और upload archive /var/lib/mintbot-agent/uploads/ वह हिस्सा है जिसे आपकी बातचीत भरती जाती हैं। वहाँ से आप कर सकते हैं:

  • Upload की हुई files को rename, delete, या move
  • तारीख़, source, या filename से browse
  • नई uploads drag-drop (chunked, कई gigabyte की files भी)
  • छोटी text files को inline edit

Panel से file delete करने पर blob और catalog row दोनों हट जाते हैं। Agent उसे LLM को अब नहीं दिखा पाएगा। यही वह बात है जो original को "आपका" बनाती है: delete करने का अधिकार सिर्फ़ आपके पास है।

निचोड़

ज़्यादातर LLM chat products आपकी uploads को अस्थायी conversation context की तरह बरतते हैं। mintbot उन्हें आपका data मानता है — आपके VPS पर store, आपकी मिल्क़ियत, और माँगने पर उस आकार में बदल कर दिया जाता है जिसे मॉडल उस turn में सबसे अच्छा use कर सके। mintbot की ज़्यादा दिलचस्प क्षमताओं में से बहुत-सी इसी नींव पर बैठी हैं।