VPS पर SimpleX chat server कैसे host करें
अपने VPS पर SimpleX SMP relay और XFTP server को सुरक्षित रूप से सेटअप करें। इस गाइड में unprivileged user, TLS कॉन्फ़िगरेशन, पोर्ट सेटिंग्स और बैकअप के सटीक स्टेप्स शामिल हैं।
Self-hosted SimpleX chat server क्या करता है
SimpleX chat server को self-host करने के लिए आप एक VPS पर एक daemon चलाते हैं: smp-server, जो SMP (simplex messaging protocol) के लिए relay है। यह उन message queues को रखता है जहाँ आपके contacts लिखते और पढ़ते हैं। एक दूसरा, वैकल्पिक daemon जिसे xftp-server कहा जाता है, file transfers को relay करता है। दोनों एक ही project, simplexmq, से आते हैं, और प्रत्येक एक single binary, एक config file, और एक append-only log है।
यह operator के लिए लिखा गया है, न कि app user के लिए। Relay में कोई account, कोई contact list और कोई chat history नहीं होती। इसमें queues, कुछ undelivered ciphertext, और एक certificate होता है जो इसकी पहचान करता है। आप uptime, थोड़ी disk, और अपने box से गुजरने वाले metadata की जिम्मेदारी लेते हैं।
नीचे दिए गए प्रत्येक command, path, port और flag project के अपने documentation से लिए गए हैं: SMP server hosting page, XFTP server page, और protocol security document। जहाँ कोई संख्या महत्वपूर्ण है, वहाँ उसके बगल में उस page का नाम दिया गया है जहाँ से वह ली गई है।
बिना user identifiers वाले नेटवर्क को relays की आवश्यकता क्यों होती है
SimpleX में न तो usernames होते हैं, न phone numbers और न ही account IDs। एक contact एक unidirectional queue है: किसी relay पर एक पता, जिस पर एक पक्ष लिखता है और दूसरा पक्ष उसे पढ़ता है। आपके दो contacts के बीच ऐसा कोई identifier साझा नहीं होता जिसे server जोड़ सके।
इन queues को कहीं न कहीं स्थित होना पड़ता है, जिसका एक सीधा कारण है। दो phones शायद ही कभी एक ही समय पर online होते हैं। किसी न किसी माध्यम को संदेश को अभी स्वीकार करके उसे तब तक सुरक्षित रखना पड़ता है जब तक कि दूसरा device उसे मांग न ले। SMP relay का पूरा काम यही है। इसका अर्थ यह भी है कि दोनों devices कभी एक-दूसरे से सीधे connect नहीं होते, इसलिए किसी को भी दूसरे का IP (internet protocol) address पता नहीं चलता। relay इस exposure को स्वयं संभाल लेता है।
relay का hostname queue address का हिस्सा होता है, इसलिए यह आपके द्वारा साझा किए गए हर invitation link के भीतर मौजूद होता है। अंत में दिए गए threat model को पढ़ते समय इस बात का ध्यान रखें।
एक relay क्या देख सकता है और क्या नहीं
प्रोजेक्ट ने protocol/security.md में इसे एक threat model के रूप में स्पष्ट किया है। किसी भी चीज़ को install करने से पहले इसे पढ़ना आवश्यक है, क्योंकि इस गाइड के बाद वह relay आपका होगा। एक relay, जिसमें हमलावर द्वारा पूरी तरह नियंत्रित relay भी शामिल है, संदेशों की सामग्री या उनके प्रकार को नहीं जान सकता। वह व्यक्तिगत संदेशों को बिना पता चले जोड़, डुप्लिकेट या दूषित नहीं कर सकता, और वह active attack के जरिए end-to-end encryption को नहीं तोड़ सकता।
उसी पृष्ठ पर उन कार्यों की सूची दी गई है जो एक relay कर सकता है। यह जान सकता है कि queue का प्राप्तकर्ता कब online है। यह गिन सकता है कि एक queue से कितने संदेश गुजरते हैं। यह प्राप्तकर्ता का IP address जान सकता है। यह queue में भविष्य के हर संदेश को drop कर सकता है, या उस queue की स्थिति के बारे में झूठ बोल सकता है।
अतः, विभाजन स्पष्ट है। गोपनीयता (confidentiality) client का काम है और self-hosting इसे प्रभावित नहीं करती। metadata और उपलब्धता (availability) relay operator का काम है, और self-hosting इन दोनों की जिम्मेदारी आपको सौंप देती है।
शुरू करने से पहले आपकी आवश्यकताएं
- Ubuntu 22.04 या 24.04 पर चलने वाला एक VPS। यह प्रोजेक्ट विशेष रूप से इन्हीं दो वर्ज़न के लिए x86-64 और aarch64 आर्किटेक्चर में release binaries प्रकाशित करता है।
- एक डोमेन नाम जिसका A record आपके VPS को पॉइंट कर रहा हो, और यदि आपके पास IPv6 है तो एक AAAA record भी। ये दस्तावेज़ उदाहरण के तौर पर
smp1.example.comका उपयोग करते हैं। - Root या
sudoएक्सेस, और firewall में बदलाव करते समय एक दूसरा SSH session खुला रखें। - सर्वर के बाहर कहीं बैकअप स्टोर करने की जगह, क्योंकि config डायरेक्टरी ही सर्वर की पहचान होती है।
ARM instance पर x86-64 के बजाय aarch64 asset का उपयोग करें। इस गाइड में बाकी कुछ भी नहीं बदलता है, और ARM और x86 VPS प्लान के बीच चयन का संबंध केवल कीमत और प्रति-कोर गति से है, न कि इस बात से कि यह सॉफ्टवेयर चलेगा या नहीं।
"latest" के बजाय एक pinned release इंस्टॉल करें
यह प्रोजेक्ट एक install script प्रदान करता है जो current release को pull करती है और एक simplex-servers-update कमांड रजिस्टर करती है। यह काम करती है। फिर भी version को pin करें: यदि किसी relay की binary आपके नियंत्रण के बिना बदल जाती है, तो समस्या आने पर आप उसका विश्लेषण नहीं कर पाएंगे।
अगस्त 2026 तक, वर्तमान simplexmq release v6.5.0 है, जिसे 29 अप्रैल 2026 को प्रकाशित किया गया था। जिस tag का आप उपयोग करना चाहते हैं, उसके लिए releases page देखें, और फिर नीचे हर जगह उस tag का उपयोग करें।
sudo useradd -m smp
sudo install -d -o smp -g smp -m 755 /etc/opt/simplex /var/opt/simplexuseradd -m smp कोई पासवर्ड सेट नहीं करता है, इसलिए कोई भी सीधे smp के रूप में login नहीं करता है। कुछ भी चलाने से पहले स्वयं दो directories बनाएँ, क्योंकि /etc/opt का स्वामित्व root के पास है और इसका mode 755 है, जिससे smp user के पास अपनी config directory लिखने के लिए कोई स्थान नहीं बचता है।
VER=v6.5.0
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/smp-server-ubuntu-24_04-x86-64" -o /tmp/smp-server
sha256sum /tmp/smp-serverउस hash की तुलना उसी tag के लिए release notes में प्रकाशित SHA2-256 checksums से करें। प्रोजेक्ट release checksums को SimpleX Chat key FB44AF81A45BDE327319797C85107E357D4A17FC के साथ sign भी करता है, जो server page पर प्रलेखित है, ताकि आप hash पढ़ने के लिए केवल पेज पर भरोसा करने के बजाय signature को verify कर सकें।
sudo install -m 755 -o root -g root /tmp/smp-server /usr/local/bin/smp-serverइसे जानबूझकर root-owned के रूप में इंस्टॉल करें। यह service smp के रूप में चलती है, इसलिए service के breach होने पर भी वह उस binary को rewrite नहीं कर सकती जिससे वह start होती है।
सर्वर को इनिशियलाइज़ करें, और इसके द्वारा प्रिंट किए गए दो सीक्रेट्स को सुरक्षित रखें
sudo su smp -c "smp-server init --yes --store-log --daily-stats --no-password --fqdn=smp1.example.com"--store-log(-l) क्यू (queues) का एक append-only लॉग/var/opt/simplex/smp-server-store.logमें लिखता है, ताकि रीस्टार्ट होने पर भी रिले (relay) सुरक्षित रहे। इसके बिना, रीस्टार्ट होने पर सभी क्यू हट जाती हैं, जिसका अर्थ है कि आपके माध्यम से रूट किया गया हर संपर्क काम करना बंद कर देगा।--daily-stats(-s) काउंटर्स को CSV फॉर्मेट में/var/opt/simplex/smp-server-stats.daily.logमें लिखता है।--fqdnआपके डोमेन को जेनरेट किए गए सर्टिफिकेट में डालता है। यदि आपके पास डोमेन नहीं है, तो इसके बजाय--ipका उपयोग करें।--no-passwordकिसी को भी आपके रिले पर क्यू बनाने की अनुमति देता है। इसे प्राइवेट रखने के लिए, इनिशियलाइज़ेशन के बाद/etc/opt/simplex/smp-server.iniमें[AUTH]के अंतर्गतcreate_passwordसेट करें, न कि यहाँ--passwordपास करें। ऐसा इसलिए है क्योंकि कमांड लाइन आपके शेल हिस्ट्री और प्रोसेस लिस्ट में चलते समय दिखाई देती है।
Init एक सर्टिफिकेट जेनरेट करता है और उन दो वैल्यूज को प्रिंट करता है जिन्हें आपको संभाल कर रखना चाहिए। पहली वैल्यू फिंगरप्रिंट है, जो एक base64 स्ट्रिंग है और इसे /etc/opt/simplex/fingerprint में भी लिखा जाता है। दूसरी वैल्यू पूरा सर्वर एड्रेस है, जो फिंगरप्रिंट और आपके होस्टनेम का संयोजन है। दोनों को अभी कॉपी कर लें।
Init /etc/opt/simplex/ca.key भी बनाता है, और डॉक्यूमेंटेशन आपको उस फाइल को ऑफलाइन स्टोरेज में ले जाने के लिए कहता है। इसका कारण महत्वपूर्ण है: क्लाइंट्स उस सर्टिफिकेट अथॉरिटी के फिंगरप्रिंट को पिन (pin) करते हैं, इसलिए जिसके पास भी ca.key होगा, वह एक नया सर्वर सर्टिफिकेट जारी कर सकता है जिसे आपके क्लाइंट्स आपके सर्टिफिकेट के रूप में स्वीकार कर लेंगे। आपको इसे केवल बाद में smp-server cert के साथ सर्वर सर्टिफिकेट को रोटेट करने के लिए वापस लाने की आवश्यकता होगी।
Init को एक बार की जाने वाली प्रक्रिया के रूप में मानें। आपके एड्रेस में मौजूद फिंगरप्रिंट उस अथॉरिटी से आता है जिसे यह जेनरेट करता है, इसलिए उस अथॉरिटी को दोबारा जेनरेट करने से आपको एक अलग एड्रेस मिलेगा और जो एड्रेस आपने पहले दिया था, वह अमान्य हो जाएगा।
इसे एक unprivileged user के रूप में systemd के अंतर्गत चलाएं
/etc/systemd/system/smp-server.service लिखें, ठीक वैसे ही जैसे docs में दिया गया है:
[Unit]
Description=SMP server systemd service
[Service]
User=smp
Group=smp
Type=simple
ExecStart=/usr/local/bin/smp-server start +RTS -N -RTS
ExecStopPost=/usr/bin/env sh -c '[ -e "/var/opt/simplex/smp-server-store.log" ] && cp "/var/opt/simplex/smp-server-store.log" "/var/opt/simplex/smp-server-store.log.bak"'
LimitNOFILE=65535
KillSignal=SIGINT
TimeoutStopSec=infinity
[Install]
WantedBy=multi-user.targetUpstream unit में AmbientCapabilities=CAP_NET_BIND_SERVICE भी होता है। वह line इसलिए मौजूद है क्योंकि process smp के रूप में चलती है, और 1024 से नीचे के ports एक non-root process के लिए बंद होते हैं, इसलिए इसके बिना daemon 80 या 443 port को bind नहीं कर सकता। यदि आप उन ports पर service दे रहे हैं, तो इसे जोड़ें। LimitNOFILE=65535 महत्वपूर्ण है क्योंकि प्रत्येक subscribed client एक open TCP connection रखता है, और default limit एक busy relay की आवश्यकता से बहुत कम होती है। ExecStopPost हर stop पर store log को एक .bak file में copy करता है, जो आपको एक free rollback point देता है।
sudo systemctl daemon-reload
sudo systemctl enable --now smp-server
sudo systemctl status smp-server
sudo journalctl -fu smp-serverएक सफल start server address को log करती है। इसके बाद पुष्टि करें कि sockets वास्तव में open हैं:
sudo ss -tlnp | grep -E ':(443|5223)'दोनों lines में smp-server का नाम होना चाहिए। Daemon को बिना sudo rights के उसके अपने account के अंतर्गत चलाना वही आदत है जिसका वर्णन VPS पर per-service accounts में किया गया है, और यही वह तरीका है जो एक network daemon में मौजूद bug को root shell बनने से रोकता है।
किन ports को open रखना है और किसे बंद रखना है
दस्तावेज़ तीन ports की सूची देते हैं: 5223/tcp, 443/tcp और 80/tcp। Port 5223 SMP transport है। प्रदान की गई config में port: 5223,443 को [TRANSPORT] के अंतर्गत सेट किया गया है, इसलिए यही protocol 443 पर भी उत्तर देता है। यह महत्वपूर्ण है क्योंकि कई प्रतिबंधित नेटवर्क केवल outbound 443 की अनुमति देते हैं और कुछ नहीं। Port 80 की आवश्यकता केवल वैकल्पिक सूचना पृष्ठ और HTTPS पर इसके redirect के लिए होती है।
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 5223/tcp
sudo ufw enable5224 को open न करें। यह control port है, और दस्तावेज़ इसे बॉक्स के भीतर से ही nc 127.0.0.1 5224 के साथ एक्सेस करते हैं। यह सर्वर की स्थिति को प्रिंट करता है और queues को हटा देता है, इसलिए इसे [AUTH] के अंतर्गत सेट किए गए admin और user passwords के साथ loopback पर ही रहना चाहिए। यदि आप इस टूल के लिए नए हैं, तो VPS पर ufw की बुनियादी जानकारी में rule order और खुद को लॉक होने से बचाने के तरीके बताए गए हैं।
एक और नियंत्रण बिंदु लोगों को परेशानी में डालता है। अधिकांश प्रदाता बॉक्स पर मौजूद ufw से अलग, अपने पैनल में एक नेटवर्क फायरवॉल चलाते हैं। एक port ufw में open हो सकता है, लेकिन आप तक पहुँचने से पहले ही उसे ड्रॉप किया जा सकता है।
वह सर्वर पता जिसकी आपके क्लाइंट्स को आवश्यकता है
smp://<fingerprint>[:<password>]@<public_hostname>[,<onion_hostname>]यह स्ट्रिंग ही संपूर्ण क्लाइंट-साइड कॉन्फ़िगरेशन है। इसे ऐप की सर्वर सेटिंग्स में पेस्ट करें, या ऐप द्वारा दिखाए गए QR कोड को स्कैन करने दें। दस्तावेज़ बताते हैं कि QR कोड में पासवर्ड शामिल होता है, इसलिए जो कोई भी इसे स्कैन करेगा, वह आपके सर्वर के माध्यम से संदेश प्राप्त कर सकेगा।
एक प्रलेखित व्यवहार सभी को आश्चर्यचकित करता है। ऐप में अपना सर्वर जोड़ने का प्रभाव केवल उन संपर्कों पर पड़ता है जिन्हें आप उस बिंदु के बाद बनाते हैं। मौजूदा संपर्क उन्हीं रिले पर बने रहते हैं जहाँ उनकी कतारें (queues) बनाई गई थीं, और वे माइग्रेट नहीं होते हैं। यही कारण है कि आप किसी रिले को बदलने के अगले ही दिन उसे बंद नहीं कर सकते।
XFTP फाइल रिले जोड़ना
XFTP (SimpleX file transfer protocol) नेटवर्क का फाइल संबंधी हिस्सा है, और यह अपने स्वयं के पते (address) वाला एक अलग daemon है। प्रोजेक्ट की XFTP घोषणा के अनुसार, रिले के पास कोई फाइल मेटाडेटा नहीं होता है: वे केवल अलग-अलग chunks देखते हैं, जिनमें से प्रत्येक 256kb, 1mb या 4mb का होता है, और इनका एक्सेस anonymous credentials द्वारा अधिकृत होता है। एक sender एक फाइल के chunks को कई रिले पर फैला सकता है, इसलिए आपके सर्वर पर फाइलें नहीं, बल्कि उनके टुकड़े होते हैं।
sudo useradd -m xftp
sudo install -d -o xftp -g xftp -m 755 /etc/opt/simplex-xftp /var/opt/simplex-xftp /srv/xftp
curl -fL "https://github.com/simplex-chat/simplexmq/releases/download/$VER/xftp-server-ubuntu-24_04-x86-64" -o /tmp/xftp-server
sudo install -m 755 -o root -g root /tmp/xftp-server /usr/local/bin/xftp-server
sudo su xftp -c "xftp-server init -l --fqdn=xftp1.example.com -q '20gb' -p /srv/xftp/"इसका कॉन्फ़िगरेशन /etc/opt/simplex-xftp/ में, इसकी स्थिति (state) /var/opt/simplex-xftp/ में, और फाइल chunks उस स्थान पर होते हैं जिसे -p में निर्दिष्ट किया गया है। systemd यूनिट का स्वरूप User=xftp और ExecStart=/usr/local/bin/xftp-server start +RTS -N -RTS के साथ समान है। Init एक xftp:// पता उसी प्रारूप में प्रिंट करता है जैसा SMP का होता है, और इसका अपना फिंगरप्रिंट /etc/opt/simplex-xftp/fingerprint में होता है।
आपको एक पोर्ट टकराव (collision) की योजना बनानी होगी। XFTP सर्वर का निर्धारित पोर्ट 443 है, और SMP कॉन्फ़िगरेशन में भी 443 सूचीबद्ध है। दो प्रक्रियाएं एक ही पते पर एक ही पोर्ट को bind नहीं कर सकती हैं, इसलिए एक VPS पर किसी एक को बदलना होगा। सबसे सरल समाधान SMP के [TRANSPORT] सेक्शन में port: 5223 को सेट करना है और 443 को फाइल रिले के लिए छोड़ देना है, हालांकि इसका नुकसान यह है कि प्रतिबंधित नेटवर्क वाले क्लाइंट्स के लिए 443 का fallback विकल्प उपलब्ध नहीं रहेगा। अन्य विकल्पों में उसी VPS पर दूसरा IP पता लेना, या दूसरा VPS उपयोग करना शामिल है।
कोटा का निर्धारण ईमानदारी से करें। -q '20gb' आपके पास उपलब्ध डिस्क स्पेस के बारे में एक वादा है। फाइल रिले वह हिस्सा है जो डिस्क और बैंडविड्थ का उपयोग करता है। मैसेज रिले इनका बहुत कम उपयोग करता है।
डिस्क पर क्या रहता है, और बैकअप क्या रिस्टोर करता है
दो डायरेक्टरी महत्वपूर्ण हैं। /etc/opt/simplex/ पहचान है: smp-server.ini, सर्वर सर्टिफिकेट और की, ca.key, और fingerprint। /var/opt/simplex/ स्टेट है: smp-server-store.log में कतारें (queues) रहती हैं और, जब restore_messages: on हो, तो डिलीवर न हुए मैसेज, साथ ही दैनिक सांख्यिकी फाइल भी यहीं होती है।
sudo systemctl stop smp-server
sudo tar czf /root/simplex-backup.tgz -C / etc/opt/simplex var/opt/simplex
sudo chmod 600 /root/simplex-backup.tgz
sudo systemctl start smp-serverस्पष्ट रहें कि वह आर्काइव क्या है। यह मैसेज आर्काइव नहीं है: कतारबद्ध आइटम उन कीज़ के लिए सिफरटेक्स्ट हैं जो रिले के पास कभी नहीं थीं, और शिप किया गया [STORE_LOG] कॉन्फ़िगरेशन वैसे भी 21 दिनों के बाद मैसेज को एक्सपायर कर देता है। यह सर्वर की पहचान की एक कॉपी है, जिसमें ca.key शामिल है, इसलिए जो कोई भी इस फाइल को प्राप्त कर लेगा, वह आपके संपर्कों के सामने खुद को आपका रिले बता सकता है। इसे एन्क्रिप्ट करें और सर्वर से दूर रखें।
इसका लाभ रिस्टोर करना है। /etc/opt/simplex को एक नए VPS पर वापस रखें, उसी DNS नाम को उस पर पॉइंट करें, और फिंगरप्रिंट अपरिवर्तित रहता है, इसलिए आपके द्वारा दिए गए सभी पते अभी भी काम करते हैं। उस डायरेक्टरी को खोने का मतलब है कोई रिकवरी संभव नहीं: एक नए इंस्टॉलेशन का मतलब है एक नया फिंगरप्रिंट, जिसका मतलब है एक नया पता, जिसका मतलब है कि आपके रिले के माध्यम से रूट किया गया हर संपर्क समाप्त हो गया है।
TLS: दो certificates जो अलग-अलग कार्य करते हैं
SMP transport किसी public certificate authority का उपयोग नहीं करता है। Init एक private authority और एक server certificate generate करता है, और उस authority का fingerprint server address के भीतर रहता है। Client यह जाँचता है कि server क्या प्रस्तुत कर रहा है, और उसकी तुलना उस pinned fingerprint से करता है। प्रोजेक्ट इसे client-to-server connection को machine-in-the-middle हमलों से बचाने के रूप में वर्णित करता है। उस port पर चलाने के लिए कोई ACME (automatic certificate management environment) client नहीं है, और rotation एक manual smp-server cert है जिसे SMP_SERVER_CFG_PATH set के साथ चलाया जाता है।
वैकल्पिक information page दूसरा certificate है। इसका [WEB] section static_path, https: 443, cert: /etc/opt/simplex/web.crt और key: /etc/opt/simplex/web.key को नाम देता है। Browser ने कभी आपके private authority के बारे में नहीं सुना होगा, इसलिए यह वह एकमात्र स्थान है जहाँ publicly trusted certificate का उपयोग किया जाना चाहिए। Docs का Docker quick start ठीक इसी उद्देश्य के लिए Caddy को server के सामने रखता है, और certificate को स्वचालित रूप से issue करता है।
Tor के माध्यम से relay तक पहुँचना
दस्तावेजों में एक Tor अनुभाग शामिल है जो Tor Project रिपॉजिटरी से Tor को इंस्टॉल करता है और /etc/tor/torrc में एक hidden service जोड़ता है:
SOCKSPort 0
HiddenServiceNonAnonymousMode 1
HiddenServiceSingleHopMode 1
HiddenServiceDir /var/lib/tor/simplex-smp/
HiddenServicePort 5223 localhost:5223
HiddenServicePort 443 localhost:443दो mode लाइनों को ध्यान से पढ़ें। Single hop और non-anonymous का अर्थ है कि relay का अपना स्थान छिपा हुआ नहीं है। Onion address तेज़ है और यह क्लाइंट्स को एक ऐसा रास्ता देता है जो कभी भी उनका IP पता आपके सामने प्रकट नहीं करता है, लेकिन सर्वर स्वयं अपने public IP पर खोजने योग्य रहता है। /var/lib/tor/simplex-smp/hostname से प्राप्त onion hostname को सर्वर पते के अंत में अल्पविराम (comma) के बाद जोड़ा जाता है। यदि आप सर्वर के स्थान को भी छिपाना चाहते हैं, तो वह एक अलग कॉन्फ़िगरेशन है, और VPS पर एक वास्तविक onion service चलाना इस अंतर को कवर करता है। प्रत्येक टूल क्या छिपाता है, इसका अंतर VPN के साथ Tor की तुलना का विषय है, और यह यहाँ सीधे लागू होता है।
थ्रेट मॉडल: self-hosting क्या बदलता है
यह आपको क्या लाभ देता है। मेटाडेटा (कौन सी queues मौजूद हैं, उन्हें कब पढ़ा जाता है, कौन से पते connect होते हैं) उस मशीन पर रहता है जिसे आप नियंत्रित करते हैं, और आप तय करते हैं कि इसे कितने समय तक रखा जाए। आप उस बड़े समूह का हिस्सा भी नहीं होते जिसे एक बार में request किया जा सकता है।
यह आपको क्या नहीं देता, स्पष्ट शब्दों में:
- एन्क्रिप्शन में कोई बदलाव नहीं होता। आपके इसे बनाने से पहले भी संदेश end-to-end encrypted थे और बाद में भी वे end-to-end encrypted ही रहते हैं। Self-hosting एक मेटाडेटा संबंधी निर्णय है, न कि क्रिप्टोग्राफी संबंधी।
- आपका VPS प्रदाता आपके IP address तक के traffic को देखता है और आपके बिलिंग विवरण रखता है। आपने भरोसे को एक मैसेजिंग ऑपरेटर से हटाकर एक होस्टिंग ऑपरेटर पर स्थानांतरित किया है। आपने इसे समाप्त नहीं किया है।
- आपका relay एक छोटा समूह है। यदि यह एक घर की सेवा करता है, तो इससे connect होना उस घर की पहचान उजागर करता है, और इसका hostname आपके द्वारा भेजे गए प्रत्येक invitation link के अंदर होता है। एक व्यस्त public relay इस एक मामले में आपको बेहतर तरीके से छिपाता है, और यही वास्तविक समझौता है। एक private search server का स्वरूप भी ऐसा ही होता है, इसीलिए what SearXNG actually hides on your own VPS इस बात पर निर्भर करता है कि कितने लोग आपके साथ उस instance को साझा करते हैं।
- उपलब्धता अब आपकी जिम्मेदारी है। डिस्क फुल होने या सर्वर बंद होने का मतलब है कि संदेशों की डिलीवरी रुक जाएगी, और आपके संपर्कों के पास आपके अलावा किसी और रास्ते से संपर्क करने का कोई तरीका नहीं होगा।
यही तर्क किसी भी ऐसी private service पर लागू होता है जिसे आप अपने स्वामित्व वाले बॉक्स पर रखते हैं, चाहे वह यह relay हो या a WireGuard VPN on your own VPS। आप यह चुन रहे हैं कि कौन सा पक्ष मेटाडेटा देखेगा। आप इसे गायब नहीं कर रहे हैं।
जब यह काम न करे
Service start होकर तुरंत बंद हो जाती है। sudo journalctl -u smp-server -n 50 पढ़ें। Bind failure उस port का नाम बताता है जिसे वह उपयोग नहीं कर सका। फिर यह देखने के लिए कि कौन सी process पहले से ही उसे रोके हुए है, sudo ss -tlnp | grep :443 चलाएं। एक नए सर्वर पर आमतौर पर यह nginx, Caddy या वह XFTP सर्वर होता है जिसे आपने एक घंटे पहले install किया था।
Init अपनी config नहीं लिख पा रहा है। /etc/opt/simplex के मौजूद होने से पहले smp user के रूप में smp-server init चलाने पर permission error आता है, क्योंकि /etc/opt का मालिक root है। पहले सही owner के साथ directory बनाएं, फिर init को दोबारा चलाएं।
Clients relay तक नहीं पहुँच पा रहे हैं। dig +short smp1.example.com के साथ जांचें कि नाम सही address पर resolve हो रहा है या नहीं। फिर अपने laptop से port का परीक्षण करें, सर्वर से नहीं: nc -vz smp1.example.com 5223। यदि बाहर से connection विफल हो जाता है जबकि ss सर्वर पर socket को open दिखाता है, तो यह provider के network firewall की ओर इशारा करता है, जो ufw से अलग एक control है।
कोई contact आपके relay के माध्यम से connect नहीं हो पा रहा है। आपके द्वारा साझा किए गए address में मौजूद fingerprint का /etc/opt/simplex/fingerprint की वर्तमान सामग्री से मेल खाना आवश्यक है। यदि आपने [AUTH] के अंतर्गत create_password सेट किया है, तो address में वह password भी होना चाहिए, अन्यथा client को queue बनाने की अनुमति नहीं मिलेगी।
App में सर्वर जोड़ने के बाद कुछ भी स्थानांतरित नहीं हुआ। यह जानबूझकर ऐसा है। केवल नए contacts ही नए जोड़े गए relay का उपयोग करते हैं। मौजूदा contacts के पास जो queues पहले से हैं, वे उन्हीं का उपयोग करते रहते हैं।
FAQ
क्या SimpleX सर्वर को self-host करने से मेरे संदेश अधिक सुरक्षित हो जाते हैं?
नहीं, और यह डिज़ाइन के अनुसार ही है। SimpleX संदेशों को डिवाइसों के बीच end-to-end encrypt करता है, इसलिए relay के पास कभी भी keys नहीं होतीं, चाहे उसे कोई भी चला रहा हो। Self-hosting केवल यह बदलता है कि उन संदेशों के आसपास के metadata को कौन देख सकता है: कौन सी queues मौजूद हैं, उन्हें कब पढ़ा जाता है, और कौन से IP addresses connect होते हैं। यह metadata से जुड़ा निर्णय है। यदि self-hosting का आपका कारण बेहतर encryption है, तो encryption पहले से ही मौजूद था।
एक SimpleX relay operator वास्तव में क्या देख सकता है?
प्रोजेक्ट का protocol/security.md इसे स्पष्ट करता है। एक relay संदेशों की सामग्री या उनके प्रकार को नहीं पढ़ सकता, व्यक्तिगत संदेशों को चुपचाप बदल नहीं सकता, और active attack के जरिए end-to-end encryption को तोड़ नहीं सकता। वह यह देख सकता है कि queue का recipient कब online है, queue से गुजरने वाले संदेशों की गिनती कर सकता है, recipient का IP address जान सकता है, queue में भविष्य के संदेशों को drop कर सकता है, या queue की स्थिति के बारे में झूठ बोल सकता है। एक बार relay आपके नियंत्रण में आ जाने पर ये शक्तियाँ आपके पास होती हैं।
क्या मुझे domain name और TLS certificate की आवश्यकता है?
उपयोगी सेटअप के लिए आपको एक domain की आवश्यकता होती है, और यदि आपके पास वास्तव में कोई domain नहीं है तो smp-server init, --ip को स्वीकार करता है। Messaging port के लिए आपको किसी public authority से certificate की आवश्यकता नहीं है: init अपनी खुद की authority generate करता है, और client उस fingerprint को pin करता है जो आपके smp:// address में दिखाई देता है। Publicly trusted certificate की आवश्यकता केवल वैकल्पिक web information page के लिए होती है, जिसे smp-server.ini के [WEB] section में cert और key के रूप में configure किया जाता है।
यदि मैं /etc/opt/simplex खो दूँ तो क्या होगा?
आपके द्वारा दिए गए सभी addresses काम करना बंद कर देंगे। वह directory उस certificate authority को रखती है जिसका fingerprint आपके server address में embedded होता है, इसलिए rebuild करने पर एक अलग fingerprint और परिणामस्वरूप एक अलग server बनता है। जिन contacts की queues उस relay पर स्थित हैं, उन्हें client side से ठीक नहीं किया जा सकता। Directory का encrypted backup लें और उसे box से बाहर रखें, और ca.key को docs के निर्देशानुसार offline store करें, क्योंकि जिसके पास भी यह होगा, वह आपके relay का रूप धारण कर सकता है।
क्या मैं SMP relay और XFTP file relay को एक ही VPS पर चला सकता हूँ?
हाँ, लेकिन एक conflict को हल करना होगा। XFTP server का निर्धारित port 443 है और default SMP config में port: 5223,443 सूचीबद्ध है, इसलिए दोनों एक ही socket चाहते हैं। इनमें से किसी एक को 443 port दें: SMP server के लिए port: 5223 set करें, या file relay को दूसरे IP address या दूसरे VPS पर ले जाएँ। साथ ही, storage quota को अपनी वास्तविक disk क्षमता के अनुसार रखें, क्योंकि file relay ही वह component है जो disk और bandwidth का उपयोग करता है।