खुद का Matrix Server Self-Host करना

लोग अपनी बातचीत किसी कंपनी के हाथ में जाने से रोकने के लिए Matrix को self-host करते हैं, और यह हिस्सा ठीक वैसे ही काम करता है जैसा दावा किया जाता है। बाद में जो बात उन्हें चौंकाती है वह है उस चीज़ की असली बनावट जो उन्होंने इंस्टॉल की: एक homeserver कोई निजी डिब्बा नहीं है जो संयोग से चैट भी कर लेता है। यह एक सार्वजनिक नेटवर्क में एक replication node है, और federation ज़्यादातर नए एडमिन की उम्मीद से कहीं अधिक एक publishing protocol की तरह बर्ताव करता है।

इसमें से कुछ भी इसे चलाने के ख़िलाफ़ तर्क नहीं है — यह इसे सोच-समझकर चलाने के पक्ष में तर्क है। जो प्राइवेसी आपको मिलती है वह असली है पर सीमित है: custody अब आपके पास आ जाती है, कोई और आपका अकाउंट बंद नहीं कर सकता, और कानूनी सवाल उस jurisdiction में पहुँचते हैं जो आपने चुनी है, न कि जो किसी कंपनी ने चुनी थी। जो प्राइवेसी आपको नहीं मिलती वह भी उतनी ही सीमित है, और उसका लगभग पूरा हिस्सा "मैसेज एन्क्रिप्टेड हैं" और "कोई नहीं बता सकता कि कौन किससे बात कर रहा है" के बीच के फ़र्क़ में छिपा है। यह गाइड दोनों पहलू कवर करती है, फिर वे ऑपरेशनल फ़ैसले जो तय करते हैं कि सर्वर एक साल बाद भी स्वस्थ रहेगा या नहीं।

अपना खुद का homeserver चलाने से असल में क्या बदलता है

सबसे पहले खतरों को अलग-अलग करके देखिए, क्योंकि एक homeserver इनमें से कुछ का पूरी तरह जवाब देता है, कुछ का आंशिक रूप से, और कुछ का बिल्कुल नहीं। नीचे दी गई तालिका इस पूरे प्रस्ताव का ईमानदार संस्करण है, और इसे हार्डवेयर चुनने से पहले पढ़ना बेहतर है, बाद में नहीं।

आख़िरी दो पंक्तियों को ध्यान से पढ़िए, क्योंकि यहीं पर उम्मीदें टूटती हैं। अगर आपका मक़सद यह है कि किसी सेवा का अस्तित्व ही कोई साबित न कर पाए, तो Matrix ग़लत औज़ार है और एक onion service उसके ज़्यादा क़रीब है। अगर आपका मक़सद custody, नियंत्रण और jurisdiction है, तो एक homeserver एक बेहतरीन औज़ार है, और इस गाइड का बाक़ी हिस्सा उसे अच्छी तरह चलाने के बारे में है।

Federation एक replication protocol है जिसने चैट प्रोटोकॉल का चोला पहन रखा है

यही वह तंत्र है जो ज़्यादातर हैरानियों की वजह बताता है। जब आपका कोई यूज़र कहीं और होस्ट किए गए रूम में शामिल होता है, तो आपका सर्वर मेल क्लाइंट की तरह डिमांड पर मैसेज नहीं मंगाता। वह एक distributed event graph में एक participant के रूप में उस रूम में शामिल होता है, फिर रूम के events, उसकी membership, और आगे के events को वैलिडेट करने लायक़ पर्याप्त state history की एक कॉपी खींचकर उसे स्टोर कर लेता है। उस पल से आपकी मशीन एक replica रखती है, और हर दूसरा भाग लेने वाला सर्वर भी एक रखता है।

