Stalwart में Calendar, Contacts और Files के लिए JMAP जोड़ा गया

 (stalw.art)
4 पॉइंट द्वारा GN⁺ 2025-10-24 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • ओपन सोर्स collaboration server Stalwart ने 4 साल के विकास के बाद Calendar, Contacts, File storage और sharing के लिए JMAP का पूर्ण implementation पूरा कर एक नया milestone हासिल किया
  • इस रिलीज़ के साथ Stalwart पूरे JMAP protocol suite को पूरी तरह support करने वाला पहला server बन गया है, और email से आगे बढ़कर व्यापक collaboration के लिए एक unified API प्रदान करता है
  • JSON-आधारित single framework के जरिए यह मौजूदा WebDAV·CalDAV·CardDAV की जटिलता और inefficiency की जगह लेता है, और developer-friendly structure उपलब्ध कराता है
  • नए JSCalendar और JSContact formats iCalendar और vCard की जटिलता को हटाकर एक स्पष्ट और consistent data model प्रदान करते हैं
  • यह open standards-आधारित collaboration technology के विकास का प्रतीक है, और आगे calendaring·file sharing·mail integration ecosystem में innovation की रफ्तार तेज होने का संकेत देता है

नई पीढ़ी के प्रोटोकॉल

  • पिछले कुछ वर्षों में IETF email, calendar और contacts के synchronization और sharing के तरीकों को फिर से परिभाषित कर रहा है
    • मौजूदा JMAP for Mail की सफलता के आधार पर, calendars·contacts·files·sharing के लिए नए extension protocols पेश किए गए हैं
    • JMAP for Calendars - CalDAV और CalDAV scheduling का आधुनिक विकल्प
    • JMAP for Contacts – CardDAV का मजबूत विकल्प
    • JMAP for File Storage – WebDAV-आधारित file storage की जगह लेने के लिए
    • JMAP Sharing – WebDAV ACL का आधुनिक उत्तराधिकारी
    • JSCalendar - साफ-सुथरे JSON-आधारित रूप में विकसित iCalendar
    • JSContact – vCard का आधुनिक JSON-आधारित उत्तराधिकारी
  • ये standards बिखरी हुई WebDAV-आधारित technologies की जगह एक unified और elegant ecosystem प्रदान करते हैं
    • दशकों पुराने compatibility issues को हल करते हैं, और एक single data model के साथ collaboration features को सरल बनाते हैं

मौजूदा तकनीकों की सीमाएँ

  • WebDAV, CalDAV, CardDAV जैसी तकनीकों का लंबे समय से स्थिर रूप से उपयोग होता आया है, लेकिन XML-आधारित design के कारण वे अत्यधिक verbose और inconsistent हैं
    • data HTTP headers, XML payloads और iCalendar data जैसी कई जगहों में बिखरा रहता है, जिससे client और server के बीच interoperability problems बार-बार सामने आते हैं
  • iCalendar और vCard भी दशकों का technical debt ढो रहे हैं
    • इनमें कम उपयोग होने वाले या deprecated properties बहुत हैं, और version के अनुसार implementations में असंगति होने से complex parsing logic की जरूरत पड़ती है
  • यह structural complexity maintenance और scalability को बाधित करती है, और आधुनिक collaboration environments के लिए उपयुक्त नहीं रह गई है

आधुनिक जरूरतों के लिए JMAP का आगमन

  • JMAP protocol मूल रूप से IMAP और SMTP को बदलने के लिए विकसित किया गया एक efficient और simple mail transport protocol है
    • JSON over HTTPS के आधार पर यह clarity और network efficiency दोनों सुनिश्चित करता है
  • अब JMAP for Calendars, Contacts, Files, Sharing के आने से यही design philosophy पूरे collaboration stack तक फैल गई है
    • mail, calendar, contacts, files और shared resources के लिए unified और consistent API प्रदान किया जाता है
  • JSCalendar और JSContact मौजूदा iCalendar और vCard को JSON-आधारित formats के रूप में फिर से निर्मित करते हैं
    • अनावश्यक properties को हटाकर एक स्पष्ट और consistent data model देते हैं
    • ये पढ़ने में आसान, developer-friendly और parsing में efficient हैं, इसलिए आधुनिक applications के लिए optimized हैं
  • JMAP और इन नए data models का संयोजन calendaring, contact management और file sharing को और तेज़ और अधिक reliable तरीके से implement करना संभव बनाता है

