เพิ่ม JMAP สำหรับปฏิทิน รายชื่อติดต่อ และไฟล์ใน Stalwart

 (stalw.art)
4 คะแนน โดย GN⁺ 2025-10-24 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • เซิร์ฟเวอร์ทำงานร่วมกันแบบโอเพนซอร์ส Stalwart บรรลุหมุดหมายใหม่หลังพัฒนามา 4 ปี ด้วยการติดตั้งใช้งาน JMAP สำหรับปฏิทิน รายชื่อติดต่อ การจัดเก็บและการแชร์ไฟล์ ได้อย่างสมบูรณ์
  • รีลีสนี้ทำให้ Stalwart กลายเป็น เซิร์ฟเวอร์ตัวแรกที่รองรับชุดโปรโตคอล JMAP ได้ครบถ้วนทั้งหมด และมอบ API แบบรวมศูนย์ที่ขยายจากอีเมลไปสู่การทำงานร่วมกันโดยรวม
  • ผ่าน เฟรมเวิร์กเดียวที่อิง JSON จึงเข้ามาแทนที่ความซับซ้อนและความไม่มีประสิทธิภาพของ WebDAV·CalDAV·CardDAV แบบเดิม พร้อมโครงสร้างที่เป็นมิตรกับนักพัฒนา
  • ฟอร์แมต JSCalendar และ JSContact ใหม่ ช่วยตัดความซับซ้อนของ iCalendar และ vCard ออกไป พร้อมมอบโมเดลข้อมูลที่ชัดเจนและสอดคล้องกัน
  • นี่เป็นสัญลักษณ์ของวิวัฒนาการด้านเทคโนโลยีการทำงานร่วมกันบนมาตรฐานเปิด และส่งสัญญาณว่า นวัตกรรมในระบบนิเวศการรวมปฏิทิน·การแชร์ไฟล์·อีเมล จะเร่งตัวขึ้น

โปรโตคอลยุคใหม่

  • ในช่วงไม่กี่ปีที่ผ่านมา IETF กำลังนิยามวิธีซิงก์และแชร์อีเมล ปฏิทิน และรายชื่อติดต่อขึ้นใหม่
    • จากความสำเร็จของ JMAP for Mail เดิม ได้มีการเพิ่มโปรโตคอลส่วนขยายใหม่สำหรับปฏิทิน รายชื่อติดต่อ ไฟล์ และการแชร์
    • JMAP for Calendars - ทางเลือกสมัยใหม่แทน CalDAV และ CalDAV scheduling
    • JMAP for Contacts – ตัวแทน CardDAV ที่ทรงพลัง
    • JMAP for File Storage – ใช้แทนที่ระบบจัดเก็บไฟล์บน WebDAV
    • JMAP Sharing – ผู้สืบทอดสมัยใหม่ของ WebDAV ACL
    • JSCalendar - iCalendar เวอร์ชันพัฒนาใหม่บนพื้นฐาน JSON ที่สะอาดกว่า
    • JSContact – ผู้สืบทอด vCard แบบ JSON ที่ถูกทำให้ทันสมัย
  • มาตรฐานเหล่านี้มอบระบบนิเวศแบบบูรณาการที่เรียบหรู เพื่อแทนที่ เทคโนโลยีบน WebDAV ที่แยกส่วน
    • ช่วยแก้ปัญหาความเข้ากันได้ที่สะสมมาหลายทศวรรษ และทำให้ฟังก์ชันการทำงานร่วมกันง่ายขึ้นด้วยโมเดลข้อมูลเดียว

