راه‌اندازی سرور Matrix شخصی

افراد سرور Matrix خود را راه‌اندازی می‌کنند تا مانع از آن شوند که یک شرکت گفت‌وگوهایشان را در اختیار داشته باشد، و این بخش دقیقاً همان‌طور که وعده داده شده عمل می‌کند. آنچه بعداً آن‌ها را غافلگیر می‌کند، ماهیت واقعی چیزی است که نصب کرده‌اند: یک هوم‌سرور یک جعبهٔ خصوصی نیست که فقط چت را پشتیبانی کند. این یک گرهٔ تکرار (replication node) در یک شبکهٔ عمومی است، و فدراسیون بسیار بیشتر از آنچه اغلب مدیران تازه‌کار انتظار دارند، شبیه یک پروتکل انتشار عمل می‌کند.

هیچ‌کدام از این‌ها دلیلی برای راه‌اندازی نکردن آن نیست — بلکه دلیلی است برای راه‌اندازی آگاهانهٔ آن. حریم خصوصی‌ای که شما به دست می‌آورید واقعی اما مشخص است: مالکیت داده‌ها به شما منتقل می‌شود، حساب کاربری‌تان را کس دیگری نمی‌تواند ببندد، و مسائل حقوقی به حوزهٔ قضایی‌ای می‌رسد که خودتان انتخاب کرده‌اید، نه حوزه‌ای که یک شرکت انتخاب کرده باشد. حریم خصوصی‌ای که به دست نمی‌آورید نیز به همان اندازه مشخص است، و تقریباً تمام آن در شکاف میان «پیام‌ها رمزگذاری شده‌اند» و «هیچ‌کس نمی‌تواند بفهمد چه کسی با چه کسی صحبت می‌کند» نهفته است. این راهنما هر دو نیمه را پوشش می‌دهد، سپس به جزئیات عملیاتی‌ای می‌پردازد که تعیین می‌کنند آیا سرور یک سال بعد همچنان سالم خواهد بود یا نه.

راه‌اندازی هوم‌سرور شخصی واقعاً چه چیزی را تغییر می‌دهد

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

دو ردیف آخر را با دقت بخوانید، چون همان‌جاست که انتظارها فرو می‌ریزد. اگر هدف شما این است که هیچ‌کس نتواند اصلاً وجود یک سرویس را اثبات کند، Matrix ابزار مناسبی نیست و یک سرویس پیازی (onion service) به گزینهٔ درست نزدیک‌تر است. اگر هدف شما مالکیت، کنترل و حوزهٔ قضایی است، هوم‌سرور ابزاری عالی است و ادامهٔ این راهنما دربارهٔ اجرای درست آن است.

فدراسیون یک پروتکل تکرار است که لباس یک پروتکل چت را پوشیده

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

پیامدهای این موضوع در هر دو جهت جاری است و هیچ‌کدام شهودی نیستند. داده‌ای که کاربران شما تولید می‌کنند — نام نمایشی، آواتار، پیوستن و ترک اتاق، برچسب‌های زمانی، واکنش‌ها — روی هر سروری که عضوی در آن اتاق دارد کپی می‌شود، و صرف‌نظر از اینکه بعداً چه چیزی را روی سرور خودتان حذف کنید، در پایگاه‌دادهٔ آن‌ها باقی می‌ماند. حذف (redaction) یک درخواست به همتایان است، نه یک فرمان. در فدراسیونی از سرورهای مستقل هیچ «حذف پیام برای همه» وجود ندارد، و انتظار داشتن چنین چیزی رایج‌ترین سوءتفاهم دربارهٔ این پروتکل است.

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

آنچه رمزگذاری پوشش می‌دهد، و آنچه آشکار باقی می‌ماند

