iMessage

สถานะ: การผสานรวม CLI ภายนอกแบบเนทีฟ Gateway จะเรียกใช้ imsg rpc และสื่อสารผ่าน JSON-RPC บน stdio (ไม่มี daemon/port แยกต่างหาก) การดำเนินการขั้นสูงต้องใช้ imsg launch และการตรวจสอบ private API ที่สำเร็จ

การตั้งค่าอย่างรวดเร็ว

brew install steipete/tap/imsgimsg rpc --helpimsg launchopenclaw channels status --probe

{channels: {imessage: {enabled: true,cliPath: "/usr/local/bin/imsg",dbPath: "/Users/user/Library/Messages/chat.db",},},}

openclaw gateway

openclaw pairing list imessageopenclaw pairing approve imessage <CODE>

#!/usr/bin/env bashexec ssh -T gateway-host imsg "$@"

{channels: {imessage: {  enabled: true,  cliPath: "~/.openclaw/scripts/imsg-ssh",  remoteHost: "user@gateway-host", // used for SCP attachment fetches  includeAttachments: true,  // Optional: override allowed attachment roots.  // Defaults include /Users/*/Library/Messages/Attachments  attachmentRoots: ["/Users/*/Library/Messages/Attachments"],  remoteAttachmentRoots: ["/Users/*/Library/Messages/Attachments"],},},}

ข้อกำหนดและสิทธิ์ (macOS)

• Messages ต้องลงชื่อเข้าใช้อยู่บน Mac ที่รัน imsg
• ต้องมี Full Disk Access สำหรับบริบทกระบวนการที่รัน OpenClaw/imsg (การเข้าถึง DB ของ Messages)
• ต้องมีสิทธิ์ Automation เพื่อส่งข้อความผ่าน Messages.app
• สำหรับการดำเนินการขั้นสูง (react / edit / unsend / threaded reply / effects / group ops) ต้องปิดใช้งาน System Integrity Protection — ดู การเปิดใช้ imsg private API ด้านล่าง การส่ง/รับข้อความและสื่อพื้นฐานทำงานได้โดยไม่ต้องปิด

Not authorized to send Apple events to Messages. (-1743)

kTCCServiceAppleEvents | /usr/libexec/sshd-keygen-wrapper | auth_value=0 | com.apple.MobileSMS

การเปิดใช้ imsg private API

imsg มาพร้อมโหมดการทำงานสองแบบ:

• โหมดพื้นฐาน (ค่าเริ่มต้น ไม่ต้องเปลี่ยน SIP): ข้อความและสื่อขาออกผ่าน send, การดู/ประวัติขาเข้า, รายการแชต นี่คือสิ่งที่คุณได้ทันทีจาก brew install steipete/tap/imsg ใหม่พร้อมสิทธิ์ macOS มาตรฐานด้านบน
• โหมด Private API: imsg ฉีด dylib ตัวช่วยเข้าไปใน Messages.app เพื่อเรียกฟังก์ชันภายในของ IMCore นี่คือสิ่งที่ปลดล็อก react, edit, unsend, reply (แบบเธรด), sendWithEffect, renameGroup, setGroupIcon, addParticipant, removeParticipant, leaveGroup รวมถึงตัวบ่งชี้การพิมพ์และใบตอบรับการอ่าน

เพื่อเข้าถึงพื้นผิวการดำเนินการขั้นสูงที่หน้า channel นี้บันทึกไว้ คุณต้องใช้โหมด Private API README ของ imsg ระบุข้อกำหนดไว้อย่างชัดเจน:

ฟีเจอร์ขั้นสูง เช่น read, typing, launch, การส่งแบบริชที่มีบริดจ์รองรับ, การแก้ไขข้อความ และการจัดการแชต เป็นแบบเลือกเปิดใช้ ฟีเจอร์เหล่านี้ต้องปิดใช้งาน SIP และฉีด dylib ตัวช่วยเข้าไปใน Messages.app imsg launch จะปฏิเสธการฉีดเมื่อเปิดใช้งาน SIP อยู่

เทคนิคการฉีดตัวช่วยใช้ dylib ของ imsg เองเพื่อเข้าถึง private API ของ Messages ไม่มีเซิร์ฟเวอร์บุคคลที่สามหรือรันไทม์ BlueBubbles ในเส้นทาง OpenClaw iMessage

การตั้งค่า

1. ติดตั้ง (หรืออัปเกรด) imsg บน Mac ที่รัน Messages.app:

   brew install steipete/tap/imsgimsg --versionimsg status --json

   เอาต์พุต imsg status --json จะรายงาน bridge_version, rpc_methods และ selectors ต่อเมธอด เพื่อให้คุณดูได้ว่าบิลด์ปัจจุบันรองรับอะไรบ้างก่อนเริ่มใช้งาน

2. ปิดใช้งาน System Integrity Protection และ (บน macOS รุ่นใหม่) Library Validation การฉีด dylib ตัวช่วยที่ไม่ใช่ของ Apple เข้าไปใน Messages.app ที่ลงนามโดย Apple ต้องปิด SIP และ ผ่อนคลาย library validation ขั้นตอน SIP ใน Recovery mode ขึ้นอยู่กับเวอร์ชัน macOS:

   • macOS 10.13-10.15 (Sierra-Catalina): ปิดใช้งาน Library Validation ผ่าน Terminal, รีบูตเข้าสู่ Recovery Mode, รัน csrutil disable, รีสตาร์ท
   • macOS 11+ (Big Sur และใหม่กว่า), Intel: Recovery Mode (หรือ Internet Recovery), csrutil disable, รีสตาร์ท
   • macOS 11+, Apple Silicon: ใช้ลำดับการเริ่มต้นด้วยปุ่มเปิดเครื่องเพื่อเข้าสู่ Recovery; บน macOS เวอร์ชันล่าสุดให้กดปุ่ม Left Shift ค้างไว้เมื่อคลิก Continue แล้วจึง csrutil disable การตั้งค่าเครื่องเสมือนมีขั้นตอนแยกต่างหาก ดังนั้นให้สร้าง snapshot ของ VM ก่อน

   บน macOS 11 และใหม่กว่า โดยปกติ csrutil disable อย่างเดียวไม่พอ Apple ยังคงบังคับใช้ library validation กับ Messages.app ในฐานะไบนารีแพลตฟอร์ม ดังนั้นตัวช่วยที่ลงนามแบบ adhoc จะถูกปฏิเสธ (Library Validation failed: ... platform binary, but mapped file is not) แม้จะปิด SIP แล้ว หลังจากปิด SIP ให้ปิด library validation ด้วยแล้วรีบูต:

   sudo defaults write /Library/Preferences/com.apple.security.libraryvalidation.plist DisableLibraryValidation -bool true

   macOS 26 (Tahoe), ตรวจสอบแล้วบน 26.5.1: การปิด SIP พร้อมกับ คำสั่ง DisableLibraryValidation ด้านบนเพียงพอสำหรับฉีดตัวช่วยใน 26.0 ถึง 26.5.x ไม่ต้องใช้ boot-args plist คือปัจจัยชี้ขาดและเป็นขั้นตอนที่มักขาดที่สุดเมื่อการฉีดล้มเหลวบน Tahoe:

   • เมื่อมี plist: imsg launch ฉีดสำเร็จและ imsg status รายงาน advanced_features: true
   • เมื่อไม่มี plist (แม้จะปิด SIP แล้ว): imsg launch ล้มเหลวด้วย Failed to launch: Timeout waiting for Messages.app to initialize AMFI ปฏิเสธตัวช่วย adhoc ขณะโหลด ดังนั้นบริดจ์จึงไม่พร้อมใช้งานและการ launch หมดเวลา timeout นั้นคืออาการที่คนส่วนใหญ่เจอบน Tahoe และวิธีแก้คือ plist ด้านบน ไม่ใช่อะไรที่รุนแรงกว่านั้น

   สิ่งนี้ได้รับการยืนยันด้วยการควบคุมก่อน/หลังบน macOS 26.5.1 (Apple Silicon): เมื่อมี plist, dylib จะ map เข้าไปใน Messages.app และบริดจ์เริ่มทำงาน; เมื่อลบ plist แล้วรีบูต, imsg launch จะเกิด timeout failure ข้างต้นโดยที่ dylib ไม่ถูก map

   หากการฉีด imsg launch หรือ selectors บางรายการเริ่มคืนค่า false หลังอัปเกรด macOS เกตนี้มักเป็นสาเหตุปกติ ตรวจสอบสถานะ SIP และ library-validation ก่อนสรุปว่าขั้นตอน SIP เองล้มเหลว หากการตั้งค่าเหล่านั้นถูกต้องแล้วแต่ bridge ยังฉีดไม่ได้ ให้รวบรวม imsg status --json พร้อมเอาต์พุต imsg launch แล้วรายงานไปยังโปรเจกต์ imsg แทนการลดระดับการควบคุมความปลอดภัยทั่วทั้งระบบเพิ่มเติม

   ทำตามขั้นตอนโหมด Recovery ของ Apple สำหรับ Mac ของคุณเพื่อปิดใช้งาน SIP ก่อนเรียกใช้ imsg launch

3. ฉีด helper เมื่อปิดใช้งาน SIP แล้ว และลงชื่อเข้าใช้ Messages.app แล้ว:

   imsg launch

   imsg launch จะปฏิเสธการฉีดเมื่อ SIP ยังเปิดใช้งานอยู่ ดังนั้นคำสั่งนี้จึงใช้ยืนยันได้ด้วยว่าขั้นตอนที่ 2 มีผลแล้ว

4. ตรวจสอบ bridge จาก OpenClaw:

   openclaw channels status --probe

   รายการ iMessage ควรรายงาน works และ imsg status --json | jq '.selectors' ควรแสดง retractMessagePart: true พร้อม selector สำหรับแก้ไข / กำลังพิมพ์ / อ่าน แล้วแต่ที่บิลด์ macOS ของคุณเปิดเผย การ gate แบบรายเมธอดของ Plugin OpenClaw ใน actions.ts จะโฆษณาเฉพาะ action ที่ selector เบื้องหลังเป็น true เท่านั้น ดังนั้นพื้นผิว action ที่คุณเห็นในรายการเครื่องมือของ agent จึงสะท้อนสิ่งที่ bridge ทำได้จริงบนโฮสต์นี้

หาก openclaw channels status --probe รายงานช่องทางเป็น works แต่ action บางรายการโยนข้อผิดพลาด "iMessage <action> requires the imsg private API bridge" ตอน dispatch ให้เรียกใช้ imsg launch อีกครั้ง — helper อาจหลุดออกได้ (Messages.app รีสตาร์ต, อัปเดต OS ฯลฯ) และสถานะ available: true ที่แคชไว้จะยังโฆษณา action ต่อไปจนกว่า probe ครั้งถัดไปจะรีเฟรช

เมื่อคุณไม่สามารถปิดใช้งาน SIP

หากสถานะปิด SIP ไม่เหมาะกับโมเดลภัยคุกคามของคุณ:

• imsg จะ fallback ไปยังโหมดพื้นฐาน — ข้อความ + สื่อ + รับเท่านั้น
• Plugin OpenClaw ยังโฆษณาการส่งข้อความ/สื่อ และการมอนิเตอร์ขาเข้า เพียงแต่ซ่อน react, edit, unsend, reply, sendWithEffect และการทำงานกลุ่มจากพื้นผิว action (ตาม gate ความสามารถแบบรายเมธอด)
• คุณสามารถรัน Mac ที่ไม่ใช่ Apple Silicon แยกต่างหาก (หรือ Mac สำหรับบอตโดยเฉพาะ) โดยปิด SIP สำหรับงาน iMessage ขณะที่ยังเปิด SIP บนอุปกรณ์หลักของคุณ ดู ผู้ใช้ macOS สำหรับบอตโดยเฉพาะ (ตัวตน iMessage แยกต่างหาก) ด้านล่าง

การควบคุมการเข้าถึงและการกำหนดเส้นทาง

{  channels: {    imessage: {      groupPolicy: "allowlist",      groupAllowFrom: ["+15555550123"],      groups: {        "*": { systemPrompt: "Use British spelling." },        "8421": {          requireMention: true,          systemPrompt: "This is the on-call rotation chat. Keep replies under 3 sentences.",        },        "9907": {          // explicit suppression: the wildcard "Use British spelling." does not apply here          systemPrompt: "",        },      },    },  },}

การผูกการสนทนา ACP

แชต iMessage แบบ legacy ยังสามารถผูกกับเซสชัน ACP ได้ด้วย

โฟลว์ผู้ปฏิบัติงานแบบเร็ว:

• เรียกใช้ /acp spawn codex --bind here ภายใน DM หรือแชตกลุ่มที่อนุญาต
• ข้อความในอนาคตในบทสนทนา iMessage เดียวกันจะถูกกำหนดเส้นทางไปยังเซสชัน ACP ที่ spawn ไว้
• /new และ /reset รีเซ็ตเซสชัน ACP ที่ผูกไว้นั้นในตำแหน่งเดิม
• /acp close ปิดเซสชัน ACP และลบการผูก

รองรับการผูกแบบถาวรที่กำหนดค่าไว้ผ่านรายการ bindings[] ระดับบน โดยมี type: "acp" และ match.channel: "imessage"

match.peer.id สามารถใช้:

• handle DM ที่ normalize แล้ว เช่น +15555550123 หรือ user@example.com
• chat_id:<id> (แนะนำสำหรับการผูกกลุ่มที่เสถียร)
• chat_guid:<guid>
• chat_identifier:<identifier>

ตัวอย่าง:

{  agents: {    list: [      {        id: "codex",        runtime: {          type: "acp",          acp: { agent: "codex", backend: "acpx", mode: "persistent" },        },      },    ],  },  bindings: [    {      type: "acp",      agentId: "codex",      match: {        channel: "imessage",        accountId: "default",        peer: { kind: "group", id: "chat_id:123" },      },      acp: { label: "codex-group" },    },  ],}

ดู Agent ACP สำหรับพฤติกรรมการผูก ACP ที่ใช้ร่วมกัน

รูปแบบการปรับใช้

{  channels: {    imessage: {      enabled: true,      cliPath: "~/.openclaw/scripts/imsg-ssh",      remoteHost: "bot@mac-mini.tailnet-1234.ts.net",      includeAttachments: true,      dbPath: "/Users/bot/Library/Messages/chat.db",    },  },}

#!/usr/bin/env bashexec ssh -T bot@mac-mini.tailnet-1234.ts.net imsg "$@"

สื่อ การแบ่งชิ้นส่วน และเป้าหมายการส่ง

imsg chats --limit 20

การกระทำ Private API

เมื่อ imsg launch กำลังทำงานและ openclaw channels status --probe รายงาน privateApi.available: true เครื่องมือข้อความจะใช้การกระทำแบบเนทีฟของ iMessage เพิ่มเติมจากการส่งข้อความปกติได้

{  channels: {    imessage: {      actions: {        reactions: true,        edit: true,        unsend: true,        reply: true,        sendWithEffect: true,        sendAttachment: true,        renameGroup: true,        setGroupIcon: true,        addParticipant: true,        removeParticipant: true,        leaveGroup: true,      },    },  },}

{  channels: {    imessage: {      sendReadReceipts: false,    },  },}

การเขียนการกำหนดค่า

iMessage อนุญาตให้ช่องทางเริ่มการเขียนการกำหนดค่าได้โดยค่าเริ่มต้น (สำหรับ /config set|unset เมื่อ commands.config: true)

ปิดใช้งาน:

{  channels: {    imessage: {      configWrites: false,    },  },}

การรวม DM แบบส่งแยก (คำสั่ง + URL ในการเขียนครั้งเดียว)

เมื่อผู้ใช้พิมพ์คำสั่งและ URL พร้อมกัน เช่น Dump https://example.com/article แอป Messages ของ Apple จะแยกการส่งเป็น สองแถว chat.db ที่แยกกัน:

1. ข้อความ ("Dump")
2. บอลลูนพรีวิว URL ("https://...") พร้อมรูปภาพพรีวิว OG เป็นไฟล์แนบ

สองแถวนี้มาถึง OpenClaw ห่างกันประมาณ 0.8-2.0 วินาทีในสภาพแวดล้อมส่วนใหญ่ หากไม่มีการรวม เอเจนต์จะได้รับเฉพาะคำสั่งในรอบงานที่ 1 ตอบกลับ (มักเป็น “ส่ง URL มาให้ฉัน”) และเห็น URL เฉพาะในรอบงานที่ 2 ซึ่งเมื่อถึงตอนนั้นบริบทของคำสั่งก็หายไปแล้ว นี่เป็นไปป์ไลน์การส่งของ Apple ไม่ใช่สิ่งที่ OpenClaw หรือ imsg เพิ่มเข้ามา

channels.imessage.coalesceSameSenderDms เลือกให้ DM บัฟเฟอร์แถวต่อเนื่องจากผู้ส่งคนเดียวกัน เมื่อ imsg เปิดเผยตัวทำเครื่องหมายพรีวิว URL เชิงโครงสร้าง balloon_bundle_id: "com.apple.messages.URLBalloonProvider" บนหนึ่งในแถวต้นทาง OpenClaw จะรวมเฉพาะการส่งแยกจริงนั้น และคงแถวอื่นที่บัฟเฟอร์ไว้เป็นรอบงานแยก บนบิลด์ imsg รุ่นเก่าที่ไม่ส่งเมตาดาต้าบอลลูนเลย OpenClaw ไม่สามารถแยกการส่งแยกออกจากการส่งแยกกันได้ จึงถอยกลับไปเป็นการรวมบักเก็ต การทำเช่นนี้รักษาพฤติกรรมก่อนมีเมตาดาต้า แทนที่จะทำให้การส่งแยก Dump <url> ถดถอยเป็นสองรอบงาน แชทกลุ่มยังคงส่งต่อแบบรายข้อความเพื่อรักษาโครงสร้างรอบงานของผู้ใช้หลายคน

{  channels: {    imessage: {      coalesceSameSenderDms: true, // opt in (default: false)    },  },}

{  messages: {    inbound: {      byChannel: {        // 7000 ms covers observed Messages.app URL-preview delays.        imessage: 7000,      },    },  },}

สถานการณ์และสิ่งที่เอเจนต์เห็น

คอลัมน์ "Flag on" แสดงลักษณะการทำงานบนบิลด์ imsg ที่ส่งออก balloon_bundle_id บนบิลด์ imsg รุ่นเก่าที่ไม่ส่งออกเมทาดาทา balloon เลย แถวด้านล่างที่ทำเครื่องหมาย "Two turns" / "N turns" จะถอยกลับไปใช้การรวมแบบเดิมแทน (หนึ่งเทิร์น): OpenClaw ไม่สามารถบอกเชิงโครงสร้างได้ว่าการส่งที่ถูกแยกเป็นส่วน ๆ ต่างจากการส่งแยกกันอย่างไร จึงคงการรวมก่อนมีเมทาดาทาไว้ การแยกอย่างแม่นยำจะเริ่มทำงานเมื่อบิลด์ส่งออกเมทาดาทา balloon

การกู้คืนขาเข้าหลังจาก bridge หรือ Gateway รีสตาร์ต

iMessage กู้คืนข้อความที่พลาดไประหว่างที่ Gateway หยุดทำงาน และในขณะเดียวกันก็ระงับ "backlog bomb" เก่าที่ Apple อาจปล่อยออกมาหลังการกู้คืน Push พฤติกรรมเริ่มต้นจะเปิดใช้งานเสมอ โดยสร้างบน dedupe ขาเข้า

• Replay dedupe. ข้อความขาเข้าทุกข้อความที่ถูกส่งต่อจะถูกบันทึกตาม Apple GUID ในสถานะ Plugin แบบถาวร (imessage.inbound-dedupe) ถูกอ้างสิทธิ์ตอนรับเข้า และ commit หลังจัดการเสร็จ (ปล่อยเมื่อเกิดความล้มเหลวชั่วคราวเพื่อให้ลองใหม่ได้) สิ่งใดที่จัดการไปแล้วจะถูกทิ้งแทนการส่งต่อซ้ำสองครั้ง นี่คือสิ่งที่ทำให้การกู้คืน replay ได้อย่างจริงจังโดยไม่ต้องทำ bookkeeping ต่อข้อความ
• Downtime recovery. ตอนเริ่มต้น monitor จะจำ chat.db rowid ล่าสุดที่ส่งต่อแล้ว (เคอร์เซอร์ต่อบัญชีที่คงอยู่ถาวร) และส่งให้ imsg watch.subscribe เป็น since_rowid เพื่อให้ imsg replay แถวที่เข้ามาระหว่างที่ Gateway หยุดทำงาน แล้วจึง tail แบบ live การ replay ถูกจำกัดไว้ที่แถวล่าสุดและข้อความที่เก่าไม่เกิน ~2 ชั่วโมง และ dedupe จะทิ้งสิ่งที่จัดการไปแล้ว
• Stale-backlog age fence. แถวที่อยู่เหนือขอบเขตตอนเริ่มต้นเป็นข้อมูล live จริง ๆ; แถวใดที่วันที่ส่งเก่ากว่าเวลามาถึงเกิน ~15 นาทีคือ backlog จาก Push-flush และจะถูกระงับ แถวที่ replay (ที่ขอบเขตหรือต่ำกว่า) จะใช้หน้าต่างการกู้คืนที่กว้างกว่าแทน เพื่อให้ข้อความที่พลาดไปไม่นานถูกส่งมอบ ในขณะที่ประวัติเก่าแก่มากจะไม่ถูกส่ง

การกู้คืนทำงานได้ทั้งกับการตั้งค่า cliPath แบบ local และ remote เพราะ replay ด้วย since_rowid ทำงานผ่านการเชื่อมต่อ RPC ของ imsg เดียวกัน ความแตกต่างคือหน้าต่างเวลา: เมื่อ Gateway อ่าน chat.db ได้ (local) ระบบจะยึดขอบเขต rowid ตอนเริ่มต้น จำกัดช่วง replay และส่งมอบข้อความที่พลาดไปซึ่งเก่าได้ถึงสองสามชั่วโมง เมื่อใช้ cliPath แบบ SSH ระยะไกล ระบบจะอ่านฐานข้อมูลไม่ได้ ดังนั้น replay จะไม่ถูกจำกัด และทุกแถวจะใช้ age fence แบบ live โดยยังคงกู้คืนข้อความที่พลาดไปไม่นานและยังคงระงับ backlog เก่า เพียงแต่ใช้หน้าต่าง live ที่แคบกว่า ให้รัน Gateway บน Mac ที่ใช้ Messages เพื่อให้ได้หน้าต่างการกู้คืนที่กว้างกว่า

สัญญาณที่ operator มองเห็นได้

backlog ที่ถูกระงับจะถูกบันทึก log ที่ระดับเริ่มต้น และจะไม่ถูกทิ้งอย่างเงียบ ๆ (recovery flag แสดงว่าหน้าต่างใดถูกใช้):

imessage: suppressed stale inbound backlog account=<id> sent=<iso> recovery=<bool> (&lt;N&gt; suppressed since start)

การย้ายระบบ

channels.imessage.catchup.* ถูกเลิกใช้แล้ว — downtime recovery ตอนนี้เป็นแบบอัตโนมัติและไม่ต้องใช้ config สำหรับการตั้งค่าใหม่ config เดิมที่มี catchup.enabled: true จะยังคงได้รับการรองรับเป็นโปรไฟล์ความเข้ากันได้สำหรับหน้าต่าง replay การกู้คืน บล็อก catchup ที่ปิดใช้งาน (enabled: false หรือไม่มี enabled: true) ถูกเลิกใช้แล้ว; openclaw doctor --fix จะลบรายการเหล่านั้น

การแก้ไขปัญหา

imsg rpc --helpimsg status --jsonopenclaw channels status --probe

imsg chats --limit 10 --jsonimsg watch --chat-id <chat-id> --jsonsqlite3 ~/Library/Messages/chat.db \"select datetime(max(date)/1000000000 + 978307200, 'unixepoch', 'localtime'), max(ROWID) from message;"

launchctl kickstart -k system/com.apple.apsdlaunchctl kickstart -k gui/$(id -u)/com.apple.CommCenterlaunchctl kickstart -k gui/$(id -u)/com.apple.identityservicesdlaunchctl kickstart -k gui/$(id -u)/com.apple.imagentimsg launchopenclaw gateway restart

#!/usr/bin/env bashexec ssh -T messages-mac imsg "$@"

openclaw channels status --probe --channel imessage

imsg chats --limit 1imsg send <handle> "test"

ตัวชี้ไปยังข้อมูลอ้างอิงการกำหนดค่า

• ข้อมูลอ้างอิงการกำหนดค่า - iMessage
• การกำหนดค่า Gateway
• การจับคู่

ที่เกี่ยวข้อง

• ภาพรวม Channels — ช่องทางทั้งหมดที่รองรับ
• การนำ BlueBubbles ออกและ path iMessage ของ imsg — ประกาศและสรุปการย้ายระบบ
• ย้ายมาจาก BlueBubbles — ตารางแปล config และขั้นตอน cutover ทีละขั้น
• การจับคู่ — การยืนยันตัวตน DM และ flow การจับคู่
• กลุ่ม — พฤติกรรมแชตกลุ่มและการ gate ด้วย mention
• Channel Routing — การ routing เซสชันสำหรับข้อความ
• ความปลอดภัย — โมเดลการเข้าถึงและการ hardening