इसके नतीजे दोनों दिशाओं में जाते हैं, और कोई भी सहज-बोध वाला नहीं है। आपके यूज़र जो डेटा बनाते हैं — display name, avatar, joins और leaves, timestamps, reactions — वह उस रूम के हर सदस्य वाले सर्वर पर कॉपी हो जाता है, और आप बाद में अपने यहाँ से जो भी डिलीट करें, वह उनके डेटाबेस में बना रहता है। Redaction साथी सर्वरों को भेजी गई एक गुज़ारिश है, कोई हुक्म नहीं। स्वतंत्र रूप से चलाए जा रहे सर्वरों के federation में कोई "unsend" नहीं होता, और इसकी उम्मीद रखना इस प्रोटोकॉल को लेकर सबसे आम ग़लतफ़हमी है।

दूसरी दिशा में, बड़े पब्लिक रूम में शामिल होने का मतलब है दूसरे लोगों की history को अपनी डिस्क पर इम्पोर्ट करना। यही वजह है कि तीन यूज़र वाला बिल्कुल नया homeserver भी दसियों गीगाबाइट का डेटाबेस ढो सकता है: इसलिए नहीं कि आपके तीन यूज़र ने बहुत कुछ लिखा, बल्कि इसलिए कि वे पचास हज़ार सदस्यों और सालों की state वाले रूम में शामिल हो गए। सोच-समझकर रूम चुनना जितना एक प्राइवेसी का फ़ैसला है, उतना ही एक capacity का फ़ैसला भी है।

Encryption क्या कवर करता है, और क्या साफ़ रह जाता है

Matrix मैसेज की सामग्री को Megolm से एन्क्रिप्ट करता है, और प्राइवेट रूम में यह डिफ़ॉल्ट रूप से ऑन रहता है। यह उस हिस्से की हिफ़ाज़त करता है जिसकी लोगों को सबसे ज़्यादा फ़िक्र होती है, और यह सचमुच काम करता है — आपका सर्वर सिर्फ़ ciphertext स्टोर करता है जिसे वह पढ़ नहीं सकता, जो एक असली और काम की खूबी है जब सर्वर किराए के हार्डवेयर पर हो। मैसेज के चारों तरफ़ का लिफ़ाफ़ा एक अलग ही कहानी है, और यह फ़र्क़ ज़्यादातर सारांशों के मुक़ाबले कहीं बड़ा है।

व्यावहारिक मतलब यह है: encryption क्या की हिफ़ाज़त करता है, federation कौन, कब और कितनी बार को उजागर करता है। ज़्यादातर समुदायों के लिए यह सौदा पूरी तरह स्वीकार्य है, और यही ईमानदारी असल मुद्दा है। जिस threat model में सोशल ग्राफ़ ख़ुद ही संवेदनशील हिस्सा है, उसके लिए एक federated प्रोटोकॉल संरचनात्मक रूप से ग़लत शक्ल है, और कोई भी configuration फ़्लैग इसे नहीं बदलता।

Synapse, Dendrite या Conduit — असल में क्या चलाएँ

व्यवहार में तीन implementations मायने रखते हैं, और यह चुनाव ज़्यादातर एक resource का फ़ैसला है, न कि कोई दार्शनिक फ़ैसला।

• Synapse reference सर्वर है, Python में लिखा गया, और अकेला ऐसा जिसमें हर फ़ीचर पहले ही दिन से काम करता है। यह सबसे ज़्यादा भूखा भी है: आपके यूज़र जिन रूम में शामिल होते हैं उनकी संख्या और साइज़ के साथ memory बढ़ती जाती है, और व्यस्त सर्वर को आख़िरकार worker processes में बाँटना पड़ता है। इसे चुनिए जब आपको spaces, moderation tooling, bridges और admin APIs को ठीक वैसे ही चलते देखना हो जैसा डॉक्युमेंटेशन में लिखा है।
• Dendrite इसका Go में लिखा गया संस्करण है। Synapse से साफ़ तौर पर हल्का और एक छोटे सर्वर के लिए पूरी तरह उपयोगी, बस कुछ फ़ीचर देर से आते हैं। जब Synapse आपके असली यूज़र्स की संख्या के लिए भारी लगे, तो यह एक ठीक-ठाक बीच का विकल्प है।
• Conduit और इसका सक्रिय रूप से विकसित हो रहा fork conduwuit Rust में लिखे गए हैं और एक embedded database के साथ एक ही binary के रूप में मिलते हैं। ये हमारे सबसे छोटे प्लान पर भी बिना शिकायत एक परिवार या छोटे समुदाय का सर्वर चला लेते हैं। बदले में इनका ecosystem छोटा है: कुछ admin tooling और चंद bridges Synapse को मानकर बनाए गए हैं।

