‏DeltaDB: کنترل نسخه برای کانتکست ایجنت‌ها

سازنده‌های ادیتور Zed تو این مقاله DeltaDB رو معرفی کردن: یه سیستم کنترل نسخه برای کانتکست ایجنت‌ها. نویسنده می‌گه با ایجنت‌ها کد خیلی سریع‌تر تولید می‌شه، ولی دلیل پشت اون کد یا تو ابزار ایجنت گیر می‌کنه یا تو Slack و یه commit message که کسی نخونده گم می‌شه. با DeltaDB می‌شه به یه تیکه کد اشاره کرد، استدلال پشتش رو برگردوند و از آدم یا ایجنتی که نوشتتش پرسید چرا این شکلیه.

زیر کار، DeltaDB مجموعه‌ای از CRDTها (یعنی ساختار داده‌هایی که چند نفر هم‌زمان ویرایششون می‌کنن و بدون تداخل ادغام می‌شن) هست که لوکال تو SQLite ذخیره می‌شن و تو یه گراف DAG به هم وصلن. هر گره اسمش delta هست، یعنی کوچیک‌ترین واحد تغییر. تغییرها اول لوکال اعمال می‌شن و هر وقت شبکه بود با سرور sync می‌شن، پس قطعی شبکه کار رو متوقف نمی‌کنه.

کل وضعیت سیستم رو می‌شه با deltaهای نوک گراف (اسمش frontier) نشون داد که اندازه‌ش به تعداد شاخه‌های باز بستگی داره، نه تعداد نویسنده‌ها. تیم عمداً سراغ version vector نرفته، چون تو یه thread آدم‌ها و ایجنت‌ها مدام میان و می‌رن و vector فقط بزرگ‌تر می‌شه. هزینه‌ش اینه که برای فهمیدن رابطهٔ دو delta باید گراف رو پیمایش کرد، ولی چون اطلاعات ancestry جدا و کوچیک ذخیره می‌شه، تو عمل سریعه. طراحی‌شون خیلی شبیه کاریه که Gentle و Kleppmann تو مقالهٔ Eg-walker شروع کردن.

برای اینکه برگشتن به هر نسخه سریع باشه، برای نسخه‌های اخیر snapshot کش می‌کنن و از نزدیک‌ترین snapshot، deltaهای بینش رو دوباره اعمال می‌کنن. وضعیت به شکل B+ treeهای copy-on-write ذخیره می‌شه، یعنی نسخهٔ جدید بیشتر گره‌های قبلی رو دوباره استفاده می‌کنه. این درخت نسخهٔ تغییریافتهٔ SumTree خود Zed هست، با این فرق که با یه cursor تغییرپذیر درجا ویرایش می‌شه و خیلی سریع‌تره.

با _timeline_ها می‌شه چند frontier رو هم‌زمان دنبال کرد؛ مثلاً یه subagent روی timeline خودش موازی کار می‌کنه و بعداً ادغام می‌شه، بدون اینکه به Git دست بزنه یا commit لازم باشه. هر thread روی یه Cloudflare Durable Object جدا sync می‌شه و هر کلاینت برای هر thread یه WebSocket باز می‌کنه. یعنی معماری تقریباً share-nothing هست و با تعداد threadها افقی scale می‌شه. نسخهٔ اول روی Cloudflare اجرا می‌شه، ولی طوری طراحی شده که به پلتفرم‌های دیگه هم ببرنش.

برای توسعه‌دهنده همهٔ اینا پشت یه API ساده قایمه: Register، Map، Buffer و Worktree (یه درخت فایل روی Git). با ماکروی #[derive(Replicate)] می‌شه اینا رو تو structهای بزرگ‌تر ترکیب کرد، مثل همین تعریف یه thread ایجنت:

#[derive(Clone, Replicate)]
struct Thread {
    #[field(0)]
    transcript: Buffer,
    #[field(1)]
    name: Register<String>,
    #[field(2)]
    worktree: Worktree,
}

هر تغییر روی این فیلدها خودش delta جدید می‌سازه و به دیسک و سرور sync می‌شه، پس لازم نیست درگیر جزئیات گراف بشی.

نکات کلیدی:

• DeltaDB از سازنده‌های Zed هست و هر ویرایش رو به گفتگوی ایجنت یا آدمی که ساختتش وصل می‌کنه.
• داده‌ها CRDTهایی تو SQLite هستن که تو یه DAG از deltaها به هم وصلن.
• به جای version vector از پیمایش گراف استفاده می‌کنه، چون نویسنده‌ها زیاد و کوتاه‌عمرن.
• وضعیت با B+ tree کپی-روی-نوشتن و snapshotهای کش‌شده سریع بازسازی می‌شه.
• هر thread یه Cloudflare Durable Object جدا داره و از طریق WebSocket sync می‌شه.
• API کلاینت: Register، Map، Buffer، Worktree و ماکروی #[derive(Replicate)].