SSD Nodes Learn 🎉 VPS $5.50/ماہ سے
تعلیمی Matt Connorتحریر: Matt Connor · اپ ڈیٹ شدہ 2026-08-13

Compartment: offline encrypted agent memory کیا ہے؟

Compartment آپ کی اپنی machine پر agent memory کو encrypted اور offline رکھتا ہے۔ threat model کی حدیں، version 4.6.0 کی تفصیل اور key کھونے کا نتیجہ جانیں۔

Compartment کیا مختلف طریقے سے کام کرتا ہے

Compartment ایک agent memory store ہے جو ہر record کو اسے بنانے والی مشین پر encrypted رکھتا ہے اور کبھی کسی network service سے رابطہ نہیں کرتا۔ دو خصوصیات اسے agent memory کے باقی شعبے سے الگ کرتی ہیں۔ vault ایک ہی sealed file ہے جسے صرف آپ کا passphrase کھول سکتا ہے، اور embedding مرحلہ مقامی طور پر چلتا ہے، اس لیے memory کا متن vector میں تبدیل ہونے کے لیے کبھی کہیں بھیجا نہیں جاتا۔ Version 4.6.0 کو 10 August 2026 کو publish کیا گیا، licence Apache-2.0 ہے، اور اسے PyPI سے install کیا جاتا ہے۔

یہ threat model کا دعویٰ ہے، اس لیے یہ guide اسے اسی حیثیت سے دیکھتی ہے۔ Encryption at rest اور offline design مخصوص چیزوں کو محفوظ بناتے ہیں۔ دیگر چیزیں محفوظ نہیں رہتیں، اور یہی خلا دوسرے دن کے مسائل کا باعث بنتا ہے۔

یہ guide project کی اپنی documentation اور release notes کی پیروی کرتی ہے، جنہیں 11 August 2026 کو پڑھا گیا تھا۔ Compartment اپنے command line tool کے ساتھ desktop application، macOS پر menu bar item، اور Windows پر notification area icon فراہم کرتا ہے، جبکہ automated container سے passphrase prompt کو control نہیں کیا جا سکتا۔ ذیل کی معلومات کو یہاں ناپے گئے رویے کے بجائے documented behaviour سمجھیں۔ کسی حقیقی اہم data پر اعتماد کرنے سے پہلے اسے spare machine پر چلائیں۔

کون سی چیز encryption at rest حقیقتاً محفوظ بناتی ہے

Vault کو XChaCha20-Poly1305 سے seal کیا گیا ہے۔ یہ AEAD (authenticated encryption with associated data) cipher ہے۔ Master key رکھنے والے keyslots کو Argon2id سے wrap کیا گیا ہے۔ Argon2id ایک password hashing function ہے جسے جان بوجھ کر سست بنایا گیا ہے اور جسے بہت زیادہ memory درکار ہوتی ہے۔

اس کے دو نتائج ہیں۔ چوری شدہ disk، پرانے backup یا support ticket کے ساتھ منسلک file کی copy صرف bytes رہ جاتی ہے، اس کے علاوہ کچھ نہیں۔ File کھولتے وقت ایک bit بھی تبدیل ہو جائے تو authentication ناکام ہو جاتی ہے۔ اس طرح corruption غلط جواب کے بجائے واضح error بن جاتی ہے۔

Embedding vectors بھی encrypted ہوتے ہیں، اور یہ بات بظاہر جتنی معمولی لگتی ہے اس سے زیادہ اہم ہے۔ Embedding، hash نہیں ہوتا۔ Embedding inversion پر ہونے والی research سے معلوم ہوا ہے کہ صرف vector کی بنیاد پر اصل text کے قابلِ مطالعہ ٹکڑے دوبارہ حاصل کیے جا سکتے ہیں۔ اس لیے encrypted database کے ساتھ plaintext vector index رکھنا تقریباً database کو کھلا چھوڑنے کے برابر ہے۔ Compartment disk پر plaintext index نہیں لکھتا۔

Deletion حقیقی deletion ہے۔ ہر record کی اپنی key ہوتی ہے، اور compartment forget --shred اس key کو destroy کرتا ہے۔ اس کے بعد پیچھے رہ جانے والا ciphertext کوئی بھی decrypt نہیں کر سکتا، آپ بھی نہیں۔ اس کا موازنہ database file سے delete کی گئی row سے کریں۔ ایسی row عموماً free pages میں اس وقت تک readable رہتی ہے جب تک کوئی چیز اسے overwrite نہ کر دے۔

