Mainstream messaging

Signal

وضعیت: یکپارچه‌سازی CLI خارجی. Gateway از طریق HTTP با signal-cli صحبت می‌کند — یا daemon بومی (JSON-RPC + SSE) یا کانتینر bbernhard/signal-cli-rest-api (REST + WebSocket).

پیش‌نیازها

OpenClaw روی سرور شما نصب شده باشد (جریان Linux زیر روی Ubuntu 24 آزموده شده است).
یکی از موارد زیر:
- signal-cli روی میزبان در دسترس باشد (حالت بومی)، یا
- کانتینر Docker به نام bbernhard/signal-cli-rest-api (حالت کانتینر).
یک شماره تلفن که بتواند یک پیامک تأیید دریافت کند (برای مسیر ثبت‌نام پیامکی).
دسترسی مرورگر برای کپچای Signal (signalcaptchas.org) هنگام ثبت‌نام.

راه‌اندازی سریع (مبتدی)

از یک شماره Signal جداگانه برای ربات استفاده کنید (توصیه‌شده).
Plugin مربوط به OpenClaw را نصب کنید:

bash

openclaw plugins install @openclaw/signal

signal-cli را نصب کنید (اگر از ساخت JVM استفاده می‌کنید، Java لازم است).
یک مسیر راه‌اندازی انتخاب کنید:
- مسیر A (پیوند QR): signal-cli link -n "OpenClaw" و اسکن با Signal.
- مسیر B (ثبت‌نام پیامکی): ثبت یک شماره اختصاصی با کپچا + تأیید پیامکی.
OpenClaw را پیکربندی کنید و gateway را راه‌اندازی مجدد کنید.
یک DM اولیه بفرستید و جفت‌سازی را تأیید کنید (openclaw pairing approve signal <CODE>).

پیکربندی حداقلی:

json5

{  channels: {    signal: {      enabled: true,      account: "+15551234567",      cliPath: "signal-cli",      dmPolicy: "pairing",      allowFrom: ["+15557654321"],    },  },}

مرجع فیلدها:

فیلد	توضیح
`account`	شماره تلفن ربات در قالب E.164 (`+15551234567`)
`cliPath`	مسیر `signal-cli` (`signal-cli` اگر در `PATH` باشد)
`configPath`	پوشه پیکربندی signal-cli که به‌صورت `--config` داده می‌شود
`dmPolicy`	سیاست دسترسی DM (`pairing` توصیه می‌شود)
`allowFrom`	شماره‌های تلفن یا مقادیر `uuid:<id>` مجاز برای DM

چیستی آن

کانال Signal از طریق signal-cli (نه libsignal جاسازی‌شده).
مسیریابی قطعی: پاسخ‌ها همیشه به Signal برمی‌گردند.
DMها نشست اصلی agent را به اشتراک می‌گذارند؛ گروه‌ها ایزوله هستند (agent:<agentId>:signal:group:<groupId>).

نوشتن پیکربندی

به‌طور پیش‌فرض، Signal مجاز است به‌روزرسانی‌های پیکربندی را که با /config set|unset فعال می‌شوند بنویسد (نیازمند commands.config: true).

برای غیرفعال‌سازی:

json5

{  channels: { signal: { configWrites: false } },}

مدل شماره (مهم)

gateway به یک دستگاه Signal وصل می‌شود (حساب signal-cli).
اگر ربات را روی حساب شخصی Signal خودتان اجرا کنید، پیام‌های خودتان را نادیده می‌گیرد (محافظت در برابر حلقه).
برای «من به ربات پیام می‌دهم و پاسخ می‌دهد»، از یک شماره ربات جداگانه استفاده کنید.

مسیر راه‌اندازی A: پیوند دادن حساب Signal موجود (QR)

signal-cli را نصب کنید (ساخت JVM یا بومی).
یک حساب ربات را پیوند دهید:
- signal-cli link -n "OpenClaw" سپس QR را در Signal اسکن کنید.
Signal را پیکربندی کنید و gateway را شروع کنید.

نمونه:

json5

{  channels: {    signal: {      enabled: true,      account: "+15551234567",      cliPath: "signal-cli",      dmPolicy: "pairing",      allowFrom: ["+15557654321"],    },  },}

