VPS पर अपना SimpleX chat server कैसे host करें

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। जहाँ कोई संख्या महत्वपूर्ण है, उसका स्रोत उसके बगल में दिया गया है।

बिना user identifiers वाले नेटवर्क को relays की आवश्यकता क्यों होती है

SimpleX में न तो usernames होते हैं, न ही phone numbers और न ही account IDs। एक contact एक unidirectional queue है: किसी relay पर एक पता, जिस पर एक पक्ष लिखता है और दूसरा पक्ष उसे पढ़ता है। आपके दो contacts के बीच कोई ऐसा identifier साझा नहीं होता जिसे कोई सर्वर आपस में जोड़ सके।

उन queues को कहीं न कहीं तो रहना ही पड़ता है, और इसका एक सीधा कारण है। दो phones शायद ही कभी एक ही समय पर online होते हैं। किसी न किसी चीज़ को अभी संदेश स्वीकार करना होता है और उसे तब तक संभाल कर रखना होता है जब तक कि दूसरा device उसे न मांगे। SMP relay का पूरा काम यही है। इसका अर्थ यह भी है कि दो devices कभी एक-दूसरे से सीधे connect नहीं होते, इसलिए किसी को भी दूसरे का IP (internet protocol) address पता नहीं चलता। relay इस exposure को खुद पर ले लेता है।

relay का hostname queue address का हिस्सा होता है, इसलिए यह उस हर invitation link के अंदर होता है जिसे आप उससे share करते हैं। अंत में दिए गए 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 इसे प्रभावित नहीं करती। मेटाडेटा और उपलब्धता (availability) relay operator का काम है, और self-hosting इन दोनों की जिम्मेदारी आपको सौंप देती है।

शुरू करने से पहले आपकी आवश्यकताएं

• Ubuntu 22.04 या 24.04 पर चलने वाला एक VPS। यह प्रोजेक्ट विशेष रूप से इन्हीं दो वर्ज़न्स के लिए x86-64 और aarch64 आर्किटेक्चर पर बने release binaries प्रकाशित करता है।
• एक domain name जिसका A record VPS की ओर इशारा करता हो, और यदि आपके पास IPv6 है तो एक AAAA record भी हो। दस्तावेज़ उदाहरण के तौर पर smp1.example.com का उपयोग करते हैं।
• Root या sudo एक्सेस, और firewall में बदलाव करते समय एक दूसरा SSH session खुला रखें।
• सर्वर के बाहर कहीं backup स्टोर करने की जगह, क्योंकि config directory ही सर्वर की पहचान होती है।

ARM instance पर x86-64 के बजाय aarch64 asset का उपयोग करें। इस गाइड में बाकी कुछ भी नहीं बदलता है, और ARM और x86 VPS plans के बीच का चुनाव कीमत और प्रति-कोर गति के बारे में है, न कि इस बारे में कि यह सॉफ्टवेयर चलता है या नहीं।

"latest" के बजाय एक pinned release इंस्टॉल करें

यह प्रोजेक्ट एक install script प्रदान करता है जो current release को pull करती है और एक simplex-servers-update कमांड रजिस्टर करती है। यह काम करती है, लेकिन फिर भी version को पिन करें: यदि किसी relay की binary आपके नियंत्रण के बिना बदल जाती है, तो समस्या आने पर आप उसका विश्लेषण नहीं कर पाएंगे।

अगस्त 2026 तक, वर्तमान simplexmq release v6.5.0 है, जिसे 29 अप्रैल 2026 को प्रकाशित किया गया था। releases page पर उस tag को देखें जिसे आप चाहते हैं, और फिर नीचे हर जगह उसी tag का उपयोग करें।

sudo useradd -m smp
sudo install -d -o smp -g smp -m 755 /etc/opt/simplex /var/opt/simplex

useradd -m smp कोई पासवर्ड सेट नहीं करता है, इसलिए कोई भी सीधे smp के रूप में लॉगिन नहीं करता है। कुछ भी चलाने से पहले स्वयं दो डायरेक्टरी बनाएं, क्योंकि /etc/opt का स्वामित्व root के पास है और इसका मोड 755 है, जिससे smp यूजर के पास अपनी कॉन्फ़िगरेशन डायरेक्टरी लिखने के लिए कोई जगह नहीं बचती है।

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

