mintbot ফাইল কীভাবে সামলায়¶
যখন আপনি আপনার mintbot agent-কে একটা ছবি, ডকুমেন্ট, voice note, spreadsheet, screenshot বা PDF পাঠান — Telegram, web panel বা API যেকোনো মাধ্যমেই — সেই ফাইলটি language model-এ পৌঁছানোর পথে mintbot-এর কেন্দ্রীয় অবকাঠামোর মধ্য দিয়ে যায় না। সে সরাসরি আপনার নিজের agent-এর VPS-এ নামে, আপনি যতদিন চান ততদিন সেখানে থাকে, এবং LLM সেখান থেকেই তার জন্য optimised একটি কপি পায়।
এটি একটি নীরব design সিদ্ধান্ত, কিন্তু এর ফলাফল গর্জে ওঠে। এই বিষয়টা খুলে বলার মতো, কারণ এটি সেই বড় জায়গাগুলোর একটা যেখানে mintbot consumer LLM chat থেকে আলাদা পথে যায়।
পুরো flow, এক প্রান্ত থেকে আরেক প্রান্ত¶
-
Upload agent VPS-এ এসে পৌঁছায়। Telegram থেকে একটা ছবি, web panel-এ drag করা একটা PDF, একটা voice memo, chat-এ paste করা একটা screenshot। Agent-এর local API bytes গ্রহণ করে, magic header শুঁকে বের করে আসলে এটা কোন ধরনের ফাইল (ফোন ও 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, এবং মূল filename সহ একটি row যোগ হয়। -
মূল ফাইলটি পবিত্র। এই মুহূর্ত থেকে mintbot-এর ভেতরে আর কিছুই সংরক্ষিত ফাইলটিকে পরিবর্তন করে না। যেসব adapter সেটিকে LLM-এর জন্য প্রস্তুত করে, তারা শুধু working copy বের করে — resize করা JPEG, transcode করা text, extract করা thumbnail। Byte-by-byte মূল ফাইলটি disk-এ থেকে যায় যতক্ষণ না আপনি agent-এর file manager থেকে নিজেই মুছে দেন। কোনো কেন্দ্রীয় bucket নেই, কোনো retention timer নেই, agent-গুলোর মধ্যে কোনো leakage নেই: প্রতিটি agent VPS শুধু নিজের মালিকের upload সম্পর্কে জানে।
-
মডেল LLM-optimised version পায়। যখন agent সিদ্ধান্ত নেয় ফাইলটি LLM-কে দেখাবে, একটা ছোট dispatcher MIME type এবং extension থেকে সঠিক adapter বাছাই করে, এবং adapter এমন content block বের করে যা মডেল পড়তে পারে:
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 MBNative PDF হিসেবে base64 inline (Anthropic মডেল সরাসরি পড়ে) Text .md,.csv,.json,.yaml, source code (.py,.js,.ts,.go,.rs, …), log, diffUTF-8 decode (latin-1 fallback), size cap পর্যন্ত text হিসেবে inline Audio .mp3,.ogg,.opus,.m4a,.wav,.flacTelegram voice note bot ইতিমধ্যেই inline transcribe করে দেয়; সরাসরি upload-এ এখন placeholder, Whisper STT পরের wave-এ আসছে Video .mp4,.mov,.webm,.mkvএখন placeholder; ffmpeg keyframe + audio transcript extraction পরের wave-এ আসছে Office docs .docx,.xlsx,.pptx,.odt,.ods,.odpএখন placeholder; native text extraction (python-docx / openpyxl / python-pptx) পরের wave-এ আসছে Unknown বাকি সব কিছু Text placeholder: "ব্যবহারকারী একটি <mime>ফাইল attach করেছেন, এটি upload ID<id>দিয়ে disk-এ সংরক্ষিত" — যাতে মডেল অন্তত কী পাঠানো হয়েছে সে বিষয়ে যুক্তি করতে পারেপ্রতিটি transformation মূল ফাইলের পাশে
<sha256>.cache/v<N>.jsonহিসেবে cache হয়, ফলে দ্বিতীয়বার মডেলের সেই ফাইল লাগলে load instant হয়ে যায়। Adapter-এর version বাড়ালে cache স্বয়ংক্রিয়ভাবে invalidate হয়। -
মডেল context-এ মেয়াদ-শেষ হওয়া URL যায় না। যখন কোনো image বা PDF LLM-এ যায়, সেটা একই turn-এ base64 inline করা হয় — পরে 404 হতে পারে এমন কোনো URL নেই, timer-যুক্ত signed link নেই। বড় ফাইলের জন্য, যেখানে মডেলের শুধু একটা pointer দরকার, URL হল একটা internal
https://agent<id>.<domain>/<panel_token>/api/local/uploads/<upload_id>/raw— আপনার নিজের agent-এর panel token দিয়ে সুরক্ষিত, এবং যতদিন ফাইল disk-এ আছে ততদিন valid।
কেন এটি consumer LLM chat experience-কে হারিয়ে দেয়¶
আপনি যখন ChatGPT-তে একটা ছবি বা Claude.ai-তে একটা PDF upload করেন, ফাইলটি যায় provider-এর storage-এ, ঐ conversation-এর সাথে যুক্ত হয়, এবং কখন অদৃশ্য হবে তা provider-এর retention policy ঠিক করে। একটা নির্দিষ্ট বয়সের পর ফাইল চলে গেছে, এমনকি আপনি যে conversation-এ সেটা ছিল সেটা এখনও দেখতে পেলেও। এক provider থেকে অন্য provider-এ switch করার মানে হল আবার শূন্য থেকে শুরু।
একটি সাধারণ Telegram-bot ফাঁদ এই বৈপরীত্যকে স্পষ্ট করে দেয়। Telegram নিজেই প্রতিটি ছবির জন্য একটি স্থায়ী file_id রাখে, কিন্তু থার্ড-পার্টি bot যারা Telegram file_id দিয়ে ফাইল আনে তারা একটি অস্থায়ী URL পায় যা ২৪ ঘণ্টায় expire হয়। গতকালের ছবিকে রেফার করা পুরোনো bot 404 দেয়। mintbot এই সমস্যাটা এক বারেই সমাধান করে: প্রথমবার যখন সে Telegram-এর কোনো ফাইল দেখে, সে চিরস্থায়ীভাবে valid file_id-এর মাধ্যমে bytes আবার এনে নেয় এবং আপনার agent-এর archive-এ কপি করে। ঐ মুহূর্ত থেকে ছবিটি আপনার।
এই design থেকে তিনটি জিনিস বের হয়:
- ফাইল আপনার, LLM provider-এর নয়। পরের মাসে Claude থেকে GPT-5-এ switch করুন — আপনার file history অক্ষত হয়ে আপনার সাথে যায়, কারণ সেটা আপনার VPS-এ, কোনো vendor-এর bucket-এ নয়।
- আপনি পরে আবার জিজ্ঞেস করতে পারেন। "তিন মাস আগে তুমি আমার জন্য একটা চুক্তি analyse করেছিলে — সেটা কি এই নতুন draft-এর সাথে তুলনা করতে পারবে?" কাজ করে, কারণ মূল ফাইলটি এখনও disk-এ আছে। Consumer chat-এ পুরোনো ফাইল সাধারণত চলে গেছে।
- মডেল সবসময় সেই version পায় যেটা সে সবচেয়ে ভালো ব্যবহার করতে পারে। Vision মডেল পায় resize করা JPEG, text-reader পায় UTF-8, PDF-reader পায় native PDF। ফোন HEIC upload করতে পারে এবং সেটা ঠিকঠাক কাজ করে — Pillow-র HEIF plugin startup-এই load হয়, এবং magic-byte sniffer সেই ফোনগুলো ধরে ফেলে যারা upload-কে
application/octet-streamবলে ভুল label দেয়।
আপনার ফাইল কোথায় সামলাবেন¶
Agent web panel-এর top bar-এ একটি file manager আছে। সেটা পুরো agent VPS browse করে, আর upload archive /var/lib/mintbot-agent/uploads/ সেই অংশ যেটা আপনার কথোপকথন ভরে তোলে। সেখান থেকে আপনি পারেন:
- Upload করা ফাইল rename, delete, বা move করতে
- তারিখ, source, বা filename দিয়ে browse করতে
- নতুন upload drag-drop করতে (chunked, কয়েক gigabyte বড় ফাইল সমর্থন করে)
- ছোট text ফাইল inline edit করতে
Panel থেকে কোনো ফাইল মুছে ফেললে blob এবং catalog row দুটোই চলে যায়। Agent সেটাকে আর LLM-কে দেখাতে পারবে না। এটাই সেই জিনিস যা মূল ফাইলকে "আপনার" করে তোলে: মুছে ফেলার অধিকার একমাত্র আপনারই।
মোদ্দা কথা¶
বেশিরভাগ LLM chat product আপনার upload-কে ক্ষণস্থায়ী conversation context হিসেবে ধরে। mintbot সেগুলোকে আপনার data হিসেবে ধরে — আপনার VPS-এ সংরক্ষিত, আপনার মালিকানায়, এবং চাহিদামতো এমন রূপে রূপান্তরিত যা মডেল ঐ turn-এ সবচেয়ে ভালো ব্যবহার করতে পারে। mintbot-এর বেশি দিলচস্প সক্ষমতাগুলোর অনেকটাই এই ভিত্তির ওপর বসানো।