پایگاه‌داده شخصی؛ جایگزینی برای صفحهٔ ورود و رمز عبور

تصور کنید وارد وب‌سایتی شوید که هیچ پرسشی درباره رمز عبور، ایمیل یا لینک‌های جادویی (Magic Link) از شما نمی‌کند. در عوض، برنامه صرفاً اجازه می‌خواهد به پایگاه‌داده‌ای متصل شود که شما مالک آن هستید و کنترلش را در دست دارید. این ایدهٔ مرکزی پروژه ayb است؛ سیستمی که طراحی شده تا قدرت را از دست مالکان اپلیکیشن‌ها بگیرد و آن را به کاربرانی که در واقع تولیدکنندگان اصلی داده‌ها هستند، بازگرداند.

مارکوا (Marcua)، خالق این پروژه، استدلال می‌کند که معماری فعلی وب بر پایه فلسفه «احراز هویت» (Authentication) بنا شده است. وقتی با یک صفحهٔ ورود مواجه می‌شوید، برنامه در واقع دارد به شما می‌گوید: «برای اینکه به داده‌های خودت که در پایگاه‌داده من ذخیره شده دسترسی داشته باشی، ثابت کن تو همان کسی هستی که ادعا می‌کنی.» در حقیقت، شما مجبورید خودتان را به اپلیکیشن احراز هویت کنید تا صرفاً این امتیاز را داشته باشید که داده‌هایتان را به آن برنامه بدهید.

این ساختار، کنترل و حضانت کامل اطلاعات شما را به توسعه‌دهنده اپلیکیشن می‌سپارد. این موضوع شما را در برابر تغییرات ناگهانی سیاست‌های حریم خصوصی، فروش داده‌ها به شخص ثالث یا نشت‌های امنیتی فاجعه‌بار آسیب‌پذیر می‌کند. مالکان اپلیکیشن‌ها می‌توانند دسترسی شما به داده‌های خودتان را محدود کنند، داده‌ها را به‌طور کامل حذف کنند یا باگ‌هایی ایجاد کنند که به دیگران اجازه دسترسی به اطلاعات شما را بدهد. همچنین، این شرکت‌ها ممکن است دچار حکومتی متلاطم شوند، مدیریت یا مالکیت آن‌ها تغییر کند و در نتیجه سیاست‌هایشان در آینده عوض شود. به‌طور خلاصه، این وضعیت از نظر مارکوا یک «مزخرف» (Poppycock) کامل است.

برای رسیدن به استقلال و عاملیت واقعی، کاربر باید بر پایگاه‌داده‌ای که داده‌هایش در آن زندگی می‌کند، تسلط داشته باشد. اگر شما مالک پایگاه‌داده باشید، در واقع مالک داده‌ها هستید. با این حال، مانع فنی بزرگی وجود دارد؛ مدیریت یک پایگاه‌داده جدی است و نمی‌توان از کاربر عادی انتظار داشت که یک نمونه Postgres را اداره کند و به پشتیبان‌گیری‌های دوره‌ای رسیدگی نماید. چارچوب ayb تلاش می‌کند این مانع را بردارد تا ساخت یک پایگاه‌داده به سادگی نام‌گذاری یک سند جدید در گوگل‌درایو یا مایکروسافت ورد باشد.

سازوکار «مجوزدهی به جای احراز هویت»

جریان پیشنهادی در این مدل، درخواست «وارد کردن رمز عبور» را با درخواست «اتصال پایگاه‌داده شما» جایگزین می‌کند. این تغییر مسیر توسط یک استاندارد فنی شناخته‌شده پشتیبانی می‌شود:

• جریان OAuth2: اپلیکیشن یک درخواست OAuth2 به ayb می‌فرستد تا توکنی دریافت کند. این سازوکار به برنامه اجازه می‌دهد تا داده‌های خاص کاربر را کوئری کند، بدون اینکه اپلیکیشن هرگز مالک زیرساخت حساب‌های کاربری باشد.
• یکپارچه‌سازی برای توسعه‌دهندگان: مارکوا کتابخانه ayb.js را منتشر کرده است. این یک کتابخانه متن‌باز است که به مهندسان اجازه می‌دهد این جریان مجوزدهی را در کمتر از یک ساعت در اپلیکیشن‌های جدید خود پیاده‌سازی کنند.
• راه‌اندازی ساده‌شده: جریان مجوزدهی به کاربر اجازه می‌دهد تا یا یک پایگاه‌داده موجود را انتخاب کند و یا صرفاً با انتخاب یک نام برای آن، پایگاه‌داده جدیدی بسازد.
• نگهداری خودکار: اگر کاربر پایگاه‌داده خود را از طریق این جریان ایجاد کند، بدون نیاز به هیچ تنظیم دستی، اسنپ‌شات‌ها و نسخه‌های پشتیبان دوره‌ای دریافت می‌کند. اپلیکیشن به‌طور خودکار مهاجرت‌های دیتابیسی (Migrations) و ذخیره‌سازی داده‌ها را مدیریت می‌کند زیرا می‌داند چگونه با ayb صحبت کند.

