$16.90/mo के Ravelin पर Synapse + Postgres + Element। आपका होमसर्वर रिले और फ़ेडरेट करता है; यह अपना ही E2E ट्रैफ़िक नहीं पढ़ सकता; नॉर्डिक न्यायक्षेत्र का मतलब है कि कोई भी उससे विनम्रता से यह कोशिश शुरू करने को नहीं कह सकता।
$16.90/mo का Ravelin ~100 रूम वाले, अच्छी तरह फ़ेडरेटेड Synapse को आराम से संभाल लेता है — Postgres, Redis, Synapse वर्कर, रूम स्टेट कैश, सब एक ही मशीन पर।
एंड-टू-एंड एन्क्रिप्शन संरचनात्मक है — होमसर्वर ऐसा ciphertext रिले करता है जिसे वह डिक्रिप्ट नहीं कर सकता। बिना KYC एडमिन साइनअप का मतलब है कि ऑपरेटर के पीछे भी कोई कागज़ी निशान नहीं रहता।
नॉर्डिक न्यायक्षेत्र + डिज़ाइन से ही नो-लॉग्स + अनमीटर्ड अपलिंक। सक्रिय रूम सेट का फ़ेडरेशन ट्रैफ़िक वाकई भारी होता है; यहाँ उसका अलग से कोई बिल नहीं आता।
ज़्यादातर लोगों के लिए matrix.org से जुड़ना ही सही जवाब है। अपना होमसर्वर चलाना तब सही जवाब है जब आपका हैंडल, आपकी रूम सदस्यता और आपके संदेशों का मेटाडेटा किसी और के प्रशासनिक panel पर नहीं रहना चाहिए। प्रोटोकॉल फ़ेडरेटेड है, एन्क्रिप्शन एंड-टू-एंड है; जो कड़ी छूटी है वह है "जिस मशीन से मेरा खाता जुड़ा है, उस पर नियंत्रण किसका है", और इसका जवाब ख़तरे के मॉडल को बुनियादी तौर पर बदल देता है।
Matrix का फ़ेडरेशन मॉडल उदार है: कोई भी होमसर्वर किसी भी दूसरे होमसर्वर से बात कर सकता है, रूम कई सर्वरों में फैले होते हैं, एन्क्रिप्शन उपयोगकर्ता के साथ चलता है, और भाग लेने के लिए किसी केंद्रीय डायरेक्टरी की ज़रूरत नहीं होती। एक बार आपका होमसर्वर चल पड़े और फ़ेडरेशन टेस्टर से सत्यापित हो जाए, तो आपका खाता नेटवर्क का प्रथम-श्रेणी नागरिक है — बिल्कुल @user:matrix.org या @user:mozilla.org की तरह, बस आपके अपने डोमेन पर।
Synapse की परिचालन कहानी जानी-पहचानी है: upstream में Docker Compose टेम्पलेट, स्टेट के लिए Postgres, वर्कर पूल के लिए Redis, और भारी फ़ेडरेशन के लिए वैकल्पिक शार्डेड वर्कर। इसमें कुछ भी नया नहीं है; सब कुछ दस्तावेज़ में दर्ज है; विफलता के तरीके ज्ञात हैं।
सही सवाल अमूर्त रूप में "सेल्फ-होस्ट या matrix.org" नहीं है — सवाल यह है: "क्या मैं चाहता हूँ कि मेरी फ़ेडरेशन पहचान उस मशीन से जुड़ी हो जिसका प्रबंधन मैं खुद करता हूँ"। अगर जवाब हाँ है, तो इस पेज का बाक़ी हिस्सा उसी की विधि है।
~100 रूम वाले कम्युनिटी होमसर्वर के लिए (छोटे DM और बाहर फ़ेडरेट किए गए कुछ भरे-पूरे सार्वजनिक रूम का मिश्रण), Ravelin ($16.90/mo, 8 vCPU, 16 GB, 480 GB NVMe) सही टियर है। फ़ेडरेशन के उछाल में Synapse का Python डेटा पाथ RAM का भूखा हो जाता है — 50k उपयोगकर्ताओं वाले सर्वर के किसी लोकप्रिय रूम में जुड़ने से state-resolution का क्षणिक उछाल आता है जिसे हेडरूम चाहिए। 16 GB इसे आराम से झेल लेता है।
~1000 सक्रिय रूम से अधिक होने पर या जब फेडरेशन ट्रैफ़िक Synapse को उसके sharded worker मोड की आवश्यकता तक धकेल दे, Bulwark टियर आपको समर्पित federation_sender, synchrotron और event_persister workers चलाने के लिए कोर देता है — एक ही बॉक्स में Synapse की हॉरिजॉन्टल स्केलिंग की कहानी। उस बिंदु पर आप यह भी सोचना चाहेंगे कि क्या Postgres का अपना VPS होना चाहिए; हम दो-बॉक्स लेआउट के बारे में बात कर सकते हैं।
निजी होमसर्वर के लिए — आपका खाता, कुछ DM, दो-चार छोटे निजी रूम — Garrison ($7.90/mo, 4 vCPU, 8 GB, 240 GB NVMe) पर्याप्त से ज़्यादा है। सिंगल-यूज़र सेटअप के लिए Sentinel पर Conduit तकनीकी रूप से संभव है, लेकिन Garrison पर Synapse आपको बिना माइग्रेशन के बढ़ने की गुंजाइश देता है।
इनमें से कोई भी यह नहीं है: हज़ार-टेनेंट वाली मैनेज्ड-Matrix सेवा। NordBastion उस ऑपरेटर के लिए बना है जो अपने जान-पहचान के लोगों के लिए अपना होमसर्वर चलाता है — अजनबियों को Matrix खाते बेचने के लिए नहीं।
एक रूपरेखा — अपस्ट्रीम element-hq Synapse दस्तावेज़ homeserver.yaml tuning और worker mode के लिए आधिकारिक संदर्भ बने रहते हैं।
आधिकारिक Docker इंजन + Compose v2 प्लगइन। Element-HQ एक मेंटेन की जाने वाली Synapse इमेज प्रकाशित करता है, जिसे आप टैग से पिन कर सकते हैं।
curl -fsSL get.docker.com \
| sh
apt install \
docker-compose-pluginSynapse इमेज का एक बार चलने वाला "generate" मोड आपके server_name के अनुसार एक शुरुआती कॉन्फ़िग लिखता है। उसी दौर में खुला रजिस्ट्रेशन बंद कर दें।
docker run --rm \
-v ./data:/data \
-e SYNAPSE_SERVER_NAME=example.org \
matrixdotorg/synapse:latest \
generatePostgres ही प्रोडक्शन स्टोर है; SQLite केवल परीक्षण के लिए है। वर्कर पूल के लिए Redis ज़रूरी है, भले ही आप सिंगल-प्रोसेस से शुरू करें।
# इन दोनों को docker-compose.yml फ़ाइल में जोड़ेंpostgres: postgres:15
redis: redis:7-alpine
# इसके बाद homeserver.yaml फ़ाइल में: डेटाबेस ड्राइवर psycopg2आपके मुख्य (apex) डोमेन पर /.well-known/matrix/{client,server} पते पर दो छोटी JSON फ़ाइलें रखनी होती हैं। इन्हें application/json के रूप में और CORS हेडर Access-Control-Allow-Origin: * के साथ सर्व किया जाना चाहिए।
# /.well-known/matrix/server
{"m.server": "matrix.example.org:443"}
# /.well-known/matrix/client
{"m.homeserver":{"base_url":"https://matrix.example.org"}}federationtester.matrix.org well-known, सर्टिफ़िकेट चेन, TLS हैंडशेक, वर्ज़न हैंडशेक और key एक्सचेंज की जाँच करता है। जब तक यह हरा न हो जाए, उपयोगकर्ताओं को आमंत्रित न करें।
# server_name यहाँ पेस्ट करें:# federationtester.matrix.org
# सभी जाँचें हरी होनी चाहिएhomeserver.yaml की registration_shared_secret और register_new_matrix_user CLI — इन दोनों को मिलाकर, सार्वजनिक साइनअप कभी खोले बिना ही एक एडमिन खाता तैयार हो जाता है।
docker compose exec synapse \
register_new_matrix_user \
-a -c /data/homeserver.yaml \
http://localhost:8008एंड-टू-एंड एन्क्रिप्शन एक मज़बूत दावा है। यह उसी पल कमज़ोर पड़ जाता है जब रिले का होस्टर बिलिंग-पक्ष के KYC से ठीक-ठीक जान लेता है कि किस क़ानूनी व्यक्ति ने यह होमसर्वर खड़ा किया। केवल-क्रिप्टो बिलिंग के साथ बिना KYC साइनअप रिले के प्रशासनिक मेटाडेटा को उतना ही अपारदर्शी रखता है जितना रिले का पेलोड मेटाडेटा है: "इस ईमेल के पीछे का प्रीपेड बैलेंस", बस इतना ही।
Matrix का एंड-टू-एंड एन्क्रिप्शन पहले ही गणितीय रूप से रिले को पेलोड पढ़ने से रोकता है। नॉर्डिक न्यायक्षेत्र दूसरी परत जोड़ता है: होस्टर को कनेक्शन मेटाडेटा लॉग करने पर मजबूर करने वाला कोई डेटा-रिटेंशन आदेश नहीं, क्लाइंट-साइड स्कैनिंग का कोई क़ानून लागू नहीं, और एक प्रकाशित warrant canary जो बताता है कि अगर कोई गणित बदलने की कोशिश करे तो क्या होगा (हम ऐसा नहीं कर सकते)। "ना" की दो परतें एक से बेहतर हैं।
कुछ अच्छी तरह से भरे सार्वजनिक कमरों में एक federated homeserver बहुत सारे छोटे federation events भेजता है — हर join, हर state change, हर message receipt एक deliver-to-N-servers fan-out है। कुल मात्रा विशाल नहीं है लेकिन यह निरंतर है, और GB-out के आधार पर बिल करने वाला कोई भी होस्टर ऑपरेटर को चिंतित कर देता है। Unmetered uplink यह मानसिक बोझ हटा देता है: जितना protocol माँगे उतना federate करें; चालान वही रहेगा।
Matrix होमसर्वर को सेल्फ-होस्ट करना किसी छोटे समूह के लिए अपनी मैसेजिंग की संप्रभुता का सबसे साफ़-सुथरा कदम है। एक SaaS चैट-टूल सीट की कीमत में आपको एक फ़ेडरेटेड, एंड-टू-एंड एन्क्रिप्टेड होमसर्वर मिलता है जिसके हैंडल किसी भी प्लेटफ़ॉर्म से ज़्यादा टिकते हैं, जिसका मॉडरेशन आपका है, और जिसकी होस्टिंग ऐसे न्यायक्षेत्र में है जहाँ न डेटा-रिटेंशन के आदेश हैं और न क्लाइंट-साइड-स्कैनिंग का कोई क़ानून लागू है।
NordBastion इस ख़ास काम के लिए जो हिस्से मायने रखते हैं, उन पर स्पष्ट राय रखता है — बिना KYC एडमिन साइनअप, नॉर्डिक न्यायक्षेत्र, अनमीटर्ड अपलिंक — और बाक़ी चीज़ों में जानबूझकर साधारण रहता है। Docker, Docker है। Synapse, Synapse है। Element-HQ इमेज देता है; हम मशीन देते हैं।
एक शाम निकालें, छह चरण पूरे करें, फ़ेडरेशन टेस्टर से सत्यापित करें, एडमिन खाता बनाएँ। वह होमसर्वर उस शाम के बाद सालों तक चलता रहेगा।
वे आठ सवाल जिनसे Matrix एडमिन docker compose up से पहले सचमुच जूझते हैं। well-known डेलिगेशन का सवाल दूसरा होने की एक वजह है।
क्योंकि सर्वर एक ही मशीन है और संदेश हमेशा के लिए संग्रहीत रहते हैं। डिस्क तक पहुँच रखने वाला कोई भी व्यक्ति — स्नैपशॉट की गलती, फोरेंसिक इमेज, बदमाश हुआ सह-व्यवस्थापक, या जब आप अंततः सर्वर सौंपते हैं तो उत्तराधिकारी — अनएन्क्रिप्टेड रूम में सादा टेक्स्ट देख सकता है। एंड-टू-एंड एन्क्रिप्शन होमसर्वर को उपयोगी बनाए रखता है (यह रिले करता है, फेडरेट करता है, UI प्रस्तुत करता है) साथ ही संदेश पेलोड को प्रतिभागियों की डिवाइस कुंजियों को छोड़कर बाकी सब के लिए गणितीय रूप से अपठनीय बना देता है। Self-hosting और E2E बेल्ट और सस्पेंडर हैं: आप रिले नियंत्रित करते हैं और रिले अपना ट्रैफ़िक नहीं पढ़ सकता।
Matrix में आप https://example.org/.well-known/matrix/client और /.well-known/matrix/server पर दो छोटी JSON फ़ाइलें सर्व करके अपने उपयोगकर्ता-सम्मुख डोमेन (example.org) को सर्वर-सम्मुख डोमेन (matrix.example.org) से अलग रख सकते हैं। client वाली फ़ाइल Element को बताती है कि कौन-सा होमसर्वर URL इस्तेमाल करना है; server वाली फ़ाइल फ़ेडरेट करने वाले peers को बताती है कि s2s API के लिए Synapse तक कहाँ पहुँचना है। लोग तीन जगह उलझते हैं: फ़ाइलों को गलत Content-Type के साथ सर्व करना, CORS का दूसरे इंस्टेंस को उन्हें fetch करने की अनुमति न देना, या server फ़ाइल का ऐसे port की ओर इशारा करना जिसे फ़ायरवॉल असल में खोलता ही नहीं। रूम प्रकाशित करने से पहले federationtester.matrix.org से सत्यापित करें।
Synapse (Python, संदर्भ कार्यान्वयन) वही है जो 95% सार्वजनिक होमसर्वर चलाते हैं; यह सबसे ज़्यादा परखा गया फ़ेडरेशन peer है और अकेला ऐसा है जो spec में परिभाषित हर फ़ीचर को सपोर्ट करता है। Conduit (Rust, सिंगल बाइनरी, RocksDB) और Dendrite (Go, माइक्रोसर्विसेज़) हल्के हैं — Conduit तो मशहूर तौर पर Raspberry Pi पर भी चलता है। उपयोगकर्ताओं वाले सार्वजनिक फ़ेडरेटेड होमसर्वर के लिए Synapse ही जवाब है; शौकिया सिंगल-यूज़र सर्वर के लिए आप Sentinel पर Conduit आज़मा सकते हैं। यह लेख Synapse को मानकर चलता है।
homeserver.yaml में enable_registration: false सेट करें और जिन लोगों को आप सचमुच चाहते हैं, उनके खाते admin API के ज़रिए बनाने के लिए registration_shared_secret पर निर्भर रहें। विकल्प के तौर पर, enable_registration_without_verification: false को हार्ड-कोडेड shared-secret इनवाइट फ़्लो के साथ जोड़ें। Matrix फ़ेडरेशन इतना बड़ा है कि खुले रजिस्ट्रेशन वाला कोई भी होमसर्वर कुछ ही दिनों में स्पैमबॉट खातों का फ़ार्म बन जाता है; मानक जवाब यही है — "रजिस्ट्रेशन एडमिन-नियंत्रित, फ़ेडरेशन खुला"।
नहीं — Matrix C-S API ही प्रोटोकॉल का अनुबंध है, और हर मानक-अनुरूप क्लाइंट हर मानक-अनुरूप सर्वर से बात कर सकता है। Element डिफ़ॉल्ट और सबसे ज़्यादा परखा हुआ है; Cinny एक हल्का वेब क्लाइंट है जिसे कुछ सेल्फ-होस्टर साथ में बंडल करना पसंद करते हैं; SchildiChat Telegram-शैली के UI वाला Element का फ़ोर्क है; FluffyChat मोबाइल-फ़र्स्ट पर केंद्रित है। होमसर्वर को न तो दिखता है और न ही फ़र्क पड़ता है कि उपयोगकर्ता किस क्लाइंट पर है। जो आपके समुदाय को पसंद हो वह चुनें, बाद में बदल लें, किसी माइग्रेशन की ज़रूरत नहीं।
हर Matrix उपयोगकर्ता के पास डिवाइस keys का एक सेट (प्रति-डिवाइस, अल्पकालिक) और एक cross-signing key (प्रति-खाता, दीर्घकालिक) होती है। cross-signing मास्टर key ही वह है जो उपयोगकर्ता को सब कुछ दोबारा सत्यापित किए बिना नया डिवाइस जोड़ने देती है; इसे खो दें तो उपयोगकर्ता re-key करने तक पुराने E2E संदेशों से बाहर हो जाता है। Element का "Secure Backup" फ़ीचर cross-signing key को पासफ़्रेज़ या रिकवरी key से एन्क्रिप्ट करके सर्वर की ओर अपारदर्शी ciphertext के रूप में संग्रहीत करता है — होमसर्वर के पास वह blob रहता है, पर वह उसे पढ़ नहीं सकता। साइनअप के समय अपने उपयोगकर्ताओं के लिए रिकवरी-key वाला चरण दस्तावेज़ में लिखें; यही UX का वह एक हिस्सा है जो टाले जा सकने वाले लॉक-आउट रोकता है।
सीधे तौर पर नहीं — रूम फ़ेडरेटेड ऑब्जेक्ट हैं, प्रति-सर्वर रिकॉर्ड नहीं, इसलिए किसी रूम को "स्थानांतरित" करने का मतलब है उसे अपग्रेड करना (एक Matrix-नेटिव प्रिमिटिव जो एक उत्तराधिकारी रूम बनाता है और पुराने रूम पर रीडायरेक्ट का stub छोड़ देता है) और उसी प्रतिभागी समूह को आमंत्रित करना। रूम ID बदल जाती है, alias साथ आ सकता है। होमसर्वरों के बीच उपयोगकर्ता-खाते का सीधा माइग्रेशन Matrix की एक पुरानी इच्छा-सूची का आइटम है (खाता पोर्टेबिलिटी spec के रोडमैप पर है); आज के लिए आप अपने सर्वर पर नया खाता बनाते हैं और लोगों से आपको दोबारा जोड़ने को कहते हैं।
Matrix में प्रति-रूम मॉडरेशन प्रिमिटिव (kick, ban, redact, रूम एडमिन) और प्रति-सर्वर मॉडरेशन प्रिमिटिव (Synapse module API के ज़रिए denylist, प्रबंधित denylist के लिए MJOLNIR बॉट, केवल-आमंत्रण फ़ेडरेशन के लिए सर्वर-स्तरीय allowlist मोड) हैं। कम्युनिटी होमसर्वर के लिए MJOLNIR-शैली की denylist सदस्यता ही मानक जवाब है — आप स्पैम/दुरुपयोग की पहचान का काम रखरखाव वाले denylist समुदायों को सौंपते हैं और नीति को स्थानीय स्तर पर लागू करते हैं। आपकी संप्रभुता: आप तय करते हैं कि किन denylist को फ़ॉलो करना है।
फ़ेडरेटेड माइक्रोब्लॉगिंग — सहोदर फ़ेडरेशन प्रोटोकॉल; वही ऑपरेटर पैटर्न, अलग सतह क्षेत्र।
Sentinel पर कर्नेल-स्तर की तेज़ VPN एग्ज़िट — उस होमसर्वर एडमिन के लिए जो अपनी ही टनल के ज़रिए ssh करना चाहता है।
Tor नेटवर्क को Nordic बैंडविड्थ दान करें — एक ही ऑपरेटर के रैक में एंड-टू-एंड एन्क्रिप्टेड होमसर्वर का स्वाभाविक पड़ोसी।
निजी होस्टिंग, उत्तर में निर्मित।