iMessage

สถานะ: การผสานรวม CLI ภายนอกแบบ native Gateway จะ spawn imsg rpc และสื่อสารผ่าน JSON-RPC บน stdio (ไม่มี daemon/port แยกต่างหาก) การดำเนินการขั้นสูงต้องใช้ imsg launch และการ probe 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 สำหรับ process context ที่รัน OpenClaw/imsg (การเข้าถึง Messages DB)
• ต้องมีสิทธิ์ Automation เพื่อส่งข้อความผ่าน Messages.app
• สำหรับการดำเนินการขั้นสูง (react / edit / unsend / threaded reply / effects / polls / 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, การ watch/history ขาเข้า, รายการแชท นี่คือสิ่งที่ได้ทันทีจาก brew install steipete/tap/imsg ใหม่พร้อมสิทธิ์ macOS มาตรฐานด้านบน
• โหมด Private API: imsg inject helper dylib เข้าไปใน Messages.app เพื่อเรียกฟังก์ชัน IMCore ภายใน นี่คือสิ่งที่ปลดล็อก react, edit, unsend, reply (แบบ thread), sendWithEffect, poll และ poll-vote (โพล native ของ Messages), renameGroup, setGroupIcon, addParticipant, removeParticipant, leaveGroup รวมถึง typing indicators และ read receipts

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

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

เทคนิค helper-injection ใช้ dylib ของ imsg เองเพื่อเข้าถึง private APIs ของ Messages ไม่มีเซิร์ฟเวอร์บุคคลที่สามหรือ runtime ของ BlueBubbles ในเส้นทาง OpenClaw iMessage

การตั้งค่า

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

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

   output ของ imsg status --json รายงาน bridge_version, rpc_methods และ selectors ราย method เพื่อให้คุณเห็นว่า build ปัจจุบันรองรับอะไรบ้างก่อนเริ่ม

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

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

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

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

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

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

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

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

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

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

   imsg launch

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

4. ตรวจสอบบริดจ์จาก OpenClaw:

   openclaw channels status --probe

   รายการ iMessage ควรรายงาน works และ imsg status --json | jq '{rpc_methods, selectors}' ควรแสดงความสามารถที่เปิดเผยโดยบิลด์ macOS ของคุณ การสร้างโพลต้องใช้ selectors.pollPayloadMessage; การโหวตต้องใช้ทั้ง selectors.pollVoteMessage และเมธอด RPC poll.vote Plugin ของ OpenClaw จะประกาศเฉพาะการกระทำที่รองรับโดยการโพรบที่แคชไว้ ส่วนแคชว่างจะยังมองในแง่บวกและโพรบเมื่อส่งครั้งแรก

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

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

หากการปิดใช้งาน SIP ไม่เป็นที่ยอมรับสำหรับโมเดลภัยคุกคามของคุณ:

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

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

{  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 แบบเดิมยังสามารถผูกกับเซสชัน ACP ได้ด้วย

ขั้นตอนด่วนสำหรับโอเปอเรเตอร์:

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

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

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

• แฮนเดิล DM ที่ถูกนอร์มัลไลซ์ เช่น +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" },    },  ],}

ดู เอเจนต์ 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,        polls: true,      },    },  },}

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

การเขียนค่า config

iMessage อนุญาตให้ช่องทางเริ่มการเขียนค่า config ตามค่าเริ่มต้น (สำหรับ /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-preview เป็นไฟล์แนบ

สองแถวนี้มาถึง 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 จะรวมเฉพาะ split-send จริงนั้น และคงแถวอื่นที่บัฟเฟอร์ไว้เป็นเทิร์นแยกกัน บนบิลด์ imsg รุ่นเก่าที่ไม่ปล่อยเมทาดาทา balloon เลย OpenClaw ไม่สามารถแยก split-send ออกจากการส่งแยกกันได้ จึงถอยกลับไปเป็นการรวม bucket วิธีนี้คงพฤติกรรมก่อนมีเมทาดาทาไว้ แทนที่จะถดถอย split-send แบบ Dump <url> ให้กลายเป็นสองเทิร์น แชตกลุ่มยังคงจัดส่งแบบรายข้อความเพื่อรักษาโครงสร้างเทิร์นของผู้ใช้หลายคนไว้

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

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

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

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

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

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

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

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

สัญญาณที่โอเปอเรเตอร์มองเห็น

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

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

การย้ายระบบ

channels.imessage.catchup.* เลิกใช้แล้ว — ตอนนี้การกู้คืนช่วงหยุดทำงานเป็นอัตโนมัติและไม่ต้องใช้คอนฟิกสำหรับการตั้งค่าใหม่ คอนฟิกที่มีอยู่พร้อม catchup.enabled: true ยังได้รับการรองรับในฐานะโปรไฟล์ความเข้ากันได้สำหรับหน้าต่างการเล่นซ้ำเพื่อกู้คืน บล็อก 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
• การจับคู่

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

• ภาพรวมช่องทาง — ช่องทางที่รองรับทั้งหมด
• การนำ BlueBubbles ออกและพาธ iMessage ของ imsg — ประกาศและสรุปการย้ายระบบ
• ย้ายมาจาก BlueBubbles — ตารางแปลคอนฟิกและการเปลี่ยนผ่านทีละขั้นตอน
• การจับคู่ — การยืนยันตัวตน DM และโฟลว์การจับคู่
• กลุ่ม — พฤติกรรมแชตกลุ่มและการควบคุมด้วย mention
• การกำหนดเส้นทางช่องทาง — การกำหนดเส้นทางเซสชันสำหรับข้อความ
• ความปลอดภัย — โมเดลการเข้าถึงและการเสริมความแข็งแกร่ง