โปรโตคอล Matrix เผชิญกับปัญหานักพัฒนาออกจากโครงการเพิ่มขึ้นเนื่องจากปัญหาประสิทธิภาพและการจัดการ

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

Matrix เกิดขึ้นในปี 2014 เป็นความพยายามที่ทะเยอทะยานในการสร้างระบบการส่งข้อความแบบเปิดและแบบสหพันธ์ที่สามารถเชื่อมต่อแพลตฟอร์มการสื่อสารต่างๆ เข้าด้วยกัน โปรโตคอลนี้สัญญาว่าจะส่งมอบสิ่งที่ IRC ไม่สามารถทำได้ - คุณสมบัติที่ทันสมัยเช่นการแชร์ไฟล์ การเข้ารหัส และความเข้ากันได้ข้ามแพลตฟอร์ม อย่างไรก็ตาม ความเป็นจริงได้พิสูจน์แล้วว่าซับซ้อนกว่าวิสัยทัศน์เริ่มแรกมาก

ไทม์ไลน์ของ Matrix Protocol

• 2014: Matrix protocol ได้รับการประกาศครั้งแรก โดยสัญญาว่าจะเป็นระบบส่งข้อความแบบ federated
• 2019: Riot Android ถูกเขียนใหม่เป็น RiotX (ต่อมากลายเป็น Element Android )
• 2023: Element X เปิดตัวในฐานะการเขียนโค้ดใหม่ทั้งหมดโดยใช้ Rust SDK
• 2025: นักพัฒนาเริ่มออกจากโครงการมากขึ้นและชุมชนเริ่มมีการวิพากษ์วิจารณ์

ปัญหาประสิทธิภาพรบกวนประสบการณ์ผู้ใช้

ปัญหาที่เห็นได้ชัดที่สุดที่ส่งผลต่อการยอมรับ Matrix คือประสิทธิภาพที่แย่ในแอปพลิเคชันไคลเอนต์ต่างๆ ผู้ใช้รายงานอย่างสม่ำเสมอเกี่ยวกับเวลาโหลดที่ช้า การใช้ CPU สูง และการใช้หน่วยความจำที่ทำให้การส่งข้อความพื้นฐานรู้สึกช้า ไคลเอนต์หลัก Element ที่สร้างบน Electron ได้รับการวิพากษ์วิจารณ์เป็นพิเศษสำหรับการใช้งานที่ใช้ทรัพยากรมาก

สมาชิกชุมชนได้สังเกตว่าแม้แต่งานง่ายๆ เช่นการเปิดเว็บไคลเอนต์ก็สามารถทำให้เบราว์เซอร์ใช้ CPU 100% ในขณะที่แสดงเพียงแอนิเมชันการโหลด ปัญหาประสิทธิภาพเหล่านี้ขยายไปเกินกว่าแค่ส่วนติดต่อผู้ใช้ - ซอฟต์แวร์เซิร์ฟเวอร์ Synapse ที่เป็นพื้นฐานก็ยังดิ้นรนกับประสิทธิภาพ ทำให้เกิดความต้องการโฮสติ้งที่แพงซึ่งไม่สนับสนุนการโฮสต์ด้วยตนเอง

หนี้ทางเทคนิคได้กลายเป็นเรื่องสำคัญมากจนทีมพัฒนา Element ได้เขียนส่วนประกอบหลักใหม่หลายครั้ง รวมถึงการเปิดตัว Element X เป็นการสร้างใหม่ทั้งหมดโดยใช้พื้นฐานใหม่ที่ใช้ Rust อย่างไรก็ตาม วิธีการนี้ได้สร้างความสับสนในหมู่ผู้ใช้ที่ต้องเลือกระหว่างไคลเอนต์ที่เร็วแต่มีคุณสมบัติจำกัด หรือไคลเอนต์ที่มีคุณสมบัติครบแต่ทำงานได้แย่

ปัญหาทางเทคนิคหลักที่ได้รับรายงาน