Offline ہونا اس کا دوسرا اہم حصہ ہے۔ کچھ بھی upload نہیں کیا جاتا۔ اس لیے کوئی vendor account آپ کی memories محفوظ نہیں رکھتا، اور نہ ہی کوئی API key موجود ہوتی ہے جو leak ہو سکے۔

کون سی Compartment تحفظ فراہم نہیں کرتی

یہ دعویٰ vault کی حد تک درست ہے، اور یہ حد بظاہر جتنی دور لگتی ہے، اس سے زیادہ قریب ہے۔

agent plaintext پڑھتا ہے۔ Recall memory کو decrypt کر کے متن agent کے حوالے کرتا ہے۔ اگر وہ agent hosted model ہے تو memory اگلے prompt کے اندر model provider تک پہنچتی ہے، بالکل اسی طرح جیسے context window کے اندر موجود باقی تمام مواد۔ Encryption at rest فائل کو محفوظ رکھتی ہے۔ یہ retrieval کو محفوظ نہیں رکھتی۔ اس لیے AI agents سے secrets باہر رکھنے کے قواعد اس وجہ سے نرم نہیں ہوتے کہ store encrypted ہے: memory کے طور پر محفوظ کیا گیا password ایسا password ہے جسے آپ نے خود بخود prompt میں paste ہونے کے لیے ترتیب دیا ہے۔

چلتی ہوئی machine پر unlocked vault کھلا ہوتا ہے۔ project کی security notes میں یہ بات واضح طور پر درج ہے۔ vault کے unlocked رہنے کے دوران master key اور working set RAM میں موجود رہتے ہیں، Python اس بات کی ضمانت نہیں دے سکتا کہ buffer کو wipe کر دیا گیا ہے، اور swap یا hibernation image اس memory کو disk پر لکھ سکتی ہے۔ آپ کے user کے طور پر چلنے والے malware کو cipher توڑنے کی ضرورت نہیں ہوتی، کیونکہ وہ پہلے سے unlocked vault سے درخواست کر سکتا ہے۔

Caller identity declarative ہوتی ہے۔ ہر caller کے لیے namespaces محدود کیے جا سکتے ہیں، لیکن caller کا نام host process سے آتا ہے۔ اس لیے جو host اپنے نام کے بارے میں جھوٹ بولے، اسے وہی grants مل جاتے ہیں جن کا وہ دعویٰ کرتا ہے۔ Namespace permissions تنظیمی سہولت ہیں، hostile local program کے خلاف security boundary نہیں۔

Shredding copies تک نہیں پہنچ سکتی۔ forget --shred موجودہ فائل کے اندر key کو destroy کرتی ہے۔ Shred سے پہلے لیا گیا backup اب بھی وہ record رکھتا ہے، اور اس دن کے passphrase سے اب بھی کھل جاتا ہے۔

کمزور passphrase بحث ختم کر دیتا ہے۔ Argon2id ہر guess کو مہنگا بناتا ہے۔ یہ ایسے passphrase کو محفوظ نہیں کر سکتا جو word list میں موجود ہو۔

Pin کی گئی release سے Compartment انسٹال کریں

Compartment کے لیے Python 3.11 یا اس کے بعد کا ورژن درکار ہے۔ یہ project تیزی سے آگے بڑھ رہا ہے؛ 10 August 2026 تک PyPI پر اس کے 30 versions موجود تھے۔ اس لیے انسٹالیشن کے دن دستیاب موجودہ version لینے کے بجائے version کو pin کریں۔

python3 --version
pip install "compartment==4.6.0"
compartment --version
compartment init

compartment --version کو وہ version دکھانا چاہیے جسے آپ نے pin کیا ہے۔ اگر shell compartment: command not found کا جواب دے تو install directory آپ کے PATH میں شامل نہیں ہے۔ زیادہ تر systems میں یہ directory ~/.local/bin ہوتی ہے۔ pipx install compartment==4.6.0 اور uv tool install compartment==4.6.0 اپنے paths خود manage کرتے ہیں، اس لیے یہ مسئلہ نہیں ہوتا۔