इस रिलीज़ का महत्व

  • यह रिलीज़ सिर्फ एक feature addition नहीं, बल्कि groupware protocol design के तरीके में एक turning point है
    • developer और organizations अब mail, contacts, calendar और shared resources को single JSON-आधारित framework पर बना सकते हैं
  • JMAP की simplicity और predictability client और server को protocol handling के बजाय features और user experience पर ध्यान केंद्रित करने में मदद करती है
  • नतीजतन interoperability problems में कमी, development speed में सुधार, और innovation में तेजी की उम्मीद है
    • यह collaboration software के पूरे क्षेत्र में standardization और efficiency improvement को बढ़ावा देने का एक अवसर है

क्लाइंट सपोर्ट और ecosystem का विस्तार

  • Stalwart फिलहाल पूरे JMAP protocol suite को पूरी तरह support करने वाला पहला server है, जबकि client support अभी शुरुआती चरण में है
  • फिर भी कई projects पहले ही नए standards अपना रहे हैं
    • Mailtemi, Parula, OpenCloud आदि JMAP Calendars, Contacts, File Storage clients विकसित कर रहे हैं
  • ecosystem तेज़ी से बढ़ रहा है, और जैसे-जैसे developers JMAP की elegance और power को सीधे अनुभव करेंगे, तेज़ adoption की उम्मीद है

संबंधित पढ़ाई

2 टिप्पणियां

 
t7vonn 2025-10-24

अच्छा है!!
 