उस हैश की तुलना उसी tag के लिए release notes में प्रकाशित SHA2-256 चेकसम से करें। प्रोजेक्ट release चेकसम को SimpleX Chat की की FB44AF81A45BDE327319797C85107E357D4A17FC के साथ साइन भी करता है, जो server page पर प्रलेखित है, ताकि आप हैश पढ़ने के लिए केवल पेज पर भरोसा करने के बजाय सिग्नेचर को सत्यापित कर सकें।

sudo install -m 755 -o root -g root /tmp/smp-server /usr/local/bin/smp-server

इसे जानबूझकर root-owned इंस्टॉल करें। सर्विस smp के रूप में चलती है, इसलिए यदि सर्विस breach होती है, तो वह उस बाइनरी को फिर से नहीं लिख सकती जिससे वह शुरू हुई है।

सर्वर को इनिशियलाइज़ करें, और इसके द्वारा प्रिंट किए गए दो secrets को सुरक्षित रखें

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 में लिखता है, ताकि restart के बाद भी relay सुरक्षित रहे। इसके बिना, restart होने पर सभी queues हट जाती हैं, जिसका अर्थ है कि आपके माध्यम से route होने वाला हर contact काम करना बंद कर देगा।
• --daily-stats (-s) counters को CSV फॉर्मेट में /var/opt/simplex/smp-server-stats.daily.log में लिखता है।
• --fqdn आपके domain को जनरेट किए गए certificate में डालता है। यदि आपके पास domain नहीं है, तो --ip का उपयोग करें।
• --no-password किसी को भी आपके relay पर queue बनाने की अनुमति देता है। इसे private रखने के लिए, init के बाद /etc/opt/simplex/smp-server.ini में [AUTH] के अंतर्गत create_password सेट करें, न कि यहाँ --password पास करें। ऐसा इसलिए है क्योंकि command line आपके shell history और process list में दिखाई देती है।

Init एक certificate जनरेट करता है और उन दो values को प्रिंट करता है जिन्हें आपको सुरक्षित रखना होगा। पहली value fingerprint है, जो एक base64 स्ट्रिंग है और इसे /etc/opt/simplex/fingerprint में भी लिखा जाता है। दूसरी value पूर्ण सर्वर पता (full server address) है, जो fingerprint और आपके hostname का संयोजन है। दोनों को अभी कॉपी कर लें।

Init /etc/opt/simplex/ca.key भी बनाता है, और docs आपको उस फ़ाइल को offline storage में ले जाने के लिए कहते हैं। इसका कारण यह है: clients उस certificate authority के fingerprint को पिन करते हैं, इसलिए जिसके पास भी ca.key होगा, वह एक नया सर्वर certificate जारी कर सकता है जिसे आपके clients आपके certificate के रूप में स्वीकार कर लेंगे। आपको बाद में smp-server cert के साथ सर्वर certificate को rotate करने के लिए ही इसकी आवश्यकता होगी।

Init को एक बार की जाने वाली प्रक्रिया (one-time step) मानें। आपके पते में मौजूद fingerprint उस authority से आता है जिसे यह जनरेट करता है, इसलिए उस authority को फिर से जनरेट करने पर आपको एक अलग पता मिलेगा और जो पता आपने पहले दिया था, वह अमान्य हो जाएगा।

इसे एक 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.target

Upstream unit में AmbientCapabilities=CAP_NET_BIND_SERVICE भी शामिल है। यह लाइन इसलिए मौजूद है क्योंकि process smp के रूप में चलती है, और 1024 से नीचे के ports एक non-root process के लिए बंद होते हैं, इसलिए इसके बिना daemon 80 या 443 पर bind नहीं हो सकता। यदि आप उन ports को serve करते हैं तो इसे जोड़ें। 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 बनने से रोकता है।

किन पोर्ट्स को खोलें, और किसे बंद रखें

दस्तावेज़ तीन पोर्ट्स की सूची देते हैं: 5223/tcp, 443/tcp और 80/tcp। पोर्ट 5223 SMP ट्रांसपोर्ट है। शिप की गई कॉन्फ़िगरेशन port: 5223,443 को [TRANSPORT] के अंतर्गत सेट करती है, इसलिए वही प्रोटोकॉल 443 पर भी उत्तर देता है। यह महत्वपूर्ण है क्योंकि कई प्रतिबंधित नेटवर्क केवल आउटबाउंड 443 की अनुमति देते हैं और कुछ भी नहीं। पोर्ट 80 की आवश्यकता केवल वैकल्पिक सूचना पृष्ठ और HTTPS पर इसके रीडायरेक्ट के लिए होती है।

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 5223/tcp
sudo ufw enable