ข้อจำกัดของเทคโนโลยีเดิม

  • WebDAV, CalDAV, CardDAV ถูกใช้งานอย่างเสถียรมายาวนาน แต่ด้วยการออกแบบที่อิง XML จึงมีความเยิ่นเย้อเกินไปและขาดความสอดคล้อง
    • ข้อมูลกระจัดกระจายอยู่ทั้งใน HTTP header, XML payload, ข้อมูล iCalendar และตำแหน่งอื่น ๆ ทำให้เกิด ปัญหาการทำงานร่วมกันได้ ระหว่างไคลเอนต์กับเซิร์ฟเวอร์อยู่บ่อยครั้ง
  • iCalendar และ vCard เองก็แบกรับหนี้ทางเทคนิคที่สะสมมาหลายสิบปี
    • มีพร็อพเพอร์ตีจำนวนมากที่แทบไม่ได้ใช้หรือถูกเลิกใช้ไปแล้ว และการติดตั้งใช้งานในแต่ละเวอร์ชันก็ไม่ตรงกัน จึงต้องใช้ ตรรกะการพาร์สที่ซับซ้อน
  • ความซับซ้อนเชิงโครงสร้างเหล่านี้เป็นอุปสรรคต่อการบำรุงรักษาและการขยายระบบ ทำให้ไม่เหมาะกับสภาพแวดล้อมการทำงานร่วมกันสมัยใหม่

การมาถึงของ JMAP ที่ตอบโจทย์ยุคใหม่

  • เดิมที โปรโตคอล JMAP ถูกพัฒนาขึ้นเพื่อแทนที่ IMAP และ SMTP ในฐานะโปรโตคอลรับส่งอีเมลที่มีประสิทธิภาพและเรียบง่าย
    • ด้วยพื้นฐาน JSON over HTTPS จึงได้ทั้งความชัดเจนและประสิทธิภาพด้านเครือข่าย
  • ตอนนี้เมื่อมี JMAP for Calendars, Contacts, Files, Sharing เข้ามา ปรัชญาการออกแบบเดียวกันนี้ก็ได้ขยายไปสู่การทำงานร่วมกันทั้งระบบ
    • มอบ API ที่เป็นหนึ่งเดียวและสอดคล้องกัน สำหรับอีเมล ปฏิทิน รายชื่อติดต่อ ไฟล์ และทรัพยากรที่แชร์
  • JSCalendar และ JSContact คือการปรับโครงสร้าง iCalendar และ vCard เดิมใหม่ให้อยู่ใน ฟอร์แมตที่อิง JSON
    • ตัดพร็อพเพอร์ตีที่ไม่จำเป็นออก และให้โมเดลข้อมูลที่ชัดเจนสอดคล้องกัน
    • อ่านได้ง่าย เป็นมิตรกับนักพัฒนา และพาร์สได้อย่างมีประสิทธิภาพสูง จึง เหมาะกับแอปพลิเคชันสมัยใหม่
  • การผสานกันของ JMAP กับโมเดลข้อมูลใหม่นี้ ช่วยให้การทำระบบปฏิทิน การจัดการรายชื่อติดต่อ และการแชร์ไฟล์ ทำได้รวดเร็วและเชื่อถือได้มากขึ้น

ความหมายของรีลีสครั้งนี้

  • รีลีสนี้ไม่ได้เป็นเพียงการเพิ่มฟีเจอร์ แต่ยังหมายถึง จุดเปลี่ยนของแนวทางการออกแบบโปรโตคอลกรุ๊ปแวร์
    • นักพัฒนาและองค์กรสามารถสร้างระบบอีเมล รายชื่อติดต่อ ปฏิทิน และทรัพยากรที่แชร์ บน เฟรมเวิร์กเดียวที่อิง JSON ได้
  • ความเรียบง่ายและคาดเดาได้ของ JMAP ช่วยให้ไคลเอนต์และเซิร์ฟเวอร์โฟกัสกับฟีเจอร์และประสบการณ์ผู้ใช้ แทนการเสียเวลาไปกับการจัดการโปรโตคอล
  • ผลลัพธ์ที่คาดหวังคือ ปัญหาการทำงานร่วมกันได้ลดลง, ความเร็วในการพัฒนาเพิ่มขึ้น, และ นวัตกรรมเร่งตัวขึ้น
    • สิ่งนี้จะเป็นแรงผลักดันให้เกิด มาตรฐานและประสิทธิภาพที่ดีขึ้น ในซอฟต์แวร์สำหรับการทำงานร่วมกันโดยรวม