मुट्ठी भर यूज़र वाले पहले सर्वर के लिए, एक छोटे VPS पर Conduit-परिवार का सॉफ़्टवेयर काम करने वाली और सस्ती चीज़ पाने का सबसे कम तकलीफ़देह रास्ता है। जिसके बढ़ने की उम्मीद है — एक पब्लिक समुदाय, कोई कंपनी, bridges वाला कोई प्रोजेक्ट — उसके लिए Synapse से शुरू कीजिए और माइग्रेशन को टालिए, क्योंकि बाद में implementations के बीच जाना कोई config बदलाव नहीं बल्कि export-and-rebuild की पूरी कवायद है।

वह delegation सेटअप जिसे सब ग़लत करते हैं

Matrix आपके user ID में मौजूद नाम को उस मशीन से अलग रखता है जो ट्रैफ़िक परोसती है, और इसे उल्टा समझ लेना self-hosting में सबसे आम और स्थायी ग़लती है। आपका server_name वह डोमेन है जो आपके सर्वर पर हर user ID में कोलन के बाद आता है। पहला event साइन होते ही यह federation में आपकी पहचान का हिस्सा बन जाता है, और मशीन के हर अकाउंट और रूम को छोड़े बिना इसे बाद में बदला नहीं जा सकता।

वह सेटअप जो आपको लगभग हमेशा चाहिए होता है: server_name आपका bare डोमेन होता है, जबकि सॉफ़्टवेयर एक सबडोमेन पर चलता है। आप इन दोनों को delegation के ज़रिए जोड़ते हैं, दो तरीक़ों में से किसी एक से। आसान तरीक़ा है bare डोमेन पर /.well-known/matrix/server पर परोसी गई एक स्टैटिक JSON फ़ाइल, जो असली host और port बताती है। दूसरा विकल्प है एक DNS रिकॉर्ड, _matrix._tcp, जो उसी जगह की ओर इशारा करता है। client-side वाली फ़ाइल भी /.well-known/matrix/client पर परोसिए, ताकि ऐप्स सिर्फ़ एक एड्रेस से homeserver ढूँढ सकें।

इसे ईमानदारी से sizing करना

सामान्य ऑपरेशन में Matrix CPU-bound नहीं है; यह memory और डेटाबेस के बर्ताव से बंधा है। Synapse के लिए प्रकाशित आँकड़े एक काम के न्यूनतम स्तर हैं: शुरुआत में लगभग 2 GB RAM, दस से पचास एक्टिव यूज़र होने पर लगभग 4 GB, और सौ से ज़्यादा होने पर 8 GB या इससे अधिक। Conduit-परिवार के सर्वर इससे कहीं नीचे रहते हैं। ये आँकड़े जो नहीं बताते वह यह है कि खपत जॉइन किए गए रूम के हिसाब से बढ़ती है, न कि रजिस्टर किए गए लोगों के हिसाब से — सौ बड़े पब्लिक रूम में पाँच यूज़र, मुट्ठी भर प्राइवेट रूम में पचास यूज़र से कहीं ज़्यादा महँगे पड़ते हैं।

इससे दो व्यावहारिक नियम निकलते हैं। डेटाबेस को तेज़ स्टोरेज पर रखिए और उसे बढ़ने की जगह दीजिए, क्योंकि write पैटर्न फूटकर नहीं बल्कि छोटा और लगातार होता है। और आज की यूज़र संख्या के हिसाब से sizing मत कीजिए: उन रूम के हिसाब से sizing कीजिए जिनमें ये यूज़र पहले महीने में शामिल होंगे — हैरानी अक्सर वहीं छिपी होती है। हमारा एंट्री प्लान एक छोटे Conduit या Dendrite सर्वर को आराम से संभाल लेता है, जबकि किसी असली समुदाय के लिए Synapse इंस्टेंस को mid-tier प्लान या उससे ऊपर होना चाहिए — chat hosting पेज पर इन दोनों तरह के मामलों के लिए हमारी सुझाई हुई टीयर सूची है।