5224 को न खोलें। यह कंट्रोल पोर्ट है, और दस्तावेज़ इसे बॉक्स से ही nc 127.0.0.1 5224 के साथ एक्सेस करने के लिए कहते हैं। यह सर्वर की स्थिति प्रिंट करता है और कतारों (queues) को हटाता है, इसलिए इसे एडमिन और यूजर पासवर्ड के साथ [AUTH] के अंतर्गत लूपबैक पर ही रहना चाहिए। यदि आप इस टूल के लिए नए हैं, तो ufw on a VPS की मूल बातें नियम क्रम और खुद को लॉक आउट होने से बचाने के तरीके को कवर करती हैं।

एक और कंट्रोल अक्सर लोगों को परेशान करता है। अधिकांश प्रदाता पैनल में एक नेटवर्क फ़ायरवॉल चलाते हैं, जो बॉक्स पर मौजूद ufw से अलग होता है। एक पोर्ट ufw में खुला हो सकता है, लेकिन आप तक पहुँचने से पहले ही उसे ड्रॉप किया जा सकता है।

सर्वर पता जिसकी आपके क्लाइंट्स को आवश्यकता है

smp://<fingerprint>[:<password>]@<public_hostname>[,<onion_hostname>]

यह स्ट्रिंग पूरी क्लाइंट-साइड कॉन्फ़िगरेशन है। इसे ऐप की सर्वर सेटिंग्स में पेस्ट करें, या किसी को ऐप द्वारा दिखाए गए QR कोड को स्कैन करने दें। दस्तावेज़ बताते हैं कि QR कोड में पासवर्ड शामिल होता है, इसलिए जो कोई भी इसे स्कैन करता है, वह आपके सर्वर के माध्यम से संदेश प्राप्त कर सकता है।

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

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, सर्वर सर्टिफिकेट और की (key), ca.key, और fingerprint शामिल हैं। /var/opt/simplex/ सर्वर की स्थिति (state) है: 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