Matrix محتوای پیام را با Megolm رمزگذاری می‌کند، و در اتاق‌های خصوصی این ویژگی به‌طور پیش‌فرض فعال است. این همان بخشی را محافظت می‌کند که بیشتر برای مردم اهمیت دارد و واقعاً کار می‌کند — سرور شما متن رمزشده‌ای را ذخیره می‌کند که نمی‌تواند آن را بخواند، که وقتی سرور یک سخت‌افزار اجاره‌ای است، یک ویژگی واقعی و مفید است. پاکت اطراف پیام داستان دیگری است، و این شکاف بیشتر از آن چیزی است که بیشتر خلاصه‌ها اعتراف می‌کنند.

خوانش عملی این است: رمزگذاری از چه چیزی محافظت می‌کند، فدراسیون چه کسی، چه زمانی و چه‌قدر مکرر را منتشر می‌کند. برای بیشتر جوامع این معامله کاملاً قابل‌قبول است و همین صداقت نکتهٔ اصلی است. برای مدل تهدیدی که خود گراف اجتماعی بخش حساس آن است، یک پروتکل فدرال‌شده از نظر ساختاری ابزار نادرستی است، و هیچ تنظیمی این را تغییر نمی‌دهد.

Synapse، Dendrite یا Conduit — واقعاً کدام را اجرا کنید

در عمل سه پیاده‌سازی اهمیت دارند، و انتخاب بیشتر یک تصمیم منابع است تا یک تصمیم فلسفی.

• Synapse سرور مرجع است، به زبان پایتون نوشته شده، و تنها گزینه‌ای است که همهٔ ویژگی‌ها از روز اول در آن کار می‌کنند. همچنین گرسنه‌ترین گزینه است: مصرف حافظه با تعداد و اندازهٔ اتاق‌هایی که کاربران شما می‌پیوندند رشد می‌کند، و یک سرور شلوغ در نهایت باید به فرایندهای کارگر تقسیم شود. آن را زمانی انتخاب کنید که به Space‌ها، ابزارهای مدیریت، بریج‌ها و APIهای مدیریتی نیاز دارید که دقیقاً همان‌طور که مستند شده رفتار کنند.
• Dendrite بازنویسی به زبان Go است. به‌طور محسوسی از Synapse سبک‌تر است و برای یک سرور کوچک کاملاً قابل استفاده است، به قیمت کمی عقب‌ماندگی در برخی ویژگی‌ها. گزینهٔ میانی معقولی است وقتی Synapse برای تعداد افرادی که واقعاً دارید سنگین به نظر می‌رسد.
• Conduit و فورک فعالانه توسعه‌یافته‌اش conduwuit به زبان Rust نوشته شده‌اند و به‌صورت یک باینری تکی با پایگاه‌دادهٔ توکار عرضه می‌شوند. آن‌ها یک سرور خانوادگی یا یک جامعهٔ کوچک را روی کوچک‌ترین پلنی که می‌فروشیم بدون شکایت اجرا می‌کنند. هزینهٔ این کار یک اکوسیستم کوچک‌تر است: برخی ابزارهای مدیریتی و چند بریج فرض را بر Synapse می‌گذارند.

برای یک سرور اول با تعداد کمی کاربر، نرم‌افزارهای خانوادهٔ Conduit روی یک VPS کوچک کم‌دردسرترین مسیر به چیزی است که کار می‌کند و ارزان می‌ماند. برای هر چیزی که انتظار رشد آن را دارید — یک جامعهٔ عمومی، یک شرکت، پروژه‌ای با بریج — از Synapse شروع کنید و از مهاجرت بعدی صرف‌نظر کنید، چون جابه‌جایی بین پیاده‌سازی‌ها بعداً یک کار خروجی‌گرفتن و بازسازی است، نه یک تغییر تنظیمات.

تنظیم delegation که همه آن را اشتباه انجام می‌دهند