यहाँ uptime ज़्यादातर workloads के मुक़ाबले कहीं ज़्यादा मायने रखता है, क्योंकि जो चैट सर्वर डाउन है वह सिर्फ़ उपलब्ध नहीं है — वह चुपचाप वे events भी खो रहा है जिन्हें साथी सर्वर कुछ देर कोशिश करने के बाद देना बंद कर देंगे। Federation मिनटों को माफ़ कर देता है, दिनों को नहीं।

Media store एक धीमी रफ़्तार वाला disk बम है

जिस भी रूम में आपके यूज़र मौजूद हैं, उससे गुज़रने वाली हर इमेज, वीडियो और फ़ाइल आपकी डिस्क पर कैश हो सकती है, यहाँ तक कि वह remote media भी जिसे आपके अपने यूज़र ने कभी खोला ही नहीं। Synapse की डिफ़ॉल्ट retention उसे अनिश्चित काल तक रखती है। नतीजा अनुमानित है और फिर भी लोगों को चौंका देता है: एक ऐसा सर्वर जिसका डेटाबेस स्थिर है पर जिसकी media डायरेक्टरी चुपचाप तब तक बढ़ती रहती है जब तक वॉल्यूम भर न जाए, और उस वक़्त लक्षण "डिस्क भर गई" नहीं बल्कि "सर्वर अजीब बर्ताव कर रहा है" होता है।

पहले दिन ही remote media के लिए एक retention policy तय कीजिए, न कि पहली outage के बाद। Synapse homeserver.yaml में retention सेटिंग्स देता है, साथ ही पुरानी history और कैश्ड फ़ाइलें हटाने के लिए admin endpoints भी; synapse-compress-state किसी पुराने सर्वर की state tables से हैरान कर देने वाली मात्रा वापस पा लेता है। डेटाबेस और media पाथ दोनों पर नज़र रखिए, और service के डाउन होने पर नहीं बल्कि खाली जगह पर अलर्ट लगाइए — दूसरा लक्षण पहले के कई दिन बाद आता है।

एक सेटिंग को डिफ़ॉल्ट पर नहीं बल्कि सोच-समझकर तय किए जाने की ज़रूरत है। URL previews आपके सर्वर से रूम में पोस्ट किया गया कोई भी लिंक फ़ेच करवाते हैं, जिसका मतलब है कि किसी के लिंक पेस्ट करते ही आपके सर्वर का IP एड्रेस किसी तीसरे पक्ष को एक आउटबाउंड रिक्वेस्ट भेजता है — यहाँ तक कि ऐसा लिंक भी जो सिर्फ़ यह देखने के लिए चुना गया हो कि कौन चारा लेता है। अगर आपका homeserver किसी front के पीछे बैठा है और उसका असली एड्रेस मायने रखता है, तो इसे ध्यान से तौलिए; origin एड्रेस छुपाने पर हमारी गाइड इसी तरह के leak को और तफ़सील से कवर करती है।

Registration, spam, और वह प्रतिष्ठा जो आपको विरासत में मिलती है

किसी पब्लिक homeserver पर खुला registration एक न्यौता है, और वह क़िस्म का नहीं जो आप चाहते हैं। Automated signups कुछ ही दिनों में एक छोटे सर्वर को spam का स्रोत बना देते हैं, और इसका असर सिर्फ़ आपके यहाँ तक सीमित नहीं रहता: दूसरे homeserver आपके डोमेन को अपनी access-control lists में जोड़ देते हैं, और एक बार आपका नाम इनमें से पर्याप्त सूचियों में आ जाए, तो आपके असली यूज़र कहीं और के रूम में भाग नहीं ले पाते। जली हुई domain प्रतिष्ठा को सुधारना उसे टालने से कहीं ज़्यादा मुश्क़िल है, बिल्कुल वैसे ही जैसे mail deliverability के साथ होता है।