• การใช้งาน CPU สูง (100%) เมื่อโหลด web client
• ฐานข้อมูลเสียหายส่งผลกระทบต่อข้อมูลหลายล้านแถวบน matrix.org
• ข้อความล้มเหลวในการเชื่อมต่อระหว่างเซิร์ฟเวอร์ในช่วงที่เกิดปัญหา
• การซิงค์คีย์การเข้ารหัสล้มเหลวระหว่าง client ต่างๆ
• ปัญหาการใช้หน่วยความจำและทรัพยากรใน client ที่ใช้ Electron

การรอคอยอย่างไร้ผล: ความหงุดหงิดต่อประสิทธิภาพที่ช้าและปัญหาการโหลดของ Matrix

คุณสมบัติสหพันธ์ไม่เป็นไปตามที่สัญญา

จุดขายหลักของ Matrix - การเป็นสหพันธ์ที่แท้จริงที่ช่วยให้เซิร์ฟเวอร์ต่างๆ สื่อสารกันได้อย่างราบรื่น - ได้พิสูจน์แล้วว่าไม่น่าเชื่อถือในทางปฏิบัติ ผู้ใช้รายงานว่าข้อความไม่สามารถซิงค์ระหว่างเซิร์ฟเวอร์ โดยการสื่อสารบางอย่างหายไปในระหว่างการหยุดทำงานหรือการบำรุงรักษาเซิร์ฟเวอร์

เหตุการณ์ฐานข้อมูลเสียหายล่าสุดบนเซิร์ฟเวอร์หลัก matrix.org ได้เน้นย้ำจุดอ่อนของสหพันธ์เหล่านี้ แม้ว่าปัญหาจะได้รับการแก้ไขในที่สุด แต่ข้อความที่ส่งในช่วงเวลาที่หยุดทำงานไม่เคยซิงโครไนซ์กับเซิร์ฟเวอร์อื่นๆ อย่างถูกต้อง ซึ่งขัดแย้งกับคำสัญญาของโปรโตคอลเรื่องการส่งข้อความแบบกระจายที่ยืดหยุ่น

เครื่องมือทดสอบสหพันธ์เองถูกควบคุมโดย Element แทนที่จะเป็น Matrix Foundation ทำให้เกิดสถานการณ์ที่ผู้ดำเนินการเซิร์ฟเวอร์อิสระต้องปฏิบัติตามการใช้งานของ Element แทนที่จะเป็นมาตรฐานอิสระ

โครงสร้างการจัดการสร้างความสับสน

ความสัมพันธ์ระหว่าง Matrix Foundation (องค์กรมาตรฐาน) และ Element (บริษัทเชิงพาณิชย์) ได้กลายเป็นเรื่องที่คลุมเครือมากขึ้น ในขณะที่ Foundation ควบคุมข้อกำหนดโปรโตคอลและเครื่องหมายการค้าตามทฤษฎี แต่การครอบงำของ Element ในการพัฒนาทั้งไคลเอนต์และเซิร์ฟเวอร์ทำให้พวกเขามีการควบคุมทิศทางของแพลตฟอร์มอย่างมีประสิทธิภาพ

สิ่งนี้ได้นำไปสู่สถานการณ์ที่ลำดับความสำคัญทางธุรกิจของ Element ขัดแย้งกับเป้าหมายของโปรโตคอลเปิด การที่บริษัทมุ่งเน้นไปที่ลูกค้าองค์กรและคุณสมบัติที่เป็นกรรมสิทธิ์เช่น Element Call ได้เบี่ยงเบนทรัพยากรจากการปรับปรุงโปรโตคอลหลักที่จะเป็นประโยชน์ต่อระบบนิเวศที่กว้างขึ้น

การตอบสนองทั่วไปจากทีมคือ: จ่ายเงินหรือหุบปากและยอมรับสิ่งที่เราให้คุณ จำนวนการเปลี่ยนแปลงทิศทางครั้งใหญ่ที่โครงการนี้มีในช่วงสองสามปีที่ผ่านมามากพอที่จะทำลายโครงการใดๆ