GN⁺ 2025-10-24
Hacker News टिप्पणियाँ
  • मेरी नज़र में Stalwart एक बेहतरीन JMAP सर्वर है
    मुझे लगता है कि JMAP ईमेल क्लाइंट बनाने के लिए बहुत अच्छा प्रोटोकॉल है
    मैं खुद होस्टिंग से बचना चाहता हूँ, लेकिन अगर Stalwart को क्लाइंट के सर्वर कॉम्पोनेंट के रूप में इस्तेमाल करके मौजूदा IMAP डेटा sync किया जा सके और JMAP API के ज़रिए उसे access किया जा सके, तो यह काफ़ी दिलचस्प होगा
    सुना है कि IMAP-IMAP sync जैसी व्यवस्था संभव है, तो जानना चाहूँगा कि क्या किसी ने इसे Stalwart के साथ आज़माया है
    अगर यह तरीका संभव हो जाए, तो मौजूदा IMAP mailbox को JMAP के ज़रिए access किया जा सकेगा, और इससे नई पीढ़ी के ईमेल क्लाइंट के विकास को बढ़ावा मिल सकता है
    • मैं यह रेखांकित करना चाहता हूँ कि “excellent” कहना कोई अतिशयोक्ति नहीं है
      Stalwart सच में बेहद खूबसूरती से संरचित सॉफ़्टवेयर है
      जिस तरह इसने भरोसा बनाते हुए धीरे-धीरे अपनी परिपक्वता बढ़ाई है, वह प्रभावशाली है
      और यह तथ्य कि इसे लगभग एक ही डेवलपर ने आगे बढ़ाया है, वाकई हैरान करता है
      GitHub योगदानकर्ता ग्राफ़
    • IMAP ↔ IMAP sync टूल mbsync का इस्तेमाल करें, तो यह आसानी से किया जा सकता है
      रिमोट IMAP को Stalwart के लोकल IMAP सर्वर से नियमित रूप से sync कर दें, फिर Stalwart उसे अंदरूनी तौर पर JMAP में बदलकर उपलब्ध करा देता है
      पहले लगा था कि maildir चरण से होकर जाना पड़ेगा, लेकिन लगता है कि सिर्फ़ IMAP ↔ IMAP से ही काम हो सकता है
    • मैं लंबे समय से ऐसी किसी चीज़ का इंतज़ार कर रहा था
      अब तक जो मिला वह बहुत महँगा था, इसलिए यह प्रगति स्वागतयोग्य है
    • मैं भी ठीक इसी वजह से सोच-विचार कर रहा था
      अभी कोई नतीजा नहीं निकला है, लेकिन इस पर लगातार विचार कर रहा हूँ
  • मैं “कोई क्लाइंट नहीं है” जैसी बात बहुत देखता हूँ, लेकिन स्वाभाविक है कि सर्वर implementation पहले आना चाहिए
    Stalwart व्यावहारिक रूप से JMAP का पहला सर्वर implementation है, इसलिए अब क्लाइंट बनाने की वजह पैदा हुई है
    वैसे Mozilla की नई मेल सेवा भी JMAP का इस्तेमाल करने वाली है, इसलिए लगता है कि इससे बड़ा momentum मिलेगा
    • मुझे लगता है कि Stalwart सच में game changer बन सकता है
      पहले मैंने Nextcloud या SoGo जैसे groupware इस्तेमाल किए थे, लेकिन उनसे निराशा हुई
      लेकिन अब Nextcloud, Stalwart के साथ सहयोग कर रहा है, और Opencloud तथा Mozilla/Thunderbird भी JMAP integration पर काम कर रहे हैं, इसलिए उम्मीद बढ़ी है
      खास तौर पर Thunderbird का webmail प्रोजेक्ट Stormbox भी चल रहा है, जो दिलचस्प है
      अभी Big Tech से दूर जाने की प्रवृत्ति मज़बूत है, इसलिए timing भी एकदम सही है
    • जानकारी के लिए, Stalwart वह पहला सर्वर है जिसने JMAP के contacts और calendar implement किए हैं
      Cyrus सिर्फ़ JMAP mail को support करता था
    • FastMail पहले से ही JMAP को प्रोडक्शन सेवा में इस्तेमाल कर रहा है, और RFC का सह-लेखक भी है
    • हाल ही में मैंने Pimsync में JMAP calendar sync implement किया है
      अब CalDAV, JMAP और filesystem के बीच sync संभव है
    • JMAP क्लाइंट मौजूद हैं
      मैं aerc नाम का क्लाइंट इस्तेमाल कर रहा हूँ
  • वेब API design के नज़रिए से JMAP आकर्षक है, लेकिन यह सवाल बना रहता है कि क्या हर नया प्रोटोकॉल सिर्फ़ HTTP के ऊपर ही बनाया जाना चाहिए
    file sharing, groupware, mail, calendar जैसी चीज़ें शायद JSON overhead के बिना और ज़्यादा efficient तरीके से डिज़ाइन की जा सकती हैं
    फिर भी HTTP-आधारित design के पीछे निश्चित ही कुछ ठोस वजहें होंगी
    • ईमेल मूल रूप से binary protocol नहीं था
      शुरुआती इंटरनेट प्रोटोकॉल ज़्यादातर text-based Telnet के ऊपर बने थे
      HTTP/3 अपने स्वभाव में binary protocol है, और JSON structured है तथा compression efficiency भी अच्छी देता है, इसलिए व्यवहार में यह काफ़ी efficient है
      “JSON over HTTP”, “custom text over telnet” की तुलना में सूक्ष्म लेकिन स्पष्ट सुधार है
    • अगर आप खुद का serialization format बनाते हैं, तो अक्सर समस्याएँ और बढ़ती हैं
      capnproto, grpc, ASN.1 जैसे framework इस्तेमाल करें तब भी हर एक की अपनी जटिलता है
      JSON सरल है और इसकी सीमाएँ साफ़ हैं, इसलिए इसे संभालना आसान है
      इसके उलट Microsoft Exchange protocol जैसे implementation-dependent design लंबे समय में समस्याएँ पैदा करते हैं
    • HTTP के ऊपर बनाना हमेशा अच्छा हो, ऐसा नहीं है
      कुछ मामलों में TCP के अलावा कोई और protocol ज़्यादा बेहतर हो सकता है
      निजी तौर पर मुझे JSON पसंद नहीं है, और मैं DER format को बेहतर मानता हूँ
      Gemini, Scorpion जैसे “small web” protocol भी दिलचस्प हैं
    • HTTP के ज़रिए ईमेल लाने में overhead बहुत बड़ा नहीं है
      बल्कि web client compatibility के लिहाज़ से HTTP ही लगभग एकमात्र विकल्प है
      मुझे नहीं लगता कि HTTP न इस्तेमाल करने का कोई खास लाभ है
    • HTTP/2 और HTTP/3 पहले से ही binary protocol हैं
      JSON की जगह CBOR इस्तेमाल करें, तो payload भी binary बनाया जा सकता है
      HTTP एक state transfer protocol है, इसलिए sync के लिए उपयुक्त है
      इसमें Braid extension जोड़ दें, तो इसे state synchronization protocol तक बढ़ाया जा सकता है
      मैं Braid प्रोजेक्ट में काम करता हूँ
  • उम्मीद है Fastmail JMAP के calendar और contacts हिस्से को जल्दी implement करेगा
    mail का support पहले से है, लेकिन अभी भी CardDAV/CalDAV साथ में चलाना पड़ता है
    • अभी अंदरूनी तौर पर JMAP का पुराना version इस्तेमाल हो रहा है
      10 साल पहले लिखा गया caldav_sync code अभी भी चल रहा है
      हाल में objectid generation logic बेहतर किया गया है ताकि ID का आकार घटे और sorting बेहतर हो
      अब calendar और contacts को नवीनतम JMAP spec के अनुसार update किया जाएगा
      filesystem में शायद थोड़ा और समय लगेगा
    • JMAP Calendar spec को अभी औपचारिक मंज़ूरी नहीं मिली है
      draft document देखें
      Contacts को RFC 9610 के रूप में 10 महीने पहले मंज़ूरी मिली थी
    • अगर Thunderbird, K-9 Mail, iPhone mail app जैसे प्रमुख क्लाइंट support नहीं करते, तो JMAP का फैलना मुश्किल होगा
      और मौजूदा समाधानों की तुलना में यह कौन-सी समस्या हल करता है, यह भी स्पष्ट नहीं है
  • JMAP एक अच्छा protocol है, लेकिन client support कमज़ोर है
    Apple Mail, Thunderbird, Outlook जैसे बड़े क्लाइंट को इसे support करना होगा
    Canary या Spark जैसे छोटे क्लाइंट इसे differentiation point के तौर पर अपना सकते थे, लेकिन हैरानी की बात है कि ऐसा नहीं हुआ
    • Outlook पहले से ही MS365-only दिशा में बदल रहा है
      नया Outlook सारा डेटा Azure में स्टोर करता है और असली सर्वर से proxy के ज़रिए बात करता है
      उसके JMAP support करने की संभावना लगभग नहीं है
    • JMAP webmail जैसे thin client के लिए अच्छा है, लेकिन local state स्टोर करने वाले desktop app के लिए इसका बहुत बड़ा फ़ायदा नहीं है
    • अगर बड़े mail provider support नहीं करते, तो JMAP की अलग पहचान कमज़ोर पड़ जाती है
      (मैं IMAP का बचाव नहीं कर रहा)
    • पहले server support चाहिए
      Gmail या iCloud support न करें, तो क्लाइंट बनाना भी बहुत मायने नहीं रखता
      dual support संभव है, लेकिन बाज़ार छोटा है
    • JMAP को सफल होना है, तो इसे mail से आगे बढ़कर calendar, contacts, file sharing जैसी चीज़ों वाला एकीकृत groupware protocol बनना होगा
      लेकिन वह अभी बहुत सारी “if” वाली बात है
  • Stalwart की वजह से ईमेल self-hosting बहुत आसान हो गई है
    यह पूरी तरह integrated server है, इसलिए लगता है जैसे एक नया दौर शुरू हो गया हो
    Maddy भी ठीक है, लेकिन उसका maintenance उतना सक्रिय नहीं है
    • मैं भी Maddy+Postfix+Dovecot+Rspamd सेटअप से Stalwart पर migrate कर रहा हूँ, और मुझे लगता है कि documentation quality कमज़ोर है
      options, default values और उनके आपसी संबंधों को एक नज़र में दिखाने वाला documentation नहीं है
      Web UI configuration संभव है, लेकिन यह declarative deployment से टकराता है
      अगर .toml फ़ाइल read-only हो, तो error आता है
    • जानना चाहूँगा कि कोई उपयोगी JMAP webmail client है या नहीं
      FastMail या Topicbox के अलावा कुछ ख़ास नहीं दिखता
      Roundcube या Wildduck की तरह HTTPS पर self-host किया जा सकने वाला कुछ चाहिए
    • समझ नहीं आता कि Postfix+Dovecot की तुलना में इसका वास्तविक फ़ायदा क्या है
      “इसे Rust में दोबारा लिखा गया है” के अलावा कोई स्पष्ट अंतर नज़र नहीं आता
  • चिंता है कि कहीं Sieve को JSON-आधारित किसी चीज़ से बदलने की कोशिश तो नहीं हो रही
    अच्छे MUA (mail client) के बिना JMAP कितना मददगार होगा, यह भी स्पष्ट नहीं है
    server को तो पहले से हल की हुई समस्या माना जाता है, लेकिन client ठहरे हुए हैं
    IMAP4 की क्षमताओं तक का ज़्यादातर हिस्सा लागू नहीं हुआ, और Sieve client भी बहुत कमजोर हैं
    • मैं “server हल की हुई समस्या है” इस बात से सहमत नहीं हूँ
      Dovecot अभी तक UTF-8 को भी पूरी तरह support नहीं करता
      Stalwart जैसे प्रोजेक्ट ऐसी legacy limitations को पार करने की कोशिश हैं
      client पक्ष पर भी Apple Mail जैसे बेहतर हुए उदाहरण मौजूद हैं
    • अंत में server और client दोनों चाहिए
      सिर्फ़ एक पक्ष के आगे बढ़ने से बात नहीं बनेगी
      अब जबकि अच्छा server आ गया है, अगला कदम अच्छे client हैं
  • अगर Google Workspace या Outlook environment में JMAP-style JSON API चाहिए, तो Nylas एक विकल्प हो सकता है
    Nylas ताकतवर है, लेकिन महँगा भी है
    बड़े पैमाने पर यह प्रति account प्रति माह $1.50 पड़ता है, जो SaaS margin को प्रभावित कर सकता है
    फिर भी real-time email analysis या custom UI बनाने में यह बहुत उपयोगी है
  • मैंने Stalwart install करके देखा, और web server तथा mail server integrated हैं