compartment init آپ سے passphrase دو مرتبہ مانگتا ہے اور کچھ بھی ظاہر نہیں کرتا۔ یہی passphrase واحد key ہے۔ project کوئی password یا recovery phrase generate نہیں کرتا۔ یہ جان بوجھ کر ایسا ہے: software کے پاس ایسی کوئی credential موجود نہیں ہوتی جس کا آپ کو علم نہ ہو۔

اس کے ساتھ کوئی چیز منسلک کرنے سے پہلے نتیجہ چیک کریں۔

compartment status

درست vault بتاتا ہے کہ وہ unlocked ہے۔ اگر وہ locked بتائے تو compartment unlock چلائیں اور passphrase درج کریں۔ restart کے بعد یہ دوبارہ lock ہو جاتا ہے، کیونکہ اسے کھلا رکھنے والی credential فی boot secret پر منحصر ہوتی ہے۔ macOS پر compartment unlock --keychain استعمال کرنے سے reboot کے بعد بھی یہ credential برقرار رہتی ہے، کیونکہ اسے system keychain میں محفوظ کیا جاتا ہے۔

اصل ڈیٹا کہاں موجود ہوتا ہے

default vault، ~/.compartment/memory.vault ہے۔ کسی بھی command کے ساتھ --vault PATH استعمال کر کے اسے کسی دوسری جگہ کی طرف point کریں، یا COMPARTMENT_VAULT environment variable استعمال کریں۔

یہ ایک file ہی مکمل store ہے۔ اس کے شروع میں ایک header ہوتا ہے، جس میں format version اور Argon2id keyslots شامل ہوتے ہیں۔ اس کے بعد sealed payload اور پھر نئی memories شامل ہونے پر append ہونے والی journal entries آتی ہیں۔ ہر journal entry کو اس کی length اور اسی length کے CRC (cyclic redundancy check) کے ساتھ frame کیا جاتا ہے۔ اس لیے crash کی وجہ سے ادھوری رہ جانے والی write کو data کے طور پر پڑھنے کے بجائے truncated entry کے طور پر شناخت کیا جاتا ہے۔ Compaction vault کو serialise کرتا ہے، ایک temporary file لکھتا ہے، اسے fsync کرتا ہے، پھر اسے rename کر کے اصل جگہ پر رکھ دیتا ہے۔ اس کا مطلب ہے کہ reader کو کبھی half-written vault نظر نہیں آتا۔

اس کا مفید نتیجہ یہ ہے کہ backup script صرف ایک path copy کرتی ہے۔ مشکل یہ ہے کہ آپ اسے grep نہیں کر سکتے اور text editor میں repair نہیں کر سکتے۔ اگر آپ ایسی memory چاہتے ہیں جسے cat سے پڑھا جا سکے اور git میں commit کیا جا سکے، تو Memmy کی سادہ مقامی memory files اس کے برعکس انتخاب ہیں۔ دونوں طریقے مناسب ہیں۔ انتخاب اس بات پر منحصر ہے کہ آپ کو stolen laptop کا خدشہ ہے یا کسی tool کے خراب ہونے کا۔

compartment uninstall software کو remove کرتا ہے اور vault برقرار رکھتا ہے۔ --purge صرف اسی وقت pass کریں جب واقعی یہی مقصد ہو۔

کسی agent کے ساتھ مربوط کرنا

ایک command کسی معاونت یافتہ client کو مربوط کر دیتی ہے۔

compartment integrate --list
compartment integrate claude

Claude Code کے لیے یہ MCP (model context protocol) server entry اور PostToolUse hook کو ~/.claude/settings.json میں لکھتا ہے، اور پہلے موجود file کا backup بناتا ہے۔ یہ /compartmentalize skill کو ~/.claude/skills/ کے تحت install کرتا ہے اور ~/.claude/CLAUDE.md میں ایک managed block شامل کرتا ہے۔ یہ block agent کو بتاتا ہے کہ Compartment اس file پر مبنی memory کی جگہ استعمال ہوگا جو agent پہلے استعمال کر رہا تھا۔ دونوں حصوں کی تصدیق کریں:

compartment hook status
compartment recent

Server کو ہاتھ سے register کرنے کے لیے:

claude mcp add --scope user compartment -- \
    compartment --vault ~/.compartment/memory.vault --caller claude-code serve