การสร้างสมดุลในลำดับความสำคัญ: การนำทางผ่านความท้าทายของการกำกับดูแลภายในโครงการ Matrix

ความท้าทายด้านความปลอดภัยและการเข้ารหัส

แม้จะวางตำแหน่งตัวเองเป็นแพลตฟอร์มที่เน้นความเป็นส่วนตัว Matrix ยังคงดิ้นรนกับความน่าเชื่อถือของการเข้ารหัส ผู้ใช้มักพบสถานการณ์ที่ข้อความไม่สามารถถอดรหัสข้ามไคลเอนต์ต่างๆ ได้ ทำให้เกิดการสูญเสียประวัติการสนทนาและประสบการณ์ที่น่าผิดหวัง

ความซับซ้อนของโปรโตคอลยังได้สร้างช่องโหว่ด้านความปลอดภัย โดยมี CVE วิกฤติสองรายการที่ค้นพบเมื่อเร็วๆ นี้ซึ่งต้องการการอัปเดตที่ประสานงานกันทั่วทั้งระบบนิเวศ ความจริงที่ว่าปัญหาเหล่านี้ใช้เวลาหลายเดือนในการแก้ไขเน้นย้ำถึงความท้าทายในการรักษาความปลอดภัยในระบบสหพันธ์ที่ซับซ้อนเช่นนี้

โปรโตคอลการส่งข้อความทางเลือกที่กล่าวถึง

• XMPP: โปรโตคอลเก่าที่มาพร้อมกับการเข้ารหัส OMEMO สมัยใหม่
• Signal: ได้รับการยกย่องในด้านประสบการณ์ผู้ใช้ แต่ไม่เป็นมิตรกับการติดตั้งเซิร์ฟเวอร์เอง
• Delta Chat: ใช้โครงสร้างพื้นฐานอีเมลสำหรับการส่งข้อความ
• Zulip: การส่งข้อความแบบเธรดพร้อมรองรับ markdown
• IRC: เรียบง่ายแต่ขาดคุณสมบัติสมัยใหม่

ความหงุดหงิดกับความปลอดภัย: ผู้ใช้ต่อสู้กับความท้าทายด้านการเข้ารหัสของ Matrix

ชุมชนแสวงหาทางเลือก

เมื่อความผิดหวังกับ Matrix เพิ่มขึ้น นักพัฒนาและผู้ใช้กำลังมองหาทางเลือกมากขึ้น บางคนกลับไปใช้ XMPP พร้อมส่วนขยายที่ทันสมัยเช่นการเข้ารหัส OMEMO ในขณะที่คนอื่นๆ สนับสนุนโซลูชันที่ง่ายกว่าซึ่งให้ความสำคัญกับความน่าเชื่อถือมากกว่าความสมบูรณ์ของคุณสมบัติ

สถานการณ์นี้สะท้อนถึงความท้าทายที่กว้างขึ้นในการพัฒนาโอเพนซอร์ส: การสร้างสมดุลระหว่างเป้าหมายทางเทคนิคที่ทะเยอทะยานกับการใช้งานจริงที่ใช้งานได้ ในขณะที่วิสัยทัศน์ของ Matrix เรื่องการส่งข้อความแบบสหพันธ์ที่เป็นสากลยังคงน่าสนใจ แต่การดำเนินการได้ดิ้นรนที่จะตอบสนองคำสัญญา

สำหรับองค์กรและบุคคลที่ลงทุนในระบบนิเวศ Matrix สถานการณ์ปัจจุบันนำเสนอทางเลือกที่ยาก พื้นฐานทางเทคนิคของโปรโตคอลยังคงแข็งแกร่ง แต่ความท้าทายในการใช้งานและปัญหาการจัดการแสดงให้เห็นว่าจำเป็นต้องมีการเปลี่ยนแปลงที่สำคัญเพื่อให้บรรลุศักยภาพเดิม

อ้างอิง: Giving Up on Element & Matrix.org