حریم خصوصی معماری و وضعیت (State)

در این مدل، اپلیکیشن به عنوان یک موجودیت «بدون وضعیت» (Stateless) باقی می‌ماند. برای مثال، اپلیکیشن Todos — یک برنامه لیست کارهای روزانه که نویسنده از آن استفاده می‌کند — با استفاده از HTML، CSS و جاوااسکریپت ایستا (Static) ساخته شده است. این برنامه هیچ‌چیز درباره بازدیدکنندگانش نمی‌داند. اگرچه توسعه‌دهنده ممکن است آدرس IP کسانی که منابع استاتیک را دانلود می‌کنند در لاگ‌های سرور ببیند، اما اپلیکیشن هیچ «وضعیت» یا داده‌ای را در سرورهای توسعه‌دهنده ذخیره نمی‌کند.

برای کسانی که به دنبال حریم خصوصی بیشتری هستند، اپلیکیشن Todos می‌تواند به عنوان یک فایل index.html مستقل دانلود و به‌صورت شخصی میزبانی (Self-hosted) شود. زمانی که کاربر برنامه را اجرا کرده و برای دریافت توکن به پایگاه‌داده خود متصل می‌شود، تمام موارد حساس لیست کارهای او در پایگاه‌داده‌ای ذخیره می‌شود که خود کاربر مالک آن است. از آنجایی که داده‌ها در دیتابیس کاربر قرار دارند، کاربر این توانایی را دارد که در هر لحظه دسترسی اپلیکیشن را لغو کند.

این رویکرد از اثر «قفل‌شدگی» (Lock-in) که در پلتفرم‌های SaaS بسیار رایج است جلوگیری می‌کند؛ جایی که کاربران نمی‌توانند به راحتی داده‌های خود را به یک رقیب منتقل کنند، زیرا شرکت اصلی کنترل فرآیند خروجی (Export) را در دست دارد. با جدا کردن اپلیکیشن از پایگاه‌داده، کاربران دیگر مجبور نیستند به‌طور ضمنی بپذیرند که هر توسعه‌دهنده برنامه، متولی بخشی از داده‌های آن‌ها باشد.

مواجهه با پارادوکس اعتماد

مارکوا به‌طور انتقادی به یک تنش اشاره می‌کند: کاربران در واقع اعتماد به یک «اپلیکیشن شخص ثالث» را با اعتماد به یک «میزبان پایگاه‌داده شخص ثالث» معاوضه می‌کنند. اگر کاربر از یک سرویس مدیریت‌شده‌ی ayb استفاده کند، همچنان به یک ارائه‌دهنده خارجی متکی است و این ریسک وجود دارد که یک فرم از مرکزگرایی با فرم دیگری جایگزین شود.

برای کاهش این ریسک، ayb متن‌باز است. این ویژگی به کاربرانی که از نظر فنی توانمند هستند اجازه می‌دهد تا نرم‌افزار را خودشان نصب و اجرا کنند؛ هرچند نویسنده اشاره می‌کند که نباید انتظار داشت هر کاربری به یک مدیر پایگاه‌داده تبدیل شود. هدف این است که این لایه‌ی انتزاعی (Abstraction)، هزینه بازپس‌گیری عاملیت را کاهش دهد؛ به این ترتیب، وقتی کاربر بر ابزاری مانند ayb مسلط شد، می‌تواند از آن در چندین اپلیکیشن مختلف استفاده کند.

علاوه بر این، سیستم از فرمت‌های فایلی «ساده» و پذیرفته‌شده برای تضمین قابلیت جابجایی داده‌ها استفاده می‌کند:

• فرمت‌های استاندارد: داده‌ها در فرمت‌هایی مانند SQLite و DuckDB ذخیره می‌شوند.
• خروج آسان: مارکوا در حال برنامه‌ریزی برای افزودن نقاط انتهایی (Endpoints) مربوط به خروجی و ورودی (Export/Import) است تا کاربران راحت‌تر بتوانند داده‌های خود را بردارند و به میزبان دیگری منتقل کنند.
• اکوسیستم آینده: چشم‌انداز این است که تعاونی‌ها و سازمان‌ها برای تبدیل شدن به متولیان مورد اعتماد داده‌های کاربران با یکدیگر رقابت کنند و جایگزین‌هایی برای میزبانی شخصی ارائه دهند.

چالش داده‌های اجتماعی و collaborative

در حالی که این مدل برای داده‌های شخصی که کاربر به‌طور قطعی «مالک» آن‌هاست به‌خوبی عمل می‌کند، همکاری (Collaboration) تعریف مالکیت را «مبهم‌تر» می‌کند. اگر دو نفر در یک ویرایشگر مشترک مانند گوگل‌داکس روی یک سند همکاری کنند، مشخص نیست که رکورد مربوطه باید در پایگاه‌داده شخصی کدام یک ذخیره شود.