کوئی بھی دوسرا MCP capable host اپنے caller name کے ساتھ اسی server کو استعمال کر سکتا ہے۔

{ "mcpServers": { "compartment": {
    "command": "compartment",
    "args": ["--vault", "/path/to/memory.vault",
             "--caller", "your-agent-name", "serve"] } } }

ہر host کو مختلف --caller value دیں۔ Audit log میں درج ہونے والا label اور namespace grants کے لیے استعمال ہونے والی key یہی ہے، اس لیے مشترک name رکھنے سے دونوں کا مقصد ختم ہو جاتا ہے۔

اگر Claude Code پہلے ہی اپنی memory files میں facts لکھ رہا ہو تو compartment import-claude --dry-run دکھاتا ہے کہ کسی بھی چیز کو منتقل کرنے سے پہلے کیا منتقل ہوگا۔ پہلے Claude Code اپنی memory files میں کیا محفوظ رکھتا ہے پڑھیں، کیونکہ ایک سال کے notes کو نئے vault میں import کرنے سے memory store ایسی چیزوں سے بھر جاتا ہے جنہیں کوئی محفوظ رکھنا نہیں چاہتا تھا۔

مقامی vault کتنی تیز ہے

یہ اعدادوشمار project ذاتی سائز کے vault کے لیے شائع کرتا ہے۔ یہ project کی documentation سے لیے گئے ہیں، یہاں کسی run کے نتائج نہیں ہیں۔

ChartCompartment published local latency, milliseconds
The data behind this chart
[
  {
    "label": "Store one memory, end to end",
    "latency_ms": 40
  },
  {
    "label": "Embed one memory, bundled model",
    "latency_ms": 25
  },
  {
    "label": "Hybrid search, median",
    "latency_ms": 11.6
  },
  {
    "label": "Vector search at 20k records, p95",
    "latency_ms": 0.68
  }
]

ایک memory محفوظ کرنے میں 40 ms لگتے ہیں، جبکہ بیس ہزار records میں vector search کے لیے 95th percentile پر 0.68 ms درکار ہوتے ہیں۔ memory کو local رکھنے کے لیے project کی دلیل حساب پر مبنی ہے: hosted memory API کو network کے ذریعے ایک round trip میں اکثر یہاں مکمل hybrid search کے 11.6 ms کے median سے زیادہ وقت لگتا ہے۔

دو design details search کے اعدادوشمار کی وضاحت کرتی ہیں۔ بیس ہزار records سے کم ہونے پر Compartment ہر vector کے ساتھ query کا موازنہ کرتا ہے، اس لیے recall ساختی طور پر exact رہتا ہے، approximate نہیں۔ اس حد سے زیادہ ہونے پر یہ HNSW (hierarchical navigable small world) استعمال کرتا ہے۔ یہ ایک approximate index ہے جو speed کے بدلے recall میں معمولی کمی قبول کرتا ہے۔ vault embedding model کا SHA-256 hash بھی محفوظ کرتا ہے اور مختلف model کے ساتھ کھلنے سے انکار کرتا ہے، کیونکہ دو مختلف models کے vectors کا موازنہ بظاہر کسی error کے بغیر ہو سکتا ہے، جبکہ حاصل ہونے والے scores بے معنی ہوتے ہیں۔

بیک اپس، اور وہ copy جسے آپ اگلے سال بھی کھول سکیں

ایک locked vault صرف ایک portable file ہوتی ہے، اس لیے اسے منتقل کرنا دراصل copy بنانا ہے۔

compartment lock
scp ~/.compartment/memory.vault other-machine:
compartment --vault memory.vault unlock

پہلے اسے lock کریں۔ agent کے لکھنے کے دوران copy بنانے سے journal entry کا append درمیان میں رہ سکتا ہے۔ اگرچہ CRC framing reader کو اس آخری fragment کو skip کرنے دیتی ہے، لیکن اس کے اندر موجود memory ضائع ہو جاتی ہے۔ compartment lock --sign file کو Ed25519 manifest سے seal کرتا ہے۔ اس طرح receiving machine passphrase اپنے پاس رکھے بغیر verify کر سکتی ہے کہ copy مکمل حالت میں پہنچی ہے۔

