mintbot फ़ाइलों को कैसे संभालता है

जब आप अपने mintbot एजेंट को कोई फ़ोटो, दस्तावेज़, वॉइस मैसेज, स्प्रेडशीट, स्क्रीनशॉट या PDF भेजते हैं — Telegram, वेब पैनल या API के ज़रिए — तो फ़ाइल आपके एजेंट के अपने VPS पर सेव होती है, और कहीं नहीं। वह वहाँ तब तक रहती है जब तक आप चाहें, और LLM को उसके लिए तैयार की गई एक कामकाजी कॉपी मिलती है।

यह एक चुपचाप लिया गया डिज़ाइन फ़ैसला है, लेकिन इसके नतीजे बड़े हैं। इसे खोलकर समझाना ज़रूरी है, क्योंकि यही वह जगह है जहाँ mintbot आम लोगों के लिए बने AI चैट ऐप से सबसे ज़्यादा अलग है।

मूल फ़ाइल आपके VPS पर जस की तस रहती है — मॉडल को हमेशा सिर्फ़ उसके लिए बनी कामकाजी कॉपी दिखती है।

शुरू से आख़िर तक पूरा प्रवाह

1. अपलोड एजेंट के VPS पर पहुँचता है। वेब पैनल में खींचकर डाला गया PDF सीधे आपके VPS पर जाता है। Telegram में भेजी गई फ़ोटो या फ़ाइल को mintbot बॉट Telegram से लेकर तुरंत आपके VPS को सौंप देता है — फ़ाइल सिर्फ़ आगे बढ़ाई जाती है, कभी केंद्रीय रूप से स्टोर नहीं होती। एजेंट का लोकल API फ़ाइल की शुरुआती पहचान-बाइट्स (magic bytes) जाँचकर पता लगाता है कि फ़ाइल असल में किस प्रकार की है (फ़ोन और ब्राउज़र हैरानी की हद तक अक्सर ग़लत लेबल लगाते हैं), उसका SHA-256 हैश निकालता है और उसे /var/lib/mintbot-agent/uploads/<shard>/<sha256>.<ext> में लिखता है। एक लोकल कैटलॉग में स्रोत (telegram / panel / api), अपलोड करने वाले की ID, MIME टाइप और मूल फ़ाइल नाम के साथ एक पंक्ति जुड़ती है। एक ही फ़ाइल दो बार भेजने पर भी वह सिर्फ़ एक बार स्टोर होती है।

   अगर बातचीत किसी प्रोजेक्ट में चल रही है, तो एजेंट उस प्रोजेक्ट के uploads/ फ़ोल्डर में भी एक कॉपी रख देता है, ताकि वह प्रोजेक्ट की बाकी फ़ाइलों के साथ ही उस पर काम कर सके।

2. मूल फ़ाइल अछूती रहती है। इस पल से mintbot के भीतर कुछ भी सेव की गई फ़ाइल को नहीं बदलता। LLM के लिए उसे तैयार करने वाले अडैप्टर सिर्फ़ कामकाजी कॉपियाँ बनाते हैं — छोटे किए गए JPEG, डिकोड किया गया टेक्स्ट। बाइट-दर-बाइट वही मूल फ़ाइल तब तक डिस्क पर रहती है जब तक आप उसे डिलीट न करें। न कोई केंद्रीय स्टोरेज, न रिटेंशन टाइमर, न एक एजेंट से दूसरे में रिसाव: हर एजेंट का VPS सिर्फ़ अपने मालिक की फ़ाइलों के बारे में जानता है।