यह स्पष्ट रखें कि वह आर्काइव क्या है। यह संदेशों का आर्काइव नहीं है: कतार में मौजूद आइटम उन की (keys) के लिए साइफरटेक्स्ट हैं जिन्हें रिले ने कभी नहीं रखा था, और शिप की गई [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 द्वारा प्रस्तुत certificate उस pinned fingerprint से मेल खाता है या नहीं, जिसे project machine-in-the-middle हमलों के विरुद्ध client-to-server connection की सुरक्षा के रूप में वर्णित करता है। उस 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 इसी उद्देश्य के लिए server के सामने Caddy को रखता है, जो स्वचालित रूप से certificate जारी करता है।

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 पता तेज़ होता है और यह क्लाइंट्स को एक ऐसा रास्ता देता है जो कभी भी उनका IP पता आपके सामने प्रकट नहीं करता है, लेकिन सर्वर स्वयं अपने public IP पर खोजने योग्य बना रहता है। /var/lib/tor/simplex-smp/hostname से प्राप्त onion hostname को सर्वर पते के अंत में अल्पविराम (comma) के बाद लगाया जाता है। यदि आप सर्वर के स्थान को भी छिपाना चाहते हैं, तो वह एक अलग कॉन्फ़िगरेशन है, और VPS पर एक वास्तविक onion service चलाना इस विकल्प को कवर करता है। प्रत्येक टूल क्या छिपाता है, इसमें अंतर VPN के साथ Tor की तुलना का विषय है, और यह यहाँ सीधे लागू होता है।

Threat model: self-hosting से क्या बदलता है

इससे आपको क्या लाभ मिलता है। मेटाडेटा (कौन सी queues मौजूद हैं, उन्हें कब पढ़ा जाता है, कौन से addresses connect होते हैं) उस मशीन पर रहता है जिसे आप नियंत्रित करते हैं, और आप तय करते हैं कि इसे कितने समय तक रखा जाए। आप उस बड़े समूह का हिस्सा भी नहीं होते जिसे एक बार में request किया जा सकता है।

स्पष्ट रूप से, इससे आपको क्या नहीं मिलता:

• Encryption में कोई बदलाव नहीं होता। आपके द्वारा इसे बनाने से पहले भी messages end-to-end encrypted थे और बाद में भी वे end-to-end encrypted ही रहते हैं। Self-hosting एक मेटाडेटा संबंधी निर्णय है, न कि cryptography संबंधी निर्णय।
• आपका VPS provider आपके IP address पर आने वाले traffic को देखता है और आपके billing विवरण रखता है। आपने भरोसे को एक messaging operator से हटाकर एक hosting operator पर स्थानांतरित किया है। आपने इसे समाप्त नहीं किया है।
• आपका relay एक छोटा समूह है। यदि यह एक घर की सेवा करता है, तो इससे connect होना उस घर की पहचान उजागर करता है, और इसका hostname आपके द्वारा भेजे गए प्रत्येक invitation link के अंदर होता है। एक व्यस्त public relay इस एक मामले में आपको बेहतर तरीके से छिपाता है, और यही वास्तविक trade-off है।
• उपलब्धता अब आपकी जिम्मेदारी है। डिस्क फुल होने या सर्वर बंद होने का मतलब है कि messages का delivery रुक जाना, और आपके contacts के पास आपके अलावा किसी अन्य माध्यम से संपर्क करने का कोई रास्ता नहीं होता।

यही तर्क किसी भी ऐसी private service पर लागू होता है जिसे आप अपने सर्वर पर रखते हैं, चाहे वह यह relay हो या आपके अपने VPS पर एक WireGuard VPN। आप यह चुन रहे हैं कि कौन सा पक्ष मेटाडेटा देखेगा। आप इसे गायब नहीं कर रहे हैं।

जब यह काम न करे

Service start होती है और तुरंत बंद हो जाती है। sudo journalctl -u smp-server -n 50 पढ़ें। Bind failure उस port का नाम बताता है जिसे वह प्राप्त नहीं कर सकी। फिर यह देखने के लिए sudo ss -tlnp | grep :443 चलाएँ कि कौन सी process उसे पहले से ही रोके हुए है, जो कि एक नए सर्वर पर आमतौर पर 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 के खुले होने की पुष्टि करता है, तो यह provider के network firewall की समस्या है, जो ufw से अलग एक नियंत्रण है।

कोई contact आपके relay के माध्यम से connect नहीं हो पा रहा है। आपके द्वारा साझा किए गए address में fingerprint का /etc/opt/simplex/fingerprint की वर्तमान सामग्री से मेल खाना आवश्यक है। यदि आपने [AUTH] के अंतर्गत create_password set किया है, तो address में वह password भी होना चाहिए, अन्यथा client को queue बनाने की अनुमति नहीं मिलेगी।

App में सर्वर जोड़ने के बाद कुछ भी move नहीं हुआ। यह जानबूझकर किया गया है। केवल नए contacts ही नए जोड़े गए relay का उपयोग करते हैं। मौजूदा contacts अपनी पुरानी queues का ही उपयोग जारी रखते हैं।

FAQ

क्या SimpleX सर्वर को self-host करने से मेरे संदेश अधिक सुरक्षित हो जाते हैं?

नहीं, और यह डिज़ाइन के अनुसार ही है। SimpleX संदेशों को डिवाइसों के बीच end-to-end encrypt करता है, इसलिए relay के पास कभी भी keys नहीं होतीं, चाहे उसे कोई भी चला रहा हो। Self-hosting केवल यह बदलता है कि उन संदेशों के आसपास के metadata को कौन देख सकता है: कौन सी queues मौजूद हैं, उन्हें कब पढ़ा जाता है, और कौन से IP addresses connect हो रहे हैं। यह metadata से जुड़ा निर्णय है। यदि आप बेहतर encryption के लिए self-hosting कर रहे हैं, तो 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 की आवश्यकता है?

एक उपयोगी setup के लिए आपको 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 को निर्देशों के अनुसार offline store करें, क्योंकि जिसके पास यह होगा वह आपके relay का रूप धारण कर सकता है।

क्या मैं SMP relay और XFTP file relay को एक ही VPS पर चला सकता हूँ?

हाँ, लेकिन एक conflict को सुलझाना होगा। XFTP server का निर्धारित port 443 है और default SMP config में port: 5223,443 सूचीबद्ध है, इसलिए दोनों एक ही socket चाहते हैं। इनमें से किसी एक को 443 दें: SMP server के लिए port: 5223 set करें, या file relay को दूसरे IP address या दूसरे VPS पर ले जाएँ। साथ ही, storage quota को अपनी वास्तविक disk capacity के अनुसार रखें, क्योंकि file relay ही वह component है जो disk और bandwidth का उपयोग करता है।