Matrix نامی را که در شناسه‌های کاربری شما ظاهر می‌شود از ماشینی که ترافیک را سرویس می‌دهد جدا می‌کند، و اشتباه گرفتن این دو رایج‌ترین خطای دائمی در خوداستقراری است. server_name شما همان دامنه‌ای است که بعد از دونقطه در هر شناسهٔ کاربری روی سرورتان ظاهر می‌شود. به محض امضا شدن اولین رویداد، این نام بخشی از هویت شما در فدراسیون می‌شود و پس از آن قابل تغییر نیست مگر با رها کردن هر حساب و هر اتاق روی آن ماشین.

تنظیمی که تقریباً همیشه می‌خواهید این است: server_name دامنهٔ اصلی شماست، در حالی که نرم‌افزار روی یک زیردامنه اجرا می‌شود. این دو را با delegation به هم متصل می‌کنید، به یکی از دو روش. روش ساده یک فایل JSON استاتیک است که در /.well-known/matrix/server روی دامنهٔ اصلی سرو می‌شود و میزبان و پورت واقعی را نام می‌برد. روش جایگزین یک رکورد DNS، _matrix._tcp، است که به همان مکان اشاره می‌کند. فایل سمت کلاینت را نیز در /.well-known/matrix/client سرو کنید، تا برنامه‌ها هوم‌سرور را فقط از روی یک آدرس پیدا کنند.

اندازه‌گیری صادقانهٔ منابع

Matrix در عملکرد عادی محدود به CPU نیست؛ محدود به حافظه و رفتار پایگاه‌داده است. ارقام منتشرشده برای Synapse یک کف مفید هستند: تقریباً 2 گیگابایت رم برای شروع، حدود 4 گیگابایت وقتی ده تا پنجاه کاربر فعال دارید، و 8 گیگابایت یا بیشتر فراتر از صد کاربر. سرورهای خانوادهٔ Conduit بسیار پایین‌تر از این‌ها قرار می‌گیرند. آنچه این ارقام از قلم می‌اندازند این است که مصرف به اتاق‌های پیوسته‌شده وابسته است، نه افراد ثبت‌شده — پنج کاربر در صد اتاق عمومی بزرگ بسیار بیشتر از پنجاه کاربر در چند اتاق خصوصی کوچک هزینه دارد.

از این‌جا دو قاعدهٔ عملی نتیجه می‌شود. پایگاه‌داده را روی حافظهٔ سریع قرار دهید و جا برای رشد آن بگذارید، چون الگوی نوشتن کوچک و پیوسته است، نه ناگهانی. و برای تعداد کاربران امروز اندازه‌گیری نکنید: برای اتاق‌هایی اندازه‌گیری کنید که آن کاربران در ماه اول به آن‌ها می‌پیوندند، که معمولاً همان‌جاست که غافلگیری رخ می‌دهد. پلن ورودی ما یک سرور کوچک Conduit یا Dendrite را به‌راحتی نگه می‌دارد، در حالی که یک نمونهٔ Synapse برای یک جامعهٔ واقعی باید روی یک پلن میان‌رده یا بالاتر باشد — صفحهٔ میزبانی چت سطوحی را که در برابر هر یک از این حالت‌ها توصیه می‌کنیم فهرست می‌کند.

آپ‌تایم این‌جا بیشتر از بیشتر بارهای کاری اهمیت دارد، چون یک سرور چت که از دسترس خارج است تنها در دسترس نبودن نیست — بلکه به‌آرامی رویدادهایی را از دست می‌دهد که همتاها مدتی دوباره تلاش می‌کنند و سپس ارسال آن‌ها را متوقف می‌کنند. فدراسیون در برابر چند دقیقه اغماض دارد و در برابر چند روز بی‌رحم است.

مخزن رسانه یک بمب دیسکی آهسته است

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

