# GoChat — ระบบและขอบเขตที่พัฒนาแล้ว

ปรับปรุง 7 กันยายน 2026

GoChat เป็นเว็บกล่องข้อความรวมที่สร้างด้วย Go 1.25, net/http, HTML/CSS/JavaScript โดยตรง และ modernc.org/sqlite (pure Go) ไม่มี framework ฝั่งเว็บหรือ backend และไม่ต้องใช้ Node.js ในการรัน ไฟล์เว็บฝังอยู่ใน executable ด้วย go:embed

## เส้นทางข้อความ

ผู้ให้บริการ → HTTPS webhook → ตรวจลายเซ็นและรหัสบัญชี → SQLite transaction + กัน event ซ้ำ → บทสนทนา/ข้อความ → Server-Sent Events → กล่องข้อความบนเว็บ

ผู้ดูแล → บันทึกข้อความและ client_id → durable outbox ใน SQLite → worker → ตรวจสถานะบัญชีและหน้าต่างเวลา → official API → บันทึกสถานะ API accepted หรือ uncertain → ปรับหน้าจอ

สถานะ sent หมายถึง API ตอบรับ ไม่ใช่ delivered/read ที่อุปกรณ์ผู้รับ รุ่นนี้ยังไม่รับ delivery receipts หากการส่งค้างกลางทาง ระบบจะใช้ uncertain และไม่ลองส่งใหม่อัตโนมัติ ป้องกันส่งข้อความซ้ำ ผู้ดูแลต้องตรวจสอบต้นทางก่อนส่งใหม่

## สิ่งที่ใช้ได้ในรุ่นนี้

- กล่องข้อความรวมและหลายบัญชีต่อผู้ให้บริการ การค้นหา กรองช่องทาง สถานะ unread/open/pending/resolved
- เปิดบทสนทนาและอ่านย้อนหลัง (ล่าสุด 1,000 ข้อความ), internal note, ตอบข้อความ, กำหนดความสำคัญ, มอบหมายผู้รับผิดชอบที่เปิดใช้งานในทีม
- เพิ่มบัญชี ตรวจสอบ token แก้ไข/หมุนเวียน credentials เปิด/พักการเชื่อมต่อ และแสดง webhook URL
- ตัวเชื่อมต่อข้อความ LINE OA, Telegram Bot, Facebook Messenger Page, Instagram Professional ผ่าน Instagram Login, WhatsApp Business Cloud และ Slack
- รับไฟล์แนบเป็นข้อความสรุปชนิดไฟล์ ยังไม่ดาวน์โหลดหรือส่งไฟล์แนบ
- ช่องทางอื่นแสดงเป็นยังไม่พร้อม และไม่เปิดให้บันทึกเสมือนเชื่อมต่อแล้ว
- พื้นที่ทดลองแยกฐานข้อมูลและไม่ส่งข้อความไปภายนอก

## ขอบเขตการเชื่อมต่อ

การมีตัวเชื่อมต่อในโค้ดไม่เท่ากับเชื่อมต่อบัญชีจริงแล้ว ต้องใช้ token ของบัญชีที่ได้รับสิทธิ์ แอปของผู้ให้บริการที่อนุมัติแล้ว และ webhook HTTPS ที่เข้าถึงได้จากอินเทอร์เน็ต ตรวจ token ผ่านจะขึ้น verified; เมื่อได้รับ webhook ที่ยืนยันแล้วจึงขึ้น connected ข้อมูลทดสอบจำลองใช้สถานะ demo เท่านั้น

LINE ใช้ push API จึงอยู่ภายใต้ quota/เงื่อนไขผู้รับ; ยังไม่ใช้ replyToken ฟรีช่วงสั้น
Telegram ต้องตั้ง setWebhook พร้อม secret_token ค่าเดียวกับช่อง verify_token ใน GoChat
Messenger/Instagram/WhatsApp ส่งข้อความปกติเฉพาะภายใน 24 ชั่วโมงนับจาก timestamp ของข้อความลูกค้าล่าสุด ตัวตรวจทำก่อนเข้าคิวและก่อนส่งจริง ไม่ขยายเวลาจาก webhook ที่ไม่มีเวลา/เวลาอนาคต รุ่นนี้ยังไม่มี template, HUMAN_AGENT หรือ message tag
Slack ต้องสมัคร events พร้อม scopes และให้ bot อยู่ในบทสนทนาที่ได้รับสิทธิ์
Meta Graph API ตั้งค่าเริ่มต้น v25.0 ตรวจรุ่นที่อนุมัติบนแอปของคุณก่อนใช้งาน (GOCHAT_GRAPH_VERSION)

## ฐานข้อมูล

SQLite WAL, foreign_keys=ON, busy_timeout 5 วินาที ใช้ connection เดียวเพื่อเรียงลำดับการเขียน เหมาะกับหนึ่ง instance ก่อนขยาย แนะนำ SQLite อยู่บน local disk/volume ไม่ใช้ network filesystem ไม่เปิดหลาย replicas เขียนไฟล์เดียวกัน