در حال حاضر، ayb به کاربر اجازه می‌دهد پایگاه‌داده خود را با همکاران به اشتراک بگذارد، اما هر پایگاه‌داده همچنان یک مالک واحد دارد. نویسنده پیشنهاد می‌کند که مدل‌های آینده ممکن است شامل مجوزدهی کاربر به اپلیکیشن برای همگام‌سازی دو پایگاه‌داده مجزا برای داده‌های مشترک باشد، اگرچه این موضوع هنوز در سطح یک پروتوتایپ است.

داده‌های اجتماعی نیز چالش مشابهی دارند. نقاط ضعف سازمان‌های بزرگی که مالک داده‌های رسانه‌های اجتماعی و الگوریتم‌های نمایش آن‌ها هستند، به‌خوبی شناخته شده است. پروژه‌های مختلفی برای حل این مشکل تلاش کرده‌اند:

• ActivityPub/Mastodon: از فدراسیون استفاده می‌کند تا به کاربران در انتخاب مکان ذخیره‌سازی داده‌ها حق انتخاب دهد.
• AT Protocol/Bluesky: ذخیره‌سازی را از تجمیع داده‌ها (Aggregation) جدا می‌کند.

با وجود این پیشرفت‌ها، «تجمیع تایم‌لاین» (Timeline Aggregation) همچنان یک گلوگاه است. زیرساخت مورد نیاز برای ردیابی و تجمیع آنچه میلیون‌ها نفر می‌گویند، معمولاً به‌طور پیش‌فرض به سمت مرکزگرایی می‌رود. نویسنده چشم‌اندازی را متصور است که در آن یک اپلیکیشن استاتیک (HTML/CSS/JS)، آپدیت‌های یک شبکه اجتماعی را با تجمیع داده‌ها از تمام ذخیره‌گاه‌های شخصی کاربران، بدون نیاز به یک تجمیع‌کننده مرکزی نمایش دهد.

مسیرهای آینده

هدف آینده این است که اکثریت صفحات ورود به اینترنت با صفحات مجوزدهی پایگاه‌داده جایگزین شوند. مارکوا پیش از این شروع به اعمال این مدل در پروژه‌های شخصی خود کرده است، از جمله ردیابی لیست کارهای روزانه (Todos)، نظارت بر عادت‌ها (Streaks) و مدیریت اشتراک خبرنامه‌ها در یک وبلاگ. توانایی ایجاد یک پایگاه‌داده با یک کلیک، ساخت اپلیکیشن‌هایی را ممکن کرده است که پیش از این به دلیل ریسک ذخیره‌سازی داده‌های حساس در دیتابیس‌های شخص ثالث یا زمان لازم برای مدیریت شخصی، از ساخت آن‌ها اجتناب می‌شد.

برای بسط این ایده، چندین حوزه اکتشافی برنامه‌ریزی شده است:

• مجموعه داده‌های منتخب (Curated Datasets): توسعه ابزارهای همکاری پایه برای روزنامه‌نگاران یا دانشمندانی که روی مجموعه‌های داده مشترک کار می‌کنند.
• یکپارچه‌سازی Local-First: بررسی اینکه چگونه یک پایگاه‌داده ayb که به‌صورت ریموت میزبانی شده است، می‌تواند با یک پایگاه‌داده محلی SQLite یا DuckDB برای عملکرد بهتر و دسترسی آفلاین همگام شود.
• حمایت از توسعه‌دهندگان: شناسایی روش‌هایی برای کمک به سایر توسعه‌دهندگان اپلیکیشن تا نرم‌افزارهایی بسازند که عاملیت کاربر را بر داده‌ها اولویت دهند.

در نهایت، چشم‌انداز این است که از دنیایی که در آن برای دیدن داده‌هایمان اجازه می‌خواهیم، به دنیایی برویم که در آن به اپلیکیشن‌ها اجازه می‌دهیم به ما در مدیریت داده‌هایمان کمک کنند.

گام بعدی شما

• اگر توسعه‌دهنده هستید، کتابخانه ayb.js را بررسی کنید تا ببینید چگونه می‌توانید وابستگی اپلیکیشن خود به دیتابیس مرکزی را حذف کنید.
• برای تجربه مالکیت داده، اپلیکیشن‌های مبتنی بر SQLite و DuckDB را که امکان خروجی کامل داده‌ها را می‌دهند، جایگزین سرویس‌های بسته کنید.
• در مورد مفهوم «میزبانی شخصی» (Self-hosting) مطالعه کنید تا متوجه شوید چگونه می‌توانید کنترل کامل داده‌های حساس خود را به دست بگیرید.

اما چالش واقعی زمانی است که بخواهیم این مدل را در مقیاس میلیون‌ها کاربر پیاده کنیم — در تحلیل ما درباره تضادهای مقیاس‌پذیری در Web3 این موضوع را بررسی کرده‌ایم.