3. मॉडल को उसके लिए बना संस्करण मिलता है। जब एजेंट फ़ाइल LLM को दिखाता है, तो एक छोटा डिस्पैचर MIME टाइप और एक्सटेंशन के आधार पर सही अडैप्टर चुनता है:

   अडैप्टर	क्या संभालता है	मॉडल को क्या मिलता है
   इमेज	JPG, PNG, WebP, GIF, HEIC (iPhone), AVIF, TIFF, BMP	लंबी साइड 1568 px तक छोटी की जाती है, JPEG q85 में दोबारा एन्कोड होती है और सीधे अनुरोध में जोड़ दी जाती है। डिकोडिंग एक अलग, अल्पकालिक प्रोसेस में होती है जिसकी मेमोरी सीमा आपके VPS के हिसाब से तय होती है, इसलिए बहुत बड़ी फ़ोटो भी एजेंट को धीमा नहीं कर सकती
   PDF	32 MB तक की .pdf	असली PDF के रूप में जोड़ी जाती है — Claude टेक्स्ट और लेआउट सीधे पढ़ता है। इससे बड़ी PDF डिस्क पर रहती है और एजेंट ख़ुद उसका टेक्स्ट निकालता है (जैसे pdftotext से)
   टेक्स्ट	.txt, .md, .csv, .json, .yaml, .svg, सोर्स कोड (.py, .js, .ts, .go, .rs, …), लॉग, diff	UTF-8 के रूप में डिकोड होता है (बैकअप के तौर पर latin-1) और 500 KB तक जोड़ा जाता है; इससे लंबी फ़ाइल वहीं काट दी जाती है, पूरी मूल फ़ाइल डिस्क पर रहती है
   ऑडियो	.mp3, .ogg, .opus, .m4a, .wav, .flac, .aac	Telegram और पैनल के माइक्रोफ़ोन से आए वॉइस मैसेज पहले से टेक्स्ट में बदले हुए आते हैं। ऑडियो फ़ाइल अभी अपने-आप ट्रांसक्राइब नहीं होती — एजेंट को उसकी जगह और निर्देश मिलते हैं, और आपके कहने पर वह उसे ट्रांसक्राइब करता है
   वीडियो	.mp4, .mov, .webm, .mkv, .avi	अभी अपने-आप प्रोसेस नहीं होता। आपके कहने पर एजेंट ffmpeg इंस्टॉल करता है (पहले बताता है कि इसमें कितनी डिस्क जगह लगेगी) और ख़ुद फ़्रेम या ऑडियो ट्रैक निकालता है
   Office दस्तावेज़	.docx, .xlsx, .pptx, पुराने .doc / .xls / .ppt, .odt, .ods, .odp	अभी अपने-आप प्रोसेस नहीं होते। आपके कहने पर एजेंट एक छोटी रीडर लाइब्रेरी इंस्टॉल करके टेक्स्ट निकालता है
   अज्ञात	बाकी सब कुछ	फ़ाइल के नाम, प्रकार, आकार और डिस्क पर उसकी जगह वाला एक नोट, साथ में उसकी शुरुआती बाइट्स hex में — इतना कि मॉडल फ़ाइल पहचान सके और काम की ज़रूरत हो तो अपने टूल से उसे खोल सके

   हर कामकाजी कॉपी मूल फ़ाइल के बगल में <sha256>.cache/v<N>.json के रूप में कैश होती है, ताकि अगली बार मॉडल को वह फ़ाइल चाहिए तो तुरंत लोड हो जाए। कोई अडैप्टर बदलने पर कैश अपने-आप दोबारा बन जाता है।

4. मॉडल के कॉन्टेक्स्ट में एक्सपायर होने वाले URL नहीं। जब कोई इमेज या PDF LLM को जाती है, तो उसे उसी अनुरोध में जोड़ दिया जाता है — ऐसा कोई URL नहीं जो बाद में 404 दे, समय-सीमा वाला कोई साइन किया हुआ लिंक नहीं। जहाँ मॉडल को सिर्फ़ एक संदर्भ चाहिए, वहाँ URL एक आंतरिक पता होता है: https://agent<id>.<domain>/<panel_token>/api/local/uploads/<upload_id>/raw — यह आपके एजेंट के अपने पैनल टोकन से सुरक्षित है और तब तक मान्य है जब तक फ़ाइल डिस्क पर है।

यह आम AI चैट से बेहतर क्यों है

जब आप ChatGPT में फ़ोटो या Claude.ai में PDF अपलोड करते हैं, तो फ़ाइल प्रोवाइडर के स्टोरेज में जाती है, उस बातचीत से जुड़ जाती है, और वह कब ग़ायब होगी यह प्रोवाइडर की रिटेंशन नीति तय करती है। एक समय के बाद फ़ाइल चली जाती है, भले ही जिस बातचीत में वह थी, वह आपको अब भी दिख रही हो। प्रोवाइडर बदलने का मतलब है शून्य से शुरुआत।

Telegram बॉट्स की एक आम गड़बड़ी इस फ़र्क़ को साफ़ दिखाती है। Telegram हर फ़ोटो के लिए एक स्थायी file_id रखता है, लेकिन बॉट को उसके लिए जो डाउनलोड लिंक मिलता है, उसके चलने की गारंटी सिर्फ़ लगभग एक घंटे की होती है। जो बॉट सिर्फ़ यह लिंक सहेजते हैं, वे कल की फ़ोटो पर 404 देते हैं। mintbot फ़ाइल आते ही उसे आपके एजेंट के आर्काइव में कॉपी कर लेता है — और अगर आप किसी पुरानी फ़ोटो का जवाब देते हैं, तो वह स्थायी file_id से उसे दोबारा ले आता है। उसके बाद से फ़ोटो आपकी है।