ตาราง: users, sessions, accounts, conversations, messages, webhook_events, audit_log, meta

- account identity: unique(provider, external_id) เมื่อเป็นบัญชีจริง
- conversation identity: unique(account_id, remote_id); ไม่รวมบุคคลจากต่างช่องทางด้วยชื่อที่เหมือนกัน
- inbound dedup: unique(account_id, event_id), บันทึกพร้อมข้อความใน transaction
- outbound dedup: unique(conversation_id, client_id), คีย์เดิมต้องเป็นเนื้อหาเดิม
- query indexes สำหรับสถานะ/บัญชี/เวลา, ประวัติข้อความ และคิว
- จำกัดรายการกล่องข้อความ 500 บทสนทนา และประวัติต่อห้อง 1,000 ข้อความ; pagination และ archive เป็นงานต่อไป

## การป้องกันข้อมูล

รหัสผ่านผู้ดูแล PBKDF2-HMAC-SHA256 600,000 รอบ พร้อม random salt; session token สุ่มและเก็บเฉพาะ SHA-256 ใน DB, cookie HttpOnly/SameSite Strict อายุ 12 ชั่วโมง และ Secure เมื่อกำหนด public HTTPS

Credentials เข้ารหัส AES-256-GCM ก่อนบันทึก DB ใช้ GOCHAT_MASTER_KEY หรือไฟล์ master.key สิทธิ์ 0600 ใน data directory สิทธิ์ 0700 ห้ามเปิดเผย key/DB/token และอย่า commit data directory การเข้ารหัสนี้ไม่ป้องกันผู้ที่ยึดเครื่องและอ่านได้ทั้ง key กับ DB

API ต้องล็อกอิน ยกเว้น setup/login/auth-status; webhook ใช้ signature ของผู้ให้บริการ ตรวจ Origin/Host/JSON ของคำขอแก้ข้อมูล; ไม่เปิด CORS และไม่เชื่อถือ forwarded headers โดยอัตโนมัติ ตั้ง public URL ให้ตรงโดเมนจริง

สร้างผู้ดูแลครั้งแรกผ่าน loopback ก่อนเปิด reverse proxy สู่อินเทอร์เน็ต ไม่มีผู้ใช้/รหัสผ่านเริ่มต้น ระบบปัจจุบันเป็นหนึ่ง workspace หลายผู้ใช้ โดย admin จัดการค่าระบบ ส่วน agent อ่าน/ตอบ inbox ร่วมกัน ไม่มี tenant isolation ระดับ SaaS หรือจำกัดการเห็นแชทเป็นรายทีม จึงต้องเพิ่มและทดสอบก่อนใช้งานเป็นระบบหลายองค์กร

## สำรองและขยายระบบ

หยุดบริการก่อนคัดลอก data directory ทั้งชุด (DB, WAL ถ้ามี และ master.key); หรือใช้ SQLite online backup เก็บ snapshot DB ที่สอดคล้องกันและสำรอง key แยกตามนโยบาย ทดสอบ restore ก่อนใช้งานจริง ห้ามคัดลอกเฉพาะ DB ระหว่างเปิด WAL แล้วถือว่าเป็น backup สมบูรณ์

สิ่งที่ควรพัฒนาต่อ: OAuth onboarding/refresh/revocation, templates และ delivery receipts, media storage, tenant isolation และ account-level access, paginated inbox/history, retention/export/delete, connector health monitoring, retry เฉพาะ provider ที่รับประกัน idempotency, reconciliation, full-text search, Telegram TDLib และตัวเชื่อมต่อที่ยังเป็นแผน

## การทดสอบ

การทดสอบอัตโนมัติใช้ httptest และข้อมูลสังเคราะห์ ตรวจ authentication, data persistence, signature, account routing, duplicate webhook, 24-hour policy, queue และ API response ไม่มีการส่งข้อความไปหาบุคคลจริง การยืนยันใช้งานจริงต้องทดสอบด้วยบัญชีที่ผู้ใช้อนุญาตทั้งขารับและขาส่ง จึงจะนับว่าผ่าน end-to-end ของแต่ละค่าย

## Callback สำหรับหลายบัญชีในแอปเดียว

Meta ใช้ `/webhooks/meta` และ Slack ใช้ `/webhooks/slack` เป็น callback กลาง จึงไม่ต้องสลับ URL เมื่อเพิ่มหลายเพจหรือหลาย workspace ในแอปเดียว ระบบตรวจ secret ของแต่ละ connection แล้วแยกตาม Page/Instagram/Phone number ID หรือ Slack team ID พร้อม dedup แยกบัญชี; callback เฉพาะบัญชียังคงรองรับ LINE และ Telegram ใช้ URL เฉพาะบัญชีตาม channel/bot ของตน