बचाव लायक़ डिफ़ॉल्ट सीधे हैं। एक प्राइवेट सर्वर के लिए enable_registration बंद रखिए और अकाउंट खुद बाँटिए। अगर आप दरवाज़ा खुला रखना चाहते हैं, तो उस पर गेट लगाइए: registration_requires_token registration को बिना किसी third-party सेवा के एक invite सिस्टम में बदल देता है, और एक captcha समस्या के मोटे हिस्से के ख़िलाफ़ मदद करता है। जिन रूम को आप एडमिनिस्टर करते हैं, उनके लिए Mjolnir और Draupnir परिवार के moderation bots आपको एक बार में एक रूम की बजाय पूरे समुदाय पर ban lists और room ACLs लागू करने देते हैं।

दूसरी दिशा में जानने लायक़ बात: हमारी address रेंज उन Matrix ACL blocklists में शामिल नहीं हैं जो homeserver के बीच घूमती रहती हैं, इसलिए एक नया सर्वर साफ़ प्रतिष्ठा से शुरू होता है। उसके बाद उस प्रतिष्ठा का क्या होता है, यह इस बात से तय होता है कि आप registration कैसे चलाते हैं, न कि मशीन कहाँ है इससे।

Bridges, और उनके साथ आने वाला metadata का बिल

Bridges वह ईमानदार वजह हैं जिसकी वजह से बहुत से लोग Matrix पर टिके रहते हैं: दूसरे नेटवर्क पर मौजूद रूम के लिए एक ही क्लाइंट। ये आपके सर्वर की सुरक्षा स्थिति को भी एक ऐसे तरीक़े से बदल देते हैं जिसे नज़रअंदाज़ करना आसान है। एक bridge रिमोट अकाउंट के लिए credentials रखता है, और जहाँ दो प्रोटोकॉल मिलते हैं उस सीमा पर, उसे मैसेज को ऐसे रूप में हैंडल करना ही पड़ता है जिसे वह बदल सके — जिसका मतलब है कि bridge प्रोसेस उस ट्रैफ़िक का plaintext देखता है जो अपने दोनों तरफ़ end-to-end एन्क्रिप्टेड है।

यह bridges से बचने की वजह नहीं है। यह bridge host को संवेदनशील इंफ़्रास्ट्रक्चर की तरह बरतने की वजह है: यह वह मशीन है जो, अगर compromise हो जाए, तो उन अकाउंट को उजागर कर देती है जिनकी वह नुमाइंदगी करती है। हर bridge किसी छोटे सर्वर के memory footprint को लगभग दोगुना कर देता है, इसलिए capacity की योजना उसी हिसाब से बनाइए, और यह कहाँ चलता है इस पर उतना ही सोचिए जितना आपने ख़ुद homeserver के लिए सोचा था — हमारी jurisdiction गाइड का तर्क उस बॉक्स पर और भी ज़्यादा ज़ोर से लागू होता है जो एक साथ कई नेटवर्क के credentials रखता है।

इसे ज़िंदा रखना: keys, backups और upgrades

एक Matrix सर्वर में एक ऐसी फ़ाइल होती है जिसका खोना डेटा की मात्रा से बिल्कुल अलग तरह से अपूरणीय है। Signing key — Synapse में signing.key — इसी से आपका सर्वर साबित करता है कि जो events आपके डोमेन से आने का दावा करते हैं वे सच में वहीं से आए हैं। इसे खो दीजिए तो आप विश्वसनीय ढंग से अपना सर्वर नहीं रह जाते; साथी सर्वर उन events को ख़ारिज कर देंगे जो आपका नाम रखने वाले किसी अजनबी ने साइन किए हों। इसे बाक़ी सब चीज़ों से अलग बैकअप कीजिए, और उस कॉपी को मशीन से दूर रखिए।

Upgrades आम बात हैं पर वैकल्पिक नहीं। Homeserver रिलीज़ schema migrations लेकर आती हैं, और कई वर्ज़न छोड़ देने से पाँच मिनट का upgrade एक पूरी दोपहर का काम बन जाता है। छलांग लगाने से पहले release notes पढ़िए, इतनी नियमितता से upgrade कीजिए कि हर क़दम छोटा रहे, और पहले घंटे की hardening checklist वाली बुनियादी host हाइजीन कीजिए — एक चैट सर्वर एक डेटाबेस से जुड़ी लंबे समय तक चलने वाली इंटरनेट-फ़ेसिंग सेवा है, और इसके साथ वैसा ही बर्ताव होना चाहिए।