इस डिज़ाइन से तीन बातें निकलती हैं:

• फ़ाइलें आपकी हैं, LLM प्रोवाइडर की नहीं। अगले महीने Claude से GPT पर जाएँ, तो आपका फ़ाइल इतिहास बिना किसी बदलाव के साथ चलता है, क्योंकि वह आपके VPS पर है — किसी वेंडर के स्टोरेज में नहीं।
• आप बाद में फिर से पूछ सकते हैं। “तीन महीने पहले तुमने मेरे लिए एक अनुबंध का विश्लेषण किया था — क्या उसे इस नए ड्राफ़्ट से मिलाकर देख सकते हो?” जैसा सवाल काम करता है, क्योंकि मूल फ़ाइल अब भी डिस्क पर है। आम चैट में पुरानी फ़ाइल आम तौर पर कब की जा चुकी होती है।
• मॉडल को हमेशा वही संस्करण मिलता है जिसका वह सबसे अच्छा इस्तेमाल कर सके। इमेज समझने वाले मॉडलों को छोटा किया गया JPEG, टेक्स्ट पढ़ने वालों को UTF-8, और PDF पढ़ने वालों को असली PDF मिलता है। फ़ोन से HEIC अपलोड करें, तो वह बस चल जाता है — इमेज डिकोडर Pillow का HEIF प्लगइन लोड करता है, और पहचान-बाइट्स की जाँच उन फ़ोनों को पकड़ लेती है जो अपलोड पर ग़लती से application/octet-stream का लेबल लगा देते हैं।

अपनी फ़ाइलें कहाँ संभालें

एजेंट के वेब पैनल में सेटिंग्स → फ़ाइल प्रबंधक के अंदर एक फ़ाइल प्रबंधक है। इससे पूरा एजेंट VPS ब्राउज़ किया जा सकता है; /var/lib/mintbot-agent/uploads/ में मौजूद अपलोड आर्काइव वह हिस्सा है जिसे आपकी बातचीत भरती है। वहाँ से आप:

• फ़ोल्डर ब्राउज़ कर सकते हैं और फ़ाइलें डाउनलोड कर सकते हैं, उनका नाम बदल सकते हैं, उन्हें दूसरी जगह ले जा सकते हैं या डिलीट कर सकते हैं
• फ़ोल्डर बना सकते हैं
• नई फ़ाइलें खींचकर डाल सकते हैं — वे टुकड़ों में अपलोड होती हैं, हर फ़ाइल 4 GB तक
• छोटी टेक्स्ट फ़ाइलें (1 MB तक) सीधे ब्राउज़र में एडिट कर सकते हैं

आकार की सीमाएँ: चैट में जोड़ी गई फ़ाइल 500 MB तक हो सकती है; Telegram बॉट्स को सिर्फ़ 20 MB तक की फ़ाइलें लेने देता है; फ़ाइल प्रबंधक हर फ़ाइल 4 GB तक स्वीकार करता है। इसके आगे एकमात्र सीमा आपकी डिस्क है — mintbot हमेशा थोड़ी ख़ाली जगह छोड़ता है ताकि सर्वर चलता रहे। डिस्क भर जाने पर एजेंट आपको बताता है और सीधे फ़ाइल प्रबंधक का लिंक देता है ताकि आप जगह ख़ाली कर सकें — या आप बस एजेंट से पुरानी फ़ाइलें डिलीट करने को कह सकते हैं।

फ़ाइल प्रबंधक में कोई फ़ाइल डिलीट करने पर वह डिस्क से हट जाती है, और एजेंट उसे फिर LLM को नहीं दिखा सकता। यही मूल फ़ाइल को “आपकी” बनाता है: उसे डिलीट करने का अधिकार सिर्फ़ आपके पास है।

सार

ज़्यादातर AI चैट प्रोडक्ट आपके अपलोड को बातचीत का एक बार इस्तेमाल होने वाला संदर्भ मानते हैं। mintbot उन्हें आपका डेटा मानता है — आपके VPS पर स्टोर, आपके स्वामित्व में, और ज़रूरत पड़ने पर उसी रूप में ढाला हुआ जो मॉडल को उस समय चाहिए। mintbot की कई ज़्यादा दिलचस्प क्षमताएँ इसी नींव पर टिकी हैं।