از همان روز اول برای رسانهٔ راه دور یک سیاست نگهداری تعیین کنید، نه بعد از اولین قطعی. Synapse تنظیمات نگهداری را در homeserver.yaml در اختیار می‌گذارد، به‌همراه نقاط پایانی مدیریتی برای پاک کردن تاریخچه و فایل‌های ذخیره‌شدهٔ قدیمی؛ synapse-compress-state مقدار شگفت‌آوری از جدول‌های وضعیت روی یک سرور قدیمی‌تر بازپس می‌گیرد. هم پایگاه‌داده و هم مسیر رسانه را زیر نظر داشته باشید، و به‌جای هشدار روی از کار افتادن سرویس، روی فضای آزاد هشدار تنظیم کنید — علامت دوم روزها بعد از اولی می‌رسد.

یک تنظیم شایستهٔ یک تصمیم آگاهانه است، نه یک پیش‌فرض. پیش‌نمایش لینک‌ها باعث می‌شود سرور شما هر لینکی که در یک اتاق ارسال می‌شود را واکشی کند، به این معنا که آدرس IP سرور شما همان لحظه‌ای که کسی یک لینک را جای‌گذاری می‌کند، یک درخواست خروجی به یک شخص ثالث می‌فرستد — از جمله لینکی که مشخصاً برای دیدن اینکه چه کسی طعمه را می‌گیرد انتخاب شده باشد. اگر هوم‌سرور شما پشت یک لایهٔ محافظ قرار دارد و آدرس واقعی آن اهمیت دارد، این را با دقت بسنجید؛ راهنمای ما دربارهٔ پنهان کردن آدرس سرور مبدأ همین دسته از نشت اطلاعات را با جزئیات بیشتری پوشش می‌دهد.

ثبت‌نام، اسپم و شهرتی که به ارث می‌برید

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

پیش‌فرض‌های قابل‌دفاع ساده هستند. enable_registration را برای یک سرور خصوصی خاموش نگه دارید و خودتان حساب‌ها را بسازید. اگر می‌خواهید در باز بماند، آن را دروازه‌بانی کنید: registration_requires_token ثبت‌نام را بدون هیچ سرویس شخص‌ثالثی به یک سیستم دعوتی تبدیل می‌کند، و یک کپچا در برابر انتهای خام مشکل کمک می‌کند. برای اتاق‌هایی که مدیریت می‌کنید، بات‌های مدیریتی از خانوادهٔ Mjolnir و Draupnir به شما اجازه می‌دهند فهرست‌های مسدودسازی و ACLهای اتاق را در کل یک جامعه به‌جای یک اتاق در هر بار اعمال کنید.

دانستنش در جهت مقابل هم ارزش دارد: محدودهٔ آدرس‌های ما روی فهرست‌های مسدودسازی ACL مربوط به Matrix که میان هوم‌سرورها دست‌به‌دست می‌شود حمل نمی‌شود، بنابراین یک سرور تازه با شهرتی پاک شروع می‌کند. آنچه بعداً بر سر آن شهرت می‌آید را نحوهٔ اداره کردن ثبت‌نام تعیین می‌کند، نه محل قرارگیری ماشین.

بریج‌ها، و صورت‌حساب متادیتایی که همراه می‌آورند

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

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

زنده نگه‌داشتن آن: کلیدها، پشتیبان‌گیری و به‌روزرسانی‌ها

یک سرور Matrix یک فایل دارد که از دست دادن آن به شکلی جبران‌ناپذیر است که هیچ ربطی به حجم داده ندارد. کلید امضا — signing.key در Synapse — همان چیزی است که به سرور شما اجازه می‌دهد ثابت کند رویدادهایی که ادعا می‌کنند از دامنهٔ شما آمده‌اند واقعاً چنین‌اند. آن را از دست بدهید و دیگر نمی‌توانید به‌طور قابل‌باور سرور خودتان باشید؛ همتاها رویدادهایی را که یک غریبه با نام شما امضا کرده رد می‌کنند. آن را جدا از هر چیز دیگر پشتیبان بگیرید، و آن نسخه را خارج از ماشین نگه دارید.