เว็บมี WebMCP แบบ optional สำหรับค้นหาและเปิดบทสนทนา (การเปิดจะ mark read) มีการตรวจ contract ด้วย context จำลอง; ยังไม่ได้ทดสอบกับ browser WebMCP runtime จริง การส่งออกภายนอกยังทำผ่านการกดส่งในหน้าเว็บตามปกติ

## ข้อมูลและการควบคุมงานทีม/บอท

Migration แบบเพิ่มคอลัมน์และตาราง เก็บข้อมูลเดิม: users เพิ่ม role/active, conversations เพิ่ม email/phone/company/address/case_summary/bot_mode, เพิ่ม saved_replies/tag_presets/bot_settings/bot_rules/bot_logs ตรวจคอลัมน์ก่อน ALTER เพื่อให้เปิดฐานข้อมูลเดิมซ้ำได้

สมาชิก agent ไม่มีสิทธิ์แก้บัญชีเชื่อมต่อ ทีม คลังคำตอบ/แท็ก หรือบอท และไม่มีสิทธิ์ export; API ตรวจ role ฝั่ง server ทุกครั้ง การปิดสมาชิกเพิกถอน session และล้าง assignment เดิม ห้ามผู้ดูแลปิด/ลดสิทธิ์ตัวเอง และต้องมี admin active อย่างน้อยหนึ่งคน

กฎ FAQ ประเมินภายใน transaction เดียวกับ dedup webhook และบันทึกข้อความเข้า ไม่เรียก HTTP ขณะถือ transaction เลือกกฎตาม priority สูงไปต่ำ ระดับเท่ากันเรียง id มี global switch, เวลาบอท และ bot_mode แยกห้อง คำถามไม่ตรงกฎหรือพบคำขอเจ้าหน้าที่จะเปลี่ยนห้องเป็น human; บอทอาจส่ง acknowledgement ที่ตั้งไว้ครั้งเดียว

เมื่อคนตอบจริง (ไม่ใช่ internal note) ระบบเปลี่ยนเป็น human และยกเลิก bot ที่ยัง queued Worker ตรวจสถานะบอทอีกครั้งก่อนส่ง กรณี API เริ่มส่งแล้วไม่สามารถเรียกคืนได้ ข้อความ uncertain ยังคงไม่ retry อัตโนมัติ

Flow รุ่นนี้เป็นเงื่อนไขคำสำคัญ → คำตอบหรือส่งต่อ; ยังไม่เก็บขั้นบทสนทนา/ตัวแปรแบบ stateful flow และยังไม่มีการตั้งเวลาปฏิบัติงานเจ้าหน้าที่แยกจากเวลาบอท การรายงานที่มีคือผลการจับคู่กฎ, assignment, สถานะและข้อความ, audit log พร้อม CSV ไม่ใช่ SLA เต็มรูปแบบ (รุ่นปัจจุบันเพิ่มเวลาถึงการกดตอบตามนิยามในเอกสาร Zaapi)


## Helpdesk และ Website Chat

เพิ่มตาราง saved_views, reply_metrics, workflow_settings/rules/logs และ widgets/widget_visitors พร้อมคอลัมน์เวลารอ/นัดติดตาม/ผลการขายบน conversations การอัปเกรดใช้ additive migration โดยไม่ลบข้อมูลเดิม

เส้นทาง inbound หลัง dedup: เก็บข้อความ → เปิดรอบรอเจ้าหน้าที่ → กฎจัดการงาน → FAQ Bot → commit เมื่อคนกดตอบจะบันทึก metric พร้อมข้อความใน transaction เดียวกัน ไม่รวมโน้ตหรือบอท กฎจัดการงานไม่ส่งข้อความเอง

Widget ส่งเข้าผ่าน ingest เดียวกัน Worker ของ provider website ตรวจสถานะช่องทางและ session แล้วทำข้อความสาธารณะให้อ่านได้ใน SQLite โดยไม่เรียก HTTP ภายนอก สถานะ sent ของเว็บไซต์หมายถึงเผยแพร่ให้ widget อ่านได้ ไม่ใช่ผู้รับอ่านแล้ว ค่า default CSP ของแอปคงเดิม มีเฉพาะ iframe widget ที่กำหนด frame-ancestors ตาม origin ที่ผู้ดูแลระบุ

ดู API วิธีใช้ นิยามตัวเลข และขอบเขตการฝังเว็บไซต์ใน [เอกสารต่อยอด Zaapi](zaapi-features.md)

## TikTok Business connector

TikTok is an official API adapter with a shared application-level signed callback. Its app credentials, refresh tokens and returned expiry times remain in encrypted account credentials, without an additional schema migration. A process mutex serializes token renewal, with a database compare-and-swap preventing concurrent credential replacement. Network calls never hold a SQLite transaction. Explicit provider rejection is failed; uncertain deliveries remain uncertain and are not automatically retried. Callback setup uses the configured public HTTPS origin. See [TikTok details](/docs/tiktok).