सर्वर कहाँ रहता है, यही अब भी नतीजा तय करता है

ऊपर लिखा सब कुछ configuration है। जिस हिस्से को configuration छू नहीं सकता वह यह है कि आपके यूज़र के बारे में अनुरोध किस कानूनी व्यवस्था तक पहुँचता है, और एक कम्युनिकेशन सर्वर के लिए यह सवाल किसी वेबसाइट के मुक़ाबले कहीं ज़्यादा वज़न रखता है। एक homeserver membership records, timestamps और social-graph डेटा को साफ़ रखता है, भले ही मैसेज बॉडी एन्क्रिप्टेड हो — इसलिए जो jurisdiction इसे होस्ट करती है, वही यह भी तय करती है कि उस रिकॉर्ड तक पहुँच किसे मिलेगी।

यही वजह है कि सिर्फ़ latency से नहीं बल्कि जान-बूझकर लोकेशन चुननी चाहिए। हम सात जगह चलाते हैं, और उनके बीच के trade-offs हमारी jurisdiction गाइड और locations पेज पर बताए गए हैं। इसी सवाल का दूसरा आधा हिस्सा यह है कि प्रोवाइडर आपको कौन जानता है: जिस अकाउंट से कोई पहचान जुड़ी ही नहीं, वह ऐसे पहचान दस्तावेज़ पेश नहीं कर सकता जो उसने कभी इकट्ठे ही नहीं किए — यही सीधी वजह है कि no-KYC hosting और self-hosted communications बार-बार एक ही बातचीत में साथ आते हैं। इनमें से कोई भी उस अदालत के सामने बचाव नहीं है जिसके पास आपका नाम पहले से है, और हमारी OpSec गाइड इस बारे में साफ़-साफ़ बताती है कि यह रेखा कहाँ है।

संक्षिप्त संस्करण

अगर आप इस पेज से सिर्फ़ छह बातें लेकर जाना चाहते हैं, तो ये लीजिए:

• कुछ भी इंस्टॉल करने से पहले server_name चुन लीजिए — यह वह इकलौता फ़ैसला है जिसे आप कभी बदल नहीं सकते।
• /.well-known/matrix/server या किसी SRV रिकॉर्ड से delegate कीजिए, और दोनों नामों पर वैध TLS बनाए रखिए।
• उन रूम के हिसाब से sizing कीजिए जिनमें आपके यूज़र शामिल होंगे, न कि इस हिसाब से कि आपके पास कितने यूज़र हैं।
• पहले दिन ही media retention तय कीजिए, और URL previews के बारे में डिफ़ॉल्ट को यूँ ही अपनाने की बजाय ख़ुद फ़ैसला लीजिए।
• Registration बंद रखिए या token से गेट कीजिए; जली हुई domain प्रतिष्ठा को वापस पाना महँगा पड़ता है।
• signing.key का बैकअप अलग से लीजिए, और डेटाबेस को कभी भी अपने साथी सर्वरों से पीछे मत ले जाइए।

यह सब कीजिए तो सर्वर बेहद सामान्य रहेगा, और एक चैट सर्वर को यही होना चाहिए। बदले में आपको जो मिलता है, उसे साफ़ नज़र से देखने लायक़ है: न कि अदृश्यता, और न ही ऐसा प्रोटोकॉल जो छुपा दे कि कौन किससे बात कर रहा है, बल्कि ऐसी बातचीत जिसकी सामग्री आपकी अपनी है, ऐसा अकाउंट जिसे कोई और बंद नहीं कर सकता, और एक मशीन जो उस कानूनी व्यवस्था के नीचे बैठी है जो आपने ख़ुद सोच-समझकर चुनी है। homeserver को वहाँ रखिए जहाँ आपने चुना, और federation को उस तक आने दीजिए।