การรองรับฝั่งไคลเอนต์และการขยายตัวของระบบนิเวศ

  • ปัจจุบัน Stalwart คือ เซิร์ฟเวอร์ตัวแรกที่รองรับชุดโปรโตคอล JMAP ได้ครบถ้วนทั้งหมด โดยการรองรับฝั่งไคลเอนต์ยังอยู่ในระยะเริ่มต้น
  • อย่างไรก็ตาม มีหลายโครงการเริ่มนำมาตรฐานใหม่นี้ไปใช้แล้ว
    • Mailtemi, Parula, OpenCloud กำลังพัฒนาไคลเอนต์สำหรับ JMAP Calendars, Contacts, File Storage
  • ระบบนิเวศกำลังเติบโตอย่างรวดเร็ว และเมื่อเหล่านักพัฒนาได้สัมผัส ความเรียบหรูและทรงพลัง ของ JMAP ด้วยตนเอง ก็มีแนวโน้มว่าจะ แพร่หลายอย่างรวดเร็ว

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
t7vonn 2025-10-24

ดีเลย!!
 
GN⁺ 2025-10-24
ความคิดเห็นใน Hacker News
  • ในมุมมองของผม Stalwart เป็น เซิร์ฟเวอร์ JMAP ที่ยอดเยี่ยม
    ผมคิดว่า JMAP เป็นโปรโตคอลที่ดีมากสำหรับการสร้างไคลเอนต์อีเมล
    ผมไม่อยากโฮสต์เองโดยตรง แต่ถ้าใช้ Stalwart เป็นคอมโพเนนต์ฝั่งเซิร์ฟเวอร์ของไคลเอนต์ เพื่อซิงก์ข้อมูล IMAP เดิมและเข้าถึงผ่าน JMAP API ได้ ก็น่าสนใจมาก
    ได้ยินมาว่าทำแบบ IMAP-to-IMAP sync ได้ เลยสงสัยว่ามีใครลองกับ Stalwart บ้างไหม
    ถ้าทำแนวทางนี้ได้ ก็จะเปิดให้เข้าถึงเมลบ็อกซ์ IMAP เดิมผ่าน JMAP และน่าจะช่วยเร่งการพัฒนาไคลเอนต์อีเมลยุคใหม่ได้
    • อยากเน้นว่าคำว่า “excellent” ไม่ได้พูดเกินจริง
      Stalwart เป็น ซอฟต์แวร์ที่มีโครงสร้างงดงามมาก
      น่าประทับใจตรงที่ค่อยๆ สร้างความน่าเชื่อถือและพัฒนาความสมบูรณ์ขึ้นมาอย่างต่อเนื่อง
      แถมยังน่าทึ่งที่แทบจะมี นักพัฒนาเพียงคนเดียว เป็นแกนหลัก
      กราฟผู้มีส่วนร่วมบน GitHub
    • ถ้าใช้ mbsync ซึ่งเป็นเครื่องมือซิงก์ IMAP ↔ IMAP ก็ทำได้ค่อนข้างง่าย
      ซิงก์ IMAP ระยะไกลเข้ากับ IMAP เซิร์ฟเวอร์ภายในของ Stalwart เป็นระยะ แล้ว Stalwart ก็จะแปลงให้เป็น JMAP ภายในและเปิดให้ใช้งาน
      ตอนแรกผมนึกว่าต้องผ่านขั้น maildir ก่อน แต่ดูแล้ว IMAP ↔ IMAP อย่างเดียวก็น่าจะพอ
    • รอสิ่งนี้มานานแล้ว
      สิ่งที่หาเจอก่อนหน้านี้แพงเกินไป เลยยินดีที่เห็นความคืบหน้าแบบนี้
    • ผมก็คิดเรื่องนี้อยู่ด้วยเหตุผลเดียวกัน
      ยังไม่มีผลงานออกมา แต่ก็ยังคิดต่ออยู่
  • เห็นหลายคนพูดว่า “ไม่มีไคลเอนต์” แต่แน่นอนว่า ต้องมีเซิร์ฟเวอร์อิมพลีเมนต์ก่อน
    Stalwart แทบจะเป็นอิมพลีเมนต์เซิร์ฟเวอร์ตัวแรกของ JMAP ดังนั้นตอนนี้จึงเริ่มมีเหตุผลให้สร้างไคลเอนต์แล้ว
    อีกอย่าง บริการเมลใหม่ของ Mozilla ก็มีแผนจะใช้ JMAP ด้วย น่าจะเป็น แรงผลักดัน สำคัญ
    • ผมคิดว่า Stalwart อาจเป็น ตัวเปลี่ยนเกม ได้จริง
      เมื่อก่อนเคยลองกรุ๊ปแวร์อย่าง Nextcloud หรือ SoGo แต่ก็ผิดหวัง
      แต่ตอนนี้ Nextcloud กำลังร่วมมือกับ Stalwart และ Opencloud กับ Mozilla/Thunderbird ก็กำลังรวม JMAP เข้าไป เลยน่าคาดหวัง
      โดยเฉพาะ โปรเจ็กต์เว็บเมล Stormbox ของ Thunderbird ก็น่าสนใจ
      ตอนนี้กระแสการย้ายออกจาก Big Tech กำลังแรง จังหวะเลยเหมาะมาก
    • สำหรับข้อมูลเพิ่มเติม Stalwart เป็นเซิร์ฟเวอร์ตัวแรกที่อิมพลีเมนต์ รายชื่อผู้ติดต่อและปฏิทิน ของ JMAP
      Cyrus รองรับแค่ JMAP mail
    • FastMail ใช้ JMAP ในบริการจริง อยู่แล้ว และยังเป็นผู้ร่วมเขียน RFC ด้วย
    • ช่วงนี้ผมเพิ่งอิมพลีเมนต์การซิงก์ปฏิทิน JMAP ใน Pimsync
      ตอนนี้จึงซิงก์ระหว่าง CalDAV, JMAP และระบบไฟล์ได้แล้ว
    • มีไคลเอนต์ JMAP อยู่แล้ว
      ผมใช้ไคลเอนต์ชื่อ aerc
  • JMAP น่าสนใจในแง่การออกแบบเว็บ API แต่ก็ยังสงสัยว่าโปรโตคอลใหม่ทุกอย่างจำเป็นต้องสร้างบน HTTP เท่านั้นหรือไม่
    อย่างการแชร์ไฟล์ กรุ๊ปแวร์ เมล ปฏิทิน น่าจะออกแบบให้มีประสิทธิภาพกว่านี้ได้โดยไม่ต้องมี overhead ของ JSON
    ถึงอย่างนั้นก็คงมีเหตุผลชัดเจนที่เลือกออกแบบบน HTTP
    • เดิมทีอีเมลก็ ไม่ใช่ไบนารีโปรโตคอล อยู่แล้ว
      เพราะโปรโตคอลอินเทอร์เน็ตยุคแรกๆ ส่วนใหญ่สร้างบน Telnet แบบข้อความ
      HTTP/3 โดยเนื้อแท้เป็นไบนารีโปรโตคอล และ JSON ก็มีโครงสร้างชัดเจนกับบีบอัดได้ดี จึงถือว่ามีประสิทธิภาพพอสมควร
      “JSON over HTTP” เป็นการปรับปรุงที่เล็กน้อยแต่ชัดเจน เมื่อเทียบกับ “custom text over telnet”
    • ถ้าสร้าง serialization format เอง ปัญหามักจะยิ่งเพิ่ม
      ถึงจะใช้เฟรมเวิร์กอย่าง capnproto, grpc, ASN.1 ก็มีความซับซ้อนของแต่ละแบบอยู่ดี
      JSON เรียบง่ายและข้อจำกัดก็ชัดเจน เลยจัดการได้ง่าย
      ในทางกลับกัน การออกแบบที่ผูกติดกับ implementation แบบโปรโตคอล Microsoft Exchange มักสร้างปัญหาในระยะยาว
    • การวางบน HTTP ไม่ได้ดีเสมอไป
      บางกรณีโปรโตคอลอื่นที่ไม่ใช่ TCP อาจเหมาะกว่า
      ส่วนตัวผมไม่ชอบ JSON และคิดว่า ฟอร์แมต DER ดีกว่า
      โปรโตคอล “small web” อย่าง Gemini หรือ Scorpion ก็น่าสนใจ
    • overhead ของการดึงอีเมลผ่าน HTTP ไม่ได้มากนัก
      ตรงกันข้าม ในแง่ความเข้ากันได้กับเว็บไคลเอนต์ HTTP แทบเป็นตัวเลือกเดียว
      ผมมองว่าแทบไม่มีข้อดีอะไรในการไม่ใช้ HTTP
    • HTTP/2 และ HTTP/3 ก็เป็น ไบนารีโปรโตคอล อยู่แล้ว
      ถ้าใช้ CBOR แทน JSON ก็ทำให้ payload เป็นไบนารีได้ด้วย
      HTTP เป็นโปรโตคอลสำหรับ การถ่ายโอนสถานะ (state transfer) จึงเหมาะกับการซิงก์
      และถ้าเพิ่ม ส่วนขยาย Braid ก็สามารถขยายให้เป็นโปรโตคอล การซิงโครไนซ์สถานะ (state synchronization) ได้
      ผมทำงานอยู่ในโปรเจ็กต์ Braid
  • อยากให้ Fastmail รีบอิมพลีเมนต์ส่วน ปฏิทินและรายชื่อผู้ติดต่อ ของ JMAP
    เมลรองรับแล้ว แต่ตอนนี้ยังต้องใช้ CardDAV/CalDAV ควบคู่กันไป
    • ตอนนี้ภายในยังใช้ JMAP เวอร์ชันเก่าอยู่
      โค้ด caldav_sync ที่เขียนไว้เมื่อ 10 ปีก่อนยังทำงานอยู่
      ช่วงนี้เราเพิ่งปรับปรุง logic การสร้าง objectid ให้ ID สั้นลงและเรียงลำดับได้ดีขึ้น
      ต่อไปก็จะอัปเดตปฏิทินและรายชื่อผู้ติดต่อให้เป็น JMAP สเปกใหม่ล่าสุด
      ส่วนระบบไฟล์น่าจะใช้เวลาอีกหน่อย
    • สเปก JMAP Calendar ยัง ไม่ได้รับการอนุมัติอย่างเป็นทางการ
      ดูได้ที่ร่างเอกสาร
      ส่วน Contacts ได้รับอนุมัติเป็น RFC 9610 เมื่อ 10 เดือนก่อน
    • ถ้าไคลเอนต์หลักอย่าง Thunderbird, K-9 Mail, แอปเมลบน iPhone ฯลฯ ไม่รองรับ JMAP ก็คงยากที่จะขยายวง
      และก็ยังไม่ชัดว่ามันแก้ปัญหาอะไรได้ดีกว่าโซลูชันเดิม
  • JMAP เป็นโปรโตคอลที่ดี แต่ยังขาด การรองรับฝั่งไคลเอนต์
    ไคลเอนต์หลักอย่าง Apple Mail, Thunderbird, Outlook ควรรองรับ
    ไคลเอนต์ขนาดเล็กอย่าง Canary หรือ Spark ก็น่าจะนำไปใช้เป็นจุดขายที่แตกต่างได้ แต่กลับไม่ทำ
    • Outlook กำลังเปลี่ยนไปเป็นแบบ รองรับ MS365 เท่านั้น อยู่แล้ว
      Outlook รุ่นใหม่เก็บข้อมูลทั้งหมดไว้ใน Azure และสื่อสารกับเซิร์ฟเวอร์จริงผ่านพร็อกซี
      แทบไม่มีโอกาสที่จะรองรับ JMAP
    • JMAP เหมาะกับ ไคลเอนต์แบบบางอย่างเว็บเมล แต่กับแอปเดสก์ท็อปที่เก็บสถานะไว้ในเครื่อง มันไม่ได้มีข้อดีมากนัก
    • ถ้าผู้ให้บริการเมลรายใหญ่ไม่รองรับ จุดเด่นของ JMAP ก็จะอ่อนลง
      (ไม่ได้จะปกป้อง IMAP นะ)
    • ต้องมีฝั่งเซิร์ฟเวอร์รองรับก่อน
      ถ้า Gmail หรือ iCloud ไม่รองรับ ต่อให้สร้างไคลเอนต์ก็มีความหมายไม่มาก
      จะรองรับสองระบบพร้อมกันก็ได้ แต่ตลาดคงเล็ก
    • ถ้า JMAP จะประสบความสำเร็จ มันต้องพัฒนาไปเป็น โปรโตคอลกรุ๊ปแวร์แบบรวมศูนย์ ที่ครอบคลุมทั้งเมล ปฏิทิน รายชื่อผู้ติดต่อ การแชร์ไฟล์ ฯลฯ
      แต่เรื่องนั้นก็ยังมี “if” อีกมาก
  • Stalwart ทำให้การ self-host อีเมล ง่ายขึ้นมาก
    มันเป็นเซิร์ฟเวอร์แบบรวมทุกอย่างในตัว จนรู้สึกเหมือนเปิดยุคใหม่
    Maddy ก็โอเค แต่การดูแลรักษาไม่ค่อยคึกคักเท่าไร
    • ผมก็กำลังย้ายจากชุด Maddy+Postfix+Dovecot+Rspamd ไป Stalwart เหมือนกัน แต่รู้สึกว่า คุณภาพเอกสารยังไม่พอ
      ไม่มีเอกสารที่ทำให้เห็นตัวเลือก ค่าเริ่มต้น และความสัมพันธ์กันได้ในที่เดียว
      ตั้งค่าผ่าน Web UI ได้ก็จริง แต่ไปขัดกับ การ deploy แบบ declarative
      ถ้าไฟล์ .toml เป็นแบบอ่านอย่างเดียว จะเกิด error
    • สงสัยว่ามี เว็บเมลไคลเอนต์ JMAP ที่ใช้งานได้ดีไหม
      นอกจาก FastMail หรือ Topicbox ก็แทบไม่มีอะไรเด่น
      อยากได้แบบที่ self-host ผ่าน HTTPS ได้อย่าง Roundcube หรือ Wildduck
    • ไม่แน่ใจว่ามันมีข้อได้เปรียบเชิงปฏิบัติเมื่อเทียบกับ Postfix+Dovecot มากแค่ไหน
      นอกจาก “เขียนใหม่ด้วย Rust” ก็ยังไม่เห็นจุดต่างที่เด่นชัด
  • กังวลว่ากำลังจะพยายามแทนที่ Sieve ด้วย JSON หรือเปล่า
    ในสถานการณ์ที่ยังไม่มี MUA ที่ดี ก็ยังสงสัยว่า JMAP จะช่วยอะไรได้มากไหม
    ฝั่งเซิร์ฟเวอร์เป็นปัญหาที่แก้ได้มานานแล้ว แต่ ฝั่งไคลเอนต์ยังหยุดนิ่ง
    แม้แต่ความสามารถของ IMAP4 เองก็ยังอิมพลีเมนต์ไม่ครบเป็นส่วนใหญ่ และไคลเอนต์สำหรับ Sieve ก็แย่มาก
    • ผมไม่เห็นด้วยกับคำว่า “ฝั่งเซิร์ฟเวอร์เป็นปัญหาที่แก้จบแล้ว”
      Dovecot ยังรองรับ UTF-8 ได้ไม่สมบูรณ์เลย
      โปรเจ็กต์อย่าง Stalwart คือความพยายามจะก้าวข้าม ข้อจำกัดของระบบเก่า เหล่านี้
      ฝั่งไคลเอนต์เองก็มีตัวอย่างที่พัฒนาไปมากแล้วอย่าง Apple Mail
    • สุดท้ายก็ต้องมีทั้ง เซิร์ฟเวอร์และไคลเอนต์
      ถ้ามีแค่ฝั่งเดียวที่พัฒนาไป ก็ไม่มีความหมาย
      ตอนนี้มีเซิร์ฟเวอร์ดีแล้ว เหลือก็แค่ไคลเอนต์ดีๆ
  • ถ้าต้องการ JSON API สไตล์ JMAP ในสภาพแวดล้อม Google Workspace หรือ Outlook, Nylas อาจเป็นทางเลือกได้
    Nylas ทรงพลังมาก แต่ราคาสูง
    ในสเกลใหญ่ คิด $1.50 ต่อบัญชีต่อเดือน ซึ่งอาจกระทบ margin ของ SaaS ได้
    ถึงอย่างนั้นก็มีประโยชน์มากสำหรับการวิเคราะห์อีเมลแบบเรียลไทม์หรือสร้าง UI แบบกำหนดเอง
  • ผมลองติดตั้ง Stalwart แล้ว และ เว็บเซิร์ฟเวอร์กับเมลเซิร์ฟเวอร์ถูกรวมเข้าด้วยกัน