پشتیبانی چندحسابی: از channels.signal.accounts با پیکربندی جداگانه برای هر حساب و name اختیاری استفاده کنید. برای الگوی مشترک، gateway/configuration را ببینید.

مسیر راه‌اندازی B: ثبت شماره ربات اختصاصی (SMS، Linux)

وقتی یک شماره اختصاصی ربات می‌خواهید و نمی‌خواهید یک حساب برنامه Signal موجود را پیوند دهید، از این روش استفاده کنید.

شماره‌ای تهیه کنید که بتواند SMS دریافت کند (یا تأیید صوتی برای خطوط ثابت).
- برای جلوگیری از تداخل حساب/نشست، از یک شماره ربات اختصاصی استفاده کنید.
signal-cli را روی میزبان gateway نصب کنید:

bash

VERSION=$(curl -Ls -o /dev/null -w %{url_effective} https://github.com/AsamK/signal-cli/releases/latest | sed -e 's/^.*\/v//')curl -L -O "https://github.com/AsamK/signal-cli/releases/download/v${VERSION}/signal-cli-${VERSION}-Linux-native.tar.gz"sudo tar xf "signal-cli-${VERSION}-Linux-native.tar.gz" -C /optsudo ln -sf /opt/signal-cli /usr/local/bin/signal-cli --version

اگر از ساخت JVM (signal-cli-${VERSION}.tar.gz) استفاده می‌کنید، ابتدا JRE 25+ را نصب کنید. signal-cli را به‌روز نگه دارید؛ بالادست یادآوری می‌کند که نسخه‌های قدیمی ممکن است با تغییر APIهای سرور Signal از کار بیفتند.

شماره را ثبت و تأیید کنید:

bash

signal-cli -a +&lt;BOT_PHONE_NUMBER&gt; register

اگر کپچا لازم بود:

https://signalcaptchas.org/registration/generate.html را باز کنید.
کپچا را کامل کنید، مقصد پیوند signalcaptcha://... را از "Open Signal" کپی کنید.
در صورت امکان، از همان IP خارجی نشست مرورگر اجرا کنید.
بلافاصله دوباره ثبت‌نام را اجرا کنید (توکن‌های کپچا سریع منقضی می‌شوند):

bash

signal-cli -a +&lt;BOT_PHONE_NUMBER&gt; register --captcha '&lt;SIGNALCAPTCHA_URL&gt;'signal-cli -a +&lt;BOT_PHONE_NUMBER&gt; verify &lt;VERIFICATION_CODE&gt;

OpenClaw را پیکربندی کنید، gateway را راه‌اندازی مجدد کنید، کانال را تأیید کنید:

bash

# If you run the gateway as a user systemd service:systemctl --user restart openclaw-gateway.service # Then verify:openclaw doctoropenclaw channels status --probe

فرستنده DM خود را جفت کنید:
- هر پیامی به شماره ربات بفرستید.
- کد را روی سرور تأیید کنید: openclaw pairing approve signal <PAIRING_CODE>.
- شماره ربات را در گوشی خود به‌عنوان مخاطب ذخیره کنید تا از نمایش "Unknown contact" جلوگیری شود.

مراجع بالادست:

README مربوط به signal-cli: https://github.com/AsamK/signal-cli
جریان کپچا: https://github.com/AsamK/signal-cli/wiki/Registration-with-captcha
جریان پیوند دادن: https://github.com/AsamK/signal-cli/wiki/Linking-other-devices-(Provisioning)

حالت daemon خارجی (httpUrl)

اگر می‌خواهید signal-cli را خودتان مدیریت کنید (شروع سرد کند JVM، آغازگر کانتینر، یا CPUهای اشتراکی)، daemon را جداگانه اجرا کنید و OpenClaw را به آن نشانه بگیرید:

json5

{  channels: {    signal: {      httpUrl: "http://127.0.0.1:8080",      autoStart: false,    },  },}

این کار auto-spawn و انتظار شروع داخل OpenClaw را رد می‌کند. برای شروع‌های کند هنگام auto-spawn، channels.signal.startupTimeoutMs را تنظیم کنید.

حالت کانتینر (bbernhard/signal-cli-rest-api)

به‌جای اجرای بومی signal-cli، می‌توانید از کانتینر Docker به نام bbernhard/signal-cli-rest-api استفاده کنید. این کانتینر signal-cli را پشت یک REST API و رابط WebSocket قرار می‌دهد.

نیازمندی‌ها:

کانتینر برای دریافت پیام بلادرنگ باید با MODE=json-rpc اجرا شود.
پیش از اتصال OpenClaw، حساب Signal خود را داخل کانتینر ثبت یا پیوند دهید.

نمونه سرویس docker-compose.yml:

yaml

signal-cli:  image: bbernhard/signal-cli-rest-api:latest  environment:    MODE: json-rpc  ports:    - "8080:8080"  volumes:    - signal-cli-data:/home/.local/share/signal-cli

پیکربندی OpenClaw:

json5

{  channels: {    signal: {      enabled: true,      account: "+15551234567",      httpUrl: "http://signal-cli:8080",      autoStart: false,      apiMode: "container", // or "auto" to detect automatically    },  },}

فیلد apiMode کنترل می‌کند OpenClaw از کدام پروتکل استفاده کند:

مقدار	رفتار
`"auto"`	(پیش‌فرض) هر دو انتقال را probe می‌کند؛ streaming دریافت WebSocket کانتینر را اعتبارسنجی می‌کند
`"native"`	اجبار به signal-cli بومی (JSON-RPC در `/api/v1/rpc`، SSE در `/api/v1/events`)
`"container"`	اجبار به کانتینر bbernhard (REST در `/v2/send`، WebSocket در `/v1/receive/{account}`)

وقتی apiMode برابر "auto" باشد، OpenClaw حالت شناسایی‌شده را برای ۳۰ ثانیه cache می‌کند تا از probeهای تکراری جلوگیری شود. دریافت کانتینر فقط پس از ارتقای /v1/receive/{account} به WebSocket برای streaming انتخاب می‌شود، که نیازمند MODE=json-rpc است.

حالت کانتینر همان عملیات کانال Signal را مانند حالت بومی پشتیبانی می‌کند، تا جایی که کانتینر APIهای متناظر را ارائه دهد: ارسال‌ها، دریافت‌ها، پیوست‌ها، نشانگرهای تایپ، رسیدهای خواندن/دیده‌شدن، واکنش‌ها، گروه‌ها و متن سبک‌دار. OpenClaw فراخوانی‌های RPC بومی Signal خود را به payloadهای REST کانتینر ترجمه می‌کند، از جمله شناسه‌های گروه group.{base64(internal_id)} و text_mode: "styled" برای متن قالب‌بندی‌شده.

نکات عملیاتی:

با حالت کانتینر از autoStart: false استفاده کنید. وقتی apiMode: "container" انتخاب شده است، OpenClaw نباید daemon بومی را spawn کند.
برای دریافت، از MODE=json-rpc استفاده کنید. MODE=normal می‌تواند باعث شود /v1/about سالم به نظر برسد، اما /v1/receive/{account} به WebSocket ارتقا پیدا نمی‌کند، بنابراین OpenClaw در حالت auto دریافت streaming کانتینر را انتخاب نمی‌کند.
وقتی می‌دانید httpUrl به REST API مربوط به bbernhard اشاره می‌کند، apiMode: "container" را تنظیم کنید. وقتی می‌دانید به JSON-RPC/SSE بومی signal-cli اشاره می‌کند، apiMode: "native" را تنظیم کنید. وقتی deployment ممکن است متفاوت باشد، از "auto" استفاده کنید.
دانلود پیوست در حالت کانتینر همان محدودیت‌های بایت رسانه را مانند حالت بومی رعایت می‌کند. پاسخ‌های بیش‌ازحد بزرگ وقتی سرور Content-Length بفرستد پیش از buffer کامل رد می‌شوند، و در غیر این صورت هنگام streaming رد می‌شوند.

کنترل دسترسی (DMها + گروه‌ها)

DMها:

پیش‌فرض: channels.signal.dmPolicy = "pairing".
فرستنده‌های ناشناس یک کد جفت‌سازی دریافت می‌کنند؛ پیام‌ها تا زمان تأیید نادیده گرفته می‌شوند (کدها پس از ۱ ساعت منقضی می‌شوند).
تأیید از طریق:
- openclaw pairing list signal
- openclaw pairing approve signal <CODE>
Pairing تبادل توکن پیش‌فرض برای DMهای Signal است. جزئیات: Pairing
فرستنده‌های فقط UUID (از sourceUuid) به‌صورت uuid:<id> در channels.signal.allowFrom ذخیره می‌شوند.

گروه‌ها:

channels.signal.groupPolicy = open | allowlist | disabled.
channels.signal.groupAllowFrom کنترل می‌کند وقتی allowlist تنظیم شده است کدام گروه‌ها یا فرستنده‌ها بتوانند پاسخ‌های گروهی را فعال کنند؛ ورودی‌ها می‌توانند شناسه‌های گروه Signal (خام، group:<id>، یا signal:group:<id>)، شماره‌های تلفن فرستنده، مقادیر uuid:<id>، یا * باشند.
channels.signal.groups["<group-id>" | "*"] می‌تواند رفتار گروه را با requireMention، tools، و toolsBySender بازنویسی کند.
برای بازنویسی‌های مخصوص هر حساب در راه‌اندازی‌های چندحسابی، از channels.signal.accounts.<id>.groups استفاده کنید.
allowlist کردن یک گروه Signal از طریق groupAllowFrom به‌خودی‌خود gating ذکر را غیرفعال نمی‌کند. یک ورودی مشخصاً پیکربندی‌شده channels.signal.groups["<group-id>"] هر پیام گروه را پردازش می‌کند، مگر اینکه requireMention=true تنظیم شده باشد.
نکته runtime: اگر channels.signal کاملاً وجود نداشته باشد، runtime برای بررسی‌های گروه به groupPolicy="allowlist" برمی‌گردد (حتی اگر channels.defaults.groupPolicy تنظیم شده باشد).

نحوه کارکرد (رفتار)

حالت بومی: signal-cli به‌عنوان daemon اجرا می‌شود؛ gateway رویدادها را از طریق SSE می‌خواند.
حالت کانتینر: gateway از طریق REST API ارسال می‌کند و از طریق WebSocket دریافت می‌کند.
پیام‌های ورودی به envelope مشترک کانال normalize می‌شوند.
پاسخ‌ها همیشه به همان شماره یا گروه برمی‌گردند.

رسانه + محدودیت‌ها

متن خروجی تا channels.signal.textChunkLimit تکه‌تکه می‌شود (پیش‌فرض ۴۰۰۰).
تکه‌تکه‌سازی اختیاری بر اساس خط جدید: channels.signal.chunkMode="newline" را تنظیم کنید تا پیش از تکه‌تکه‌سازی طولی، بر اساس خطوط خالی (مرزهای پاراگراف) تقسیم شود.
پیوست‌ها پشتیبانی می‌شوند (base64 از signal-cli دریافت می‌شود).
پیوست‌های یادداشت صوتی وقتی contentType وجود نداشته باشد از نام فایل signal-cli به‌عنوان fallback برای MIME استفاده می‌کنند، بنابراین رونویسی صوتی همچنان می‌تواند یادداشت‌های صوتی AAC را دسته‌بندی کند.
سقف رسانه پیش‌فرض: channels.signal.mediaMaxMb (پیش‌فرض ۸).
برای رد کردن دانلود رسانه، از channels.signal.ignoreAttachments استفاده کنید.
زمینه تاریخچه گروه از channels.signal.historyLimit (یا channels.signal.accounts.*.historyLimit) استفاده می‌کند و به messages.groupChat.historyLimit fallback می‌کند. برای غیرفعال‌سازی، 0 را تنظیم کنید (پیش‌فرض ۵۰).

تایپ + رسیدهای خواندن

نشانگرهای تایپ: OpenClaw سیگنال‌های تایپ را از طریق signal-cli sendTyping می‌فرستد و تا زمانی که پاسخ در حال اجراست آن‌ها را تازه‌سازی می‌کند.
رسیدهای خواندن: وقتی channels.signal.sendReadReceipts برابر true باشد، OpenClaw رسیدهای خواندن را برای پیام‌های مستقیم مجاز ارسال می‌کند.
signal-cli رسیدهای خواندن را برای گروه‌ها ارائه نمی‌کند.

واکنش‌های وضعیت چرخه حیات

messages.statusReactions.enabled: true را تنظیم کنید تا Signal چرخه حیات واکنش مشترک در صف/در حال فکر کردن/ابزار/Compaction/انجام‌شده/خطا را در نوبت‌های ورودی نشان دهد. Signal از زمان‌سنج پیام ورودی به عنوان هدف واکنش استفاده می‌کند؛ واکنش‌های گروهی با شناسه گروه Signal به همراه فرستنده اصلی به عنوان نویسنده هدف ارسال می‌شوند.

واکنش‌های وضعیت همچنین به یک واکنش تأیید و یک messages.ackReactionScope مطابق (direct، group-all، group-mentions، یا all) نیاز دارند. برای غیرفعال کردن واکنش‌های وضعیت Signal، channels.signal.reactionLevel: "off" را تنظیم کنید. کنش react در ابزار پیام سخت‌گیرانه‌تر باقی می‌ماند: به reactionLevel: "minimal" یا "extensive" نیاز دارد.

messages.removeAckAfterReply: true واکنش وضعیت نهایی را پس از زمان نگهداری پیکربندی‌شده پاک می‌کند. در غیر این صورت Signal پس از وضعیت نهایی انجام‌شده/خطا، واکنش تأیید اولیه را برمی‌گرداند.

واکنش‌ها (ابزار پیام)

از message action=react همراه با channel=signal استفاده کنید.
اهداف: E.164 یا UUID فرستنده (از uuid:<id> در خروجی جفت‌سازی استفاده کنید؛ UUID بدون پیشوند هم کار می‌کند).
messageId زمان‌سنج Signal برای پیامی است که به آن واکنش نشان می‌دهید.
واکنش‌های گروهی به targetAuthor یا targetAuthorUuid نیاز دارند.

نمونه‌ها:

Code

message action=react channel=signal target=uuid:123e4567-e89b-12d3-a456-426614174000 messageId=1737630212345 emoji=🔥message action=react channel=signal target=+15551234567 messageId=1737630212345 emoji=🔥 remove=truemessage action=react channel=signal target=signal:group:<groupId> targetAuthor=uuid:<sender-uuid> messageId=1737630212345 emoji=✅

پیکربندی:

channels.signal.actions.reactions: کنش‌های واکنش را فعال/غیرفعال کنید (پیش‌فرض true).
channels.signal.reactionLevel: off | ack | minimal | extensive.
- off/ack واکنش‌های عامل را غیرفعال می‌کند (ابزار پیام react خطا خواهد داد).
- minimal/extensive واکنش‌های عامل را فعال می‌کند و سطح راهنمایی را تنظیم می‌کند.
بازنویسی‌های هر حساب: channels.signal.accounts.<id>.actions.reactions، channels.signal.accounts.<id>.reactionLevel.

واکنش‌های تأیید

درخواست‌های تأیید اجرای Signal و Plugin از بلوک‌های مسیریابی سطح بالای approvals.exec و approvals.plugin استفاده می‌کنند. Signal بلوک channels.signal.execApprovals ندارد.

👍 یک بار تأیید می‌کند.
👎 رد می‌کند.
وقتی درخواستی تأیید پایدار ارائه می‌دهد، از /approve <id> allow-always استفاده کنید.

حل واکنش تأیید به تأییدکنندگان صریح Signal از channels.signal.allowFrom، channels.signal.defaultTo، یا فیلدهای سطح حساب مطابق نیاز دارد. درخواست‌های تأیید اجرای مستقیم در همان گفت‌وگو همچنان می‌توانند جایگزین محلی تکراری /approve را بدون تأییدکنندگان صریح پنهان کنند؛ تأییدهای گروهی بدون تأییدکننده، جایگزین محلی را قابل مشاهده نگه می‌دارند.

اهداف تحویل (CLI/cron)

پیام‌های مستقیم: signal:+15551234567 (یا E.164 ساده).
پیام‌های مستقیم UUID: uuid:<id> (یا UUID بدون پیشوند).
گروه‌ها: signal:group:<groupId>.
نام‌های کاربری: username:<name> (اگر حساب Signal شما پشتیبانی کند).

نام‌های مستعار

وقتی برای اهداف تکرارشونده Signal نام‌های پایدار می‌خواهید، نام‌های مستعار را پیکربندی کنید. نام‌های مستعار فقط پیکربندی سمت OpenClaw هستند؛ مخاطبان Signal را ایجاد یا ویرایش نمی‌کنند.

json5

{  channels: {    signal: {      aliases: {        me: "+15557654321",        jane: "uuid:123e4567-e89b-12d3-a456-426614174000",        ops: "group:<groupId>",      },      defaultTo: "signal:me",    },  },}

هر جا اهداف تحویل Signal پذیرفته می‌شوند، از نام‌های مستعار استفاده کنید:

bash

openclaw message send --channel signal --target signal:ops --message "Deployment is complete"

نام‌های مستعار هر حساب، نام‌های مستعار سطح بالا را به ارث می‌برند و می‌توانند نام‌ها را اضافه یا بازنویسی کنند:

json5

{  channels: {    signal: {      aliases: {        me: "+15557654321",      },      accounts: {        work: {          aliases: {            ops: "group:<workGroupId>",          },        },      },    },  },}

openclaw directory peers list --channel signal و openclaw directory groups list --channel signal نام‌های مستعار پیکربندی‌شده را فهرست می‌کنند. دایرکتوری Signal مبتنی بر پیکربندی است؛ مخاطبان Signal را به صورت زنده پرس‌وجو نمی‌کند یا حساب Signal را تغییر نمی‌دهد.

عیب‌یابی

ابتدا این نردبان را اجرا کنید:

bash

openclaw statusopenclaw gateway statusopenclaw logs --followopenclaw doctoropenclaw channels status --probe

سپس در صورت نیاز وضعیت جفت‌سازی پیام مستقیم را تأیید کنید:

bash

openclaw pairing list signal

خرابی‌های رایج:

Daemon در دسترس است اما پاسخی نیست: تنظیمات حساب/daemon (httpUrl، account) و حالت دریافت را بررسی کنید.
پیام‌های مستقیم نادیده گرفته می‌شوند: فرستنده در انتظار تأیید جفت‌سازی است.
پیام‌های گروهی نادیده گرفته می‌شوند: دروازه‌گذاری فرستنده/اشاره گروهی تحویل را مسدود می‌کند.
خطاهای اعتبارسنجی پیکربندی پس از ویرایش‌ها: openclaw doctor --fix را اجرا کنید.
Signal در عیب‌یابی وجود ندارد: تأیید کنید channels.signal.enabled: true است.

بررسی‌های اضافه:

bash

openclaw pairing list signalpgrep -af signal-cligrep -i "signal" "/tmp/openclaw/openclaw-$(date +%Y-%m-%d).log" | tail -20

برای جریان تریاژ: /channels/troubleshooting.

نکات امنیتی

signal-cli کلیدهای حساب را به صورت محلی ذخیره می‌کند (معمولاً در ~/.local/share/signal-cli/data/).
پیش از مهاجرت سرور یا بازسازی، از وضعیت حساب Signal پشتیبان بگیرید.
channels.signal.dmPolicy: "pairing" را نگه دارید مگر اینکه صریحاً دسترسی گسترده‌تر به پیام‌های مستقیم را بخواهید.
تأیید SMS فقط برای جریان‌های ثبت‌نام یا بازیابی لازم است، اما از دست دادن کنترل شماره/حساب می‌تواند ثبت‌نام دوباره را پیچیده کند.

مرجع پیکربندی (Signal)

پیکربندی کامل: پیکربندی

گزینه‌های ارائه‌دهنده:

channels.signal.enabled: راه‌اندازی کانال را فعال/غیرفعال کنید.
channels.signal.apiMode: auto | native | container (پیش‌فرض: auto). حالت کانتینر را ببینید.
channels.signal.account: E.164 برای حساب ربات.
channels.signal.cliPath: مسیر signal-cli.
channels.signal.configPath: دایرکتوری اختیاری signal-cli --config.
channels.signal.httpUrl: URL کامل daemon (میزبان/درگاه را بازنویسی می‌کند).
channels.signal.httpHost، channels.signal.httpPort: اتصال daemon (پیش‌فرض 127.0.0.1:8080).
channels.signal.autoStart: daemon را به صورت خودکار ایجاد کند (اگر httpUrl تنظیم نشده باشد، پیش‌فرض true).
channels.signal.startupTimeoutMs: مهلت انتظار راه‌اندازی بر حسب ms (سقف 120000).
channels.signal.receiveMode: on-start | manual.
channels.signal.ignoreAttachments: دانلود پیوست‌ها را رد کنید.
channels.signal.ignoreStories: داستان‌ها را از daemon نادیده بگیرید.
channels.signal.sendReadReceipts: رسیدهای خواندن را ارسال کنید.
channels.signal.dmPolicy: pairing | allowlist | open | disabled (پیش‌فرض: pairing).
channels.signal.allowFrom: فهرست مجاز پیام مستقیم (E.164 یا uuid:<id>). open به "*" نیاز دارد. Signal نام کاربری ندارد؛ از شناسه‌های تلفن/UUID استفاده کنید.
channels.signal.aliases: نام‌های مستعار سمت OpenClaw برای اهداف تحویل پیام مستقیم یا گروه.
channels.signal.groupPolicy: open | allowlist | disabled (پیش‌فرض: allowlist).
channels.signal.groupAllowFrom: فهرست مجاز گروه؛ شناسه‌های گروه Signal (خام، group:<id>، یا signal:group:<id>)، شماره‌های E.164 فرستنده، یا مقادیر uuid:<id> را می‌پذیرد.
channels.signal.groups: بازنویسی‌های هر گروه با کلید شناسه گروه Signal (یا "*"). فیلدهای پشتیبانی‌شده: requireMention، tools، toolsBySender.
channels.signal.accounts.<id>.groups: نسخه هر حساب از channels.signal.groups برای راه‌اندازی‌های چندحسابی.
channels.signal.accounts.<id>.aliases: نام‌های مستعار هر حساب، ادغام‌شده با نام‌های مستعار سطح بالا.
channels.signal.historyLimit: بیشترین پیام‌های گروهی برای گنجاندن به عنوان زمینه (0 غیرفعال می‌کند).
channels.signal.dmHistoryLimit: حد سابقه پیام مستقیم در نوبت‌های کاربر. بازنویسی‌های هر کاربر: channels.signal.dms["<phone_or_uuid>"].historyLimit.
channels.signal.textChunkLimit: اندازه قطعه خروجی (نویسه‌ها).
channels.signal.chunkMode: length (پیش‌فرض) یا newline برای تقسیم بر اساس خطوط خالی (مرزهای پاراگراف) پیش از قطعه‌بندی بر اساس طول.
channels.signal.mediaMaxMb: سقف رسانه ورودی/خروجی (MB).

گزینه‌های سراسری مرتبط:

agents.list[].groupChat.mentionPatterns (Signal از اشاره‌های بومی پشتیبانی نمی‌کند).
messages.groupChat.mentionPatterns (جایگزین سراسری).
messages.responsePrefix.

مرتبط

نمای کلی کانال‌ها — همه کانال‌های پشتیبانی‌شده
جفت‌سازی — احراز هویت پیام مستقیم و جریان جفت‌سازی
گروه‌ها — رفتار گفت‌وگوی گروهی و دروازه‌گذاری اشاره
مسیریابی کانال — مسیریابی نشست برای پیام‌ها
امنیت — مدل دسترسی و سخت‌سازی

Was this useful?

Signal

پیش‌نیازها

راه‌اندازی سریع (مبتدی)

چیستی آن

نوشتن پیکربندی

مدل شماره (مهم)

مسیر راه‌اندازی A: پیوند دادن حساب Signal موجود (QR)

مسیر راه‌اندازی B: ثبت شماره ربات اختصاصی (SMS، Linux)

حالت daemon خارجی (httpUrl)

حالت کانتینر (bbernhard/signal-cli-rest-api)

کنترل دسترسی (DMها + گروه‌ها)

نحوه کارکرد (رفتار)

رسانه + محدودیت‌ها

تایپ + رسیدهای خواندن

واکنش‌های وضعیت چرخه حیات

واکنش‌ها (ابزار پیام)

واکنش‌های تأیید

اهداف تحویل (CLI/cron)

نام‌های مستعار

عیب‌یابی

نکات امنیتی

مرجع پیکربندی (Signal)

مرتبط

On this page

Molty