چونکہ file پہلے ہی seal ہو چکی ہے، اس لیے عام cloud storage اس کے لیے قابل قبول جگہ ہے۔ یہی وہ مقام ہے جہاں encryption at rest براہ راست فائدہ دیتا ہے: backup target کو کبھی کوئی memory نظر نہیں آتی۔

دو انتباہات اہم ہیں۔ Shredding backups تک نہیں پہنچتی۔ اس لیے آج crypto shredded کیا گیا record، last week's copy میں اس شخص کے لیے اب بھی readable رہتا ہے جس کے پاس last week's passphrase ہو۔ اور compartment export --plaintext پورے vault کو unencrypted لکھتا ہے۔ کسی دوسری چیز میں migration کے لیے یہ درست tool ہے، لیکن ~/Downloads میں چھوڑنے کے لیے یہ غلط file ہے۔

کاپیوں کی تعداد کم رکھیں اور ان پر تاریخ درج کریں۔ جب کوئی memory store prune نہیں کرتا تو وہ liability بن جاتا ہے۔ اسی کی وضاحت یہ ہے کہ پرانی agent memories خاموشی سے retrieval کو کیوں خراب کرتی ہیں۔

کلید کا انتظام، گردش، اور دوسرا عامل

compartment rekey
compartment 2fa enable
compartment 2fa status

rekey موجودہ فائل کے keyslot میں master key کو دوبارہ wrap کرکے passphrase تبدیل کرتا ہے۔ پرانی copies میں پرانی passphrase برقرار رہتی ہے، کیونکہ ان bytes کو تبدیلی سے پہلے seal کیا گیا تھا اور انہیں واپس جاکر edit نہیں کیا جاتا۔ Copies کو بھی rotate کریں، یا یہ تسلیم کریں کہ retired passphrase اب بھی کسی چیز کو کھول سکتی ہے۔

2fa enable ایک keyfile کو دوسرے عامل کے طور پر شامل کرتا ہے۔ Key derivation کے دوران یہ passphrase کے ساتھ استعمال ہوتی ہے، اس لیے vault کھولنے کے لیے دونوں درکار ہوتے ہیں۔ اس سے ان چیزوں کی تعداد بھی دوگنی ہو جاتی ہے جو آپ کھو سکتے ہیں۔ Keyfile کو اس machine سے الگ رکھیں جس پر vault موجود ہے۔

Scripts اور CI (continuous integration) کے لیے passphrase COMPARTMENT_PASSPHRASE environment variable کے ذریعے فراہم کی جا سکتی ہے، اور unlock --passphrase-stdin اسے pipe سے پڑھتا ہے۔ Pipe کو ترجیح دیں۔ اسی user کے زیرِ ملکیت دوسرے processes environment variable پڑھ سکتے ہیں، اور یہ عموماً job logs میں بھی شامل ہو جاتی ہے۔

Audit history hash chained ہے، اور compartment audit verify اس میں آگے بڑھ کر پہلی ٹوٹی ہوئی link کی اطلاع دیتا ہے۔ ہر restore کے بعد اسے چلائیں، کیونکہ اسی وقت خاموشی سے truncated file ظاہر ہوتی ہے۔

پاس فریز بھول جانے پر کیا ہوتا ہے

کچھ نہیں ہوتا، اور یہی اس ڈیزائن کا مقصد ہے۔ کوئی reset، recovery phrase یا لکھنے کے لیے address موجود نہیں ہوتا، کیونکہ key کی کوئی نقل آپ کی یادداشت اور optional keyfile کے علاوہ کہیں موجود نہیں ہوتی۔ vault random نظر آنے والے bytes کی ایک file ہی رہتا ہے۔

اس لیے recovery plan vault کے لیے نہیں بلکہ passphrase کے لیے ہوتا ہے۔ compartment init چلانے کے دن اسے password manager میں محفوظ کریں۔ پھر اسے آزمائیں: vault کو lock کریں، صرف اپنے لکھے ہوئے passphrase سے اسے unlock کریں، اور اس کے بعد agent کو اسے بھرنا شروع کرنے دیں۔

Compartment یا memory server

Compartment بنیادی طور پر ایک ہی machine کے لیے بنایا گیا ہے۔ Sharing کا مطلب locked file کو copy کرنا، یا data کو export اور import کرنا ہے۔ اس میں concurrent writer موجود نہیں ہوتا۔ اس لیے ایک ہی file کی طرف متوجہ laptop اور workstation ایک دوسرے کا کام overwrite کر دیں گے۔