به‌روزرسانی‌ها معمولی هستند اما اختیاری نیستند. نسخه‌های جدید هوم‌سرور مهاجرت‌های اسکیمای پایگاه‌داده به همراه دارند، و رد شدن از چندین نسخه یک به‌روزرسانی پنج‌دقیقه‌ای را به یک بعدازظهر کامل تبدیل می‌کند. پیش از پرش، یادداشت‌های انتشار را بخوانید، به‌اندازه‌ای منظم به‌روزرسانی کنید که هر گام کوچک بماند، و بهداشت پایهٔ میزبان را از چک‌لیست سخت‌سازی ساعت اول انجام دهید — یک سرور چت یک سرویس رو-به-اینترنت با عمر طولانی و یک پایگاه‌داده متصل به آن است، و سزاوار همان رفتار است.

محل قرارگیری سرور همچنان نتیجه را تعیین می‌کند

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

این همان استدلال عملی برای انتخاب آگاهانهٔ یک مکان است، نه صرفاً بر اساس تأخیر شبکه. ما در هفت حوزهٔ قضایی سرویس ارائه می‌دهیم، و مصالحه‌های میان آن‌ها در راهنمای حوزهٔ قضایی و در صفحهٔ مکان‌ها شرح داده شده است. نیمهٔ دیگر همین پرسش این است که ارائه‌دهنده شما را چه کسی می‌شناسد: حسابی که هیچ هویتی به آن متصل نیست نمی‌تواند مدارک هویتی‌ای را ارائه دهد که هرگز جمع‌آوری نکرده، و این همان دلیل سرراست این است که میزبانی بدون KYC و ارتباطات خوداستقرارشده مدام در یک گفت‌وگو ظاهر می‌شوند. هیچ‌کدام دفاعی در برابر دادگاهی که از پیش نام شما را دارد نیست، و راهنمای OpSec ما صریح است دربارهٔ اینکه آن خط دقیقاً کجاست.

نسخهٔ کوتاه

اگر می‌خواهید فقط شش چیز از این صفحه با خود ببرید، این‌ها را ببرید:

• server_name را پیش از نصب هر چیزی انتخاب کنید — این تنها تصمیمی است که هرگز نمی‌توانید آن را تجدیدنظر کنید.
• با /.well-known/matrix/server یا یک رکورد SRV delegate کنید، و TLS معتبر را روی هر دو نام نگه دارید.
• برای اتاق‌هایی که کاربران شما به آن‌ها می‌پیوندند اندازه‌گیری کنید، نه برای تعداد کاربرانی که دارید.
• از همان روز اول نگهداری رسانه را تنظیم کنید، و دربارهٔ پیش‌نمایش لینک‌ها آگاهانه تصمیم بگیرید، نه اینکه پیش‌فرض را به ارث ببرید.
• ثبت‌نام را بسته یا دارای توکن نگه دارید؛ بازگرداندن شهرت سوخته‌شدهٔ یک دامنه پرهزینه است.
• signing.key را جداگانه پشتیبان بگیرید، و هرگز پایگاه‌داده را پشت‌سر همتایان خود عقب نبرید.

این کارها را انجام دهید و سرور شما بی‌دردسر خواهد بود، که دقیقاً همان چیزی است که یک سرور چت باید باشد. آنچه در ازای آن به دست می‌آورید ارزش صریح بودن دارد: نه نامرئی بودن، و نه پروتکلی که پنهان کند چه کسی با چه کسی صحبت می‌کند، بلکه گفت‌وگوهایی که محتوایشان مال شماست، حسابی که هیچ‌کس دیگری نمی‌تواند ببندد، و ماشینی که زیر نظامی حقوقی نشسته که خودتان آگاهانه انتخاب کرده‌اید. هوم‌سرور را جایی بگذارید که خودتان انتخاب کرده‌اید، و بگذارید فدراسیون به سراغش بیاید.