جب کئی machines کو ایک ہی وقت میں ایک ہی memory درکار ہو، تو یہ server کا مسئلہ ہے۔ VPS پر self-hosted Mem0 memory server اس کا حل فراہم کرتا ہے: ایک endpoint، متعدد clients، اور ایسی memory جو laptop کے بعد بھی برقرار رہتی ہے۔ اس کی لاگت واضح طور پر سمجھنا ضروری ہے۔ یہ server ایسا process چلاتا ہے جو اس میں محفوظ data پڑھ سکتا ہے۔ اس لیے اب آپ کے threat model میں VPS اور ہر وہ شخص شامل ہے جو اس کی API تک پہنچ سکتا ہے۔

انتخاب اس نقصان کے مطابق کریں جس کا آپ کو حقیقی خدشہ ہے۔ اگر خدشہ laptop چوری ہونے یا vendor کے آپ کے notes پڑھنے کا ہے، تو encrypted local vault زیادہ مضبوط جواب ہے۔ اگر خدشہ یہ ہے کہ machines تبدیل کرتے ہی agent سب کچھ بھول جاتا ہے، تو server بہتر انتخاب ہے۔

FAQ

Compartment کی encryption اصل میں کس چیز کو محفوظ رکھتی ہے؟

یہ فائل کو محفوظ رکھتی ہے۔ vault کو XChaCha20-Poly1305 سے seal کیا جاتا ہے، اس کے keyslots کو Argon2id سے wrap کیا جاتا ہے، اور embedding vectors بھی encrypted ہوتے ہیں۔ اس لیے چوری شدہ disk یا پرانا backup ایسے bytes فراہم کرتا ہے جن میں کچھ بھی قابلِ مطالعہ نہیں ہوتا۔ یہ running machine پر unlocked vault کو محفوظ نہیں رکھتی، کیونکہ vault کھلا ہونے کے دوران master key RAM میں موجود ہوتی ہے۔ یہ اس بات کو بھی control نہیں کرتی کہ recall کے بعد plaintext memory ملنے پر agent اس کے ساتھ کیا کرتا ہے۔

اگر Compartment offline ہو تو کیا میری memories میرے model provider سے private رہتی ہیں؟

صرف recall ہونے تک۔ Storing اور searching network کے بغیر ہوتی ہے، اور embedding model locally چلتا ہے۔ اس لیے write کے وقت machine سے کچھ باہر نہیں جاتا۔ Read کے وقت agent کو plaintext ملتا ہے۔ اگر وہ agent hosted model ہو تو memory prompt میں شامل ہو کر provider تک context window کے باقی حصے کی طرح پہنچتی ہے۔ کسی credential کو memory کے طور پر کبھی store نہ کریں۔

اگر میں اپنی Compartment passphrase کھو دوں تو کیا ہوگا؟

vault ناقابلِ بازیافت ہو جائے گا، اور یہ جان بوجھ کر ایسا ہے۔ Compartment کوئی seed یا recovery phrase generate نہیں کرتا، اور ایسی کوئی credential محفوظ نہیں رکھتا جو آپ کے پاس موجود نہ ہو۔ اس لیے reset کرنے کے لیے کچھ نہیں ہوتا۔ passphrase کو password manager میں رکھیں، vault رکھنے والی machine سے کسی بھی 2FA keyfile کو الگ محفوظ رکھیں، اور vault میں اہم data رکھنے سے پہلے تصدیق کریں کہ آپ اس کی copy unlock کر سکتے ہیں۔

کیا دو machines ایک ہی Compartment vault share کر سکتی ہیں؟

ایک ہی وقت میں نہیں۔ locked vault ایک portable file ہوتی ہے۔ دستاویزی طریقہ یہ ہے کہ اسے lock کریں، copy کریں، پھر --vault کے ذریعے دوسری machine پر unlock کریں۔ concurrent access موجود نہیں ہوتی، اس لیے دو machines کا ایک ہی file میں لکھنا memories ضائع کر دے گا۔ جب اس کی ضرورت ہو تو memory server چلائیں۔

#agent-memory#compartment#encryption#offline#privacy