From 0386a9fc2997692a569ed08b277d68b26f805f77 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Mon, 6 Apr 2026 03:37:43 +0000 Subject: [PATCH] chore(i18n): refresh uk translations --- docs/uk/channels/matrix.md | 600 +++++++++++++++++++------------------ 1 file changed, 303 insertions(+), 297 deletions(-) diff --git a/docs/uk/channels/matrix.md b/docs/uk/channels/matrix.md index a1c31aef4..07d04451f 100644 --- a/docs/uk/channels/matrix.md +++ b/docs/uk/channels/matrix.md @@ -2,29 +2,27 @@ read_when: - Налаштування Matrix в OpenClaw - Налаштування Matrix E2EE і верифікації -summary: Стан підтримки Matrix, налаштування та приклади конфігурації +summary: Статус підтримки Matrix, налаштування та приклади конфігурації title: Matrix x-i18n: - generated_at: "2026-04-06T01:20:16Z" + generated_at: "2026-04-06T03:37:42Z" model: gpt-5.4 provider: openai - source_hash: 3e2d84c08d7d5b96db14b914e54f08d25334401cdd92eb890bc8dfb37b0ca2dc + source_hash: 3dbcb2c01c4024d340af3ff6f8fc6f15b32241d98dfd5676c465bf8106e4dd7f source_path: channels/matrix.md workflow: 15 --- # Matrix -Matrix — це вбудований канальний плагін Matrix для OpenClaw. -Він використовує офіційний `matrix-js-sdk` і підтримує DM, кімнати, гілки, медіа, реакції, опитування, місцезнаходження та E2EE. +Matrix — це вбудований плагін каналу Matrix для OpenClaw. +Він використовує офіційний `matrix-js-sdk` і підтримує DM, кімнати, треди, медіа, реакції, опитування, геолокацію та E2EE. ## Вбудований плагін -Matrix постачається як вбудований плагін у поточних випусках OpenClaw, тому звичайним -зібраним пакетам не потрібне окреме встановлення. +Matrix постачається як вбудований плагін у поточних релізах OpenClaw, тому звичайним пакетованим збіркам не потрібне окреме встановлення. -Якщо у вас стара збірка або власне встановлення без Matrix, встановіть -його вручну: +Якщо ви використовуєте старішу збірку або користувацьке встановлення без Matrix, встановіть його вручну: Встановлення з npm: @@ -43,14 +41,14 @@ openclaw plugins install ./path/to/local/matrix-plugin ## Налаштування 1. Переконайтеся, що плагін Matrix доступний. - - У поточних пакетних випусках OpenClaw він уже вбудований. - - У старих/кастомних встановленнях його можна додати вручну командами вище. + - Поточні пакетовані релізи OpenClaw уже містять його. + - У старіших/користувацьких встановленнях його можна додати вручну наведеними вище командами. 2. Створіть обліковий запис Matrix на своєму homeserver. -3. Налаштуйте `channels.matrix` одним із таких способів: +3. Налаштуйте `channels.matrix`, використовуючи один із варіантів: - `homeserver` + `accessToken`, або - `homeserver` + `userId` + `password`. 4. Перезапустіть gateway. -5. Почніть DM із ботом або запросіть його до кімнати. +5. Почніть DM з ботом або запросіть його до кімнати. Шляхи інтерактивного налаштування: @@ -62,22 +60,22 @@ openclaw configure --section channels Що саме запитує майстер Matrix: - URL homeserver -- метод автентифікації: access token або пароль -- ID користувача лише якщо ви вибрали автентифікацію паролем +- метод автентифікації: токен доступу або пароль +- ID користувача лише якщо вибрано автентифікацію за паролем - необов’язкова назва пристрою - чи вмикати E2EE - чи налаштовувати доступ до кімнат Matrix зараз Важливі особливості роботи майстра: -- Якщо для вибраного облікового запису вже існують змінні середовища автентифікації Matrix, і для цього облікового запису ще не збережено автентифікацію в конфігурації, майстер пропонує скористатися змінними середовища і записує лише `enabled: true` для цього облікового запису. -- Коли ви інтерактивно додаєте інший обліковий запис Matrix, введена назва облікового запису нормалізується до ID облікового запису, який використовується в конфігурації та змінних середовища. Наприклад, `Ops Bot` стає `ops-bot`. -- Підказки allowlist для DM одразу приймають повні значення `@user:server`. Відображувані імена працюють лише тоді, коли пошук у живому каталозі знаходить одну точну відповідність; інакше майстер просить повторити спробу з повним Matrix ID. -- Підказки allowlist для кімнат безпосередньо приймають ID кімнат і псевдоніми. Вони також можуть у реальному часі визначати назви приєднаних кімнат, але невизначені назви зберігаються лише у введеному вигляді під час налаштування і потім ігноруються під час визначення allowlist у runtime. Віддавайте перевагу `!room:server` або `#alias:server`. -- Ідентичність кімнати/сеансу в runtime використовує стабільний ID кімнати Matrix. Псевдоніми, оголошені в кімнаті, використовуються лише як вхідні дані для пошуку, а не як довгостроковий ключ сеансу чи стабільна ідентичність групи. -- Щоб визначити назви кімнат перед їх збереженням, використовуйте `openclaw channels resolve --channel matrix "Project Room"`. +- Якщо змінні середовища автентифікації Matrix уже існують для вибраного облікового запису, і для цього облікового запису автентифікацію ще не збережено в конфігурації, майстер пропонує скористатися env-ярликом і записує для цього облікового запису лише `enabled: true`. +- Коли ви інтерактивно додаєте ще один обліковий запис Matrix, введена назва облікового запису нормалізується до ID облікового запису, який використовується в конфігурації та змінних середовища. Наприклад, `Ops Bot` стає `ops-bot`. +- Підказки allowlist для DM одразу приймають повні значення `@user:server`. Відображувані імена працюють лише тоді, коли живий пошук у каталозі знаходить один точний збіг; інакше майстер попросить повторити спробу з повним Matrix ID. +- Підказки allowlist для кімнат напряму приймають ID кімнат і псевдоніми. Вони також можуть у реальному часі розпізнавати назви приєднаних кімнат, але нерозпізнані назви зберігаються лише в тому вигляді, як були введені під час налаштування, і пізніше ігноруються під час виконання runtime-розв’язання allowlist. Надавайте перевагу `!room:server` або `#alias:server`. +- Runtime-ідентичність кімнати/сесії використовує стабільний Matrix room ID. Оголошені кімнатою псевдоніми використовуються лише як вхідні дані для пошуку, а не як довгостроковий ключ сесії чи стабільний ідентифікатор групи. +- Щоб розв’язати назви кімнат перед збереженням, використовуйте `openclaw channels resolve --channel matrix "Project Room"`. -Мінімальне налаштування на основі token: +Мінімальне налаштування на основі токена: ```json5 { @@ -92,7 +90,7 @@ openclaw configure --section channels } ``` -Налаштування на основі пароля (token кешується після входу): +Налаштування на основі пароля (після входу токен кешується): ```json5 { @@ -109,8 +107,8 @@ openclaw configure --section channels ``` Matrix зберігає кешовані облікові дані в `~/.openclaw/credentials/matrix/`. -Обліковий запис за замовчуванням використовує `credentials.json`; іменовані облікові записи — `credentials-.json`. -Коли кешовані облікові дані існують там, OpenClaw вважає Matrix налаштованим для setup, doctor і виявлення стану каналу, навіть якщо поточну автентифікацію не задано безпосередньо в конфігурації. +Обліковий запис за замовчуванням використовує `credentials.json`; іменовані облікові записи використовують `credentials-.json`. +Коли там існують кешовані облікові дані, OpenClaw вважає Matrix налаштованим для setup, doctor і виявлення channel-status, навіть якщо поточна автентифікація не задана безпосередньо в конфігурації. Еквіваленти змінних середовища (використовуються, коли ключ конфігурації не задано): @@ -121,7 +119,7 @@ Matrix зберігає кешовані облікові дані в `~/.opencl - `MATRIX_DEVICE_ID` - `MATRIX_DEVICE_NAME` -Для неосновних облікових записів використовуйте змінні середовища з областю облікового запису: +Для облікових записів не за замовчуванням використовуйте змінні середовища з областю облікового запису: - `MATRIX__HOMESERVER` - `MATRIX__ACCESS_TOKEN` @@ -140,10 +138,10 @@ Matrix зберігає кешовані облікові дані в `~/.opencl - `MATRIX_OPS_X2D_BOT_HOMESERVER` - `MATRIX_OPS_X2D_BOT_ACCESS_TOKEN` -Matrix екранує розділові знаки в ID облікових записів, щоб уникнути колізій у змінних середовища з областю облікового запису. -Наприклад, `-` стає `_X2D_`, тож `ops-prod` перетворюється на `MATRIX_OPS_X2D_PROD_*`. +Matrix екранує розділові символи в ID облікових записів, щоб уникнути колізій змінних середовища з областю. +Наприклад, `-` перетворюється на `_X2D_`, тому `ops-prod` відповідає `MATRIX_OPS_X2D_PROD_*`. -Інтерактивний майстер пропонує скористатися змінними середовища лише тоді, коли ці змінні автентифікації вже наявні, а для вибраного облікового запису ще не збережено автентифікацію Matrix у конфігурації. +Інтерактивний майстер пропонує env-ярлик лише тоді, коли ці змінні середовища автентифікації вже присутні, а для вибраного облікового запису ще не збережено автентифікацію Matrix у конфігурації. ## Приклад конфігурації @@ -182,13 +180,20 @@ Matrix екранує розділові знаки в ID облікових з } ``` -## Попередній перегляд під час streaming +`autoJoin` застосовується до запрошень Matrix загалом, а не лише до запрошень у кімнати/групи. +Це включає нові запрошення у стилі DM. На момент запрошення OpenClaw не може надійно знати, чи +запрошена кімната зрештою вважатиметься DM чи групою, тому всі запрошення спочатку проходять через +одне й те саме рішення `autoJoin`. `dm.policy` усе ще застосовується після того, як бот приєднається +та кімнату буде класифіковано як DM, тож `autoJoin` керує поведінкою приєднання, а `dm.policy` — +поведінкою відповідей/доступу. -Потокове надсилання відповідей Matrix вмикається лише за бажанням. +## Попередній перегляд потокових відповідей -Установіть `channels.matrix.streaming` у `"partial"`, якщо хочете, щоб OpenClaw надсилав один живий попередній -варіант відповіді, редагував його на місці, поки модель генерує текст, а потім фіналізував його, коли -відповідь буде готова: +Потокове надсилання відповідей Matrix вмикається лише за згодою. + +Встановіть `channels.matrix.streaming` у `"partial"`, якщо хочете, щоб OpenClaw надсилав одну живу +попередню відповідь, редагував цей попередній перегляд на місці, поки модель генерує текст, а потім +завершував його, коли відповідь буде готова: ```json5 { @@ -201,35 +206,35 @@ Matrix екранує розділові знаки в ID облікових з ``` - `streaming: "off"` — значення за замовчуванням. OpenClaw чекає на фінальну відповідь і надсилає її один раз. -- `streaming: "partial"` створює одне редаговане повідомлення-попередній перегляд для поточного блоку відповіді асистента за допомогою звичайних текстових повідомлень Matrix. Це зберігає успадковану для Matrix поведінку сповіщень за першим попереднім переглядом, тож стандартні клієнти можуть сповіщати про перший потоковий текст попереднього перегляду, а не про завершений блок. -- `streaming: "quiet"` створює одне редаговане тихе повідомлення-попередній перегляд для поточного блоку відповіді асистента. Використовуйте це лише тоді, коли ви також налаштували правила push для одержувачів щодо фіналізованих редагувань попереднього перегляду. -- `blockStreaming: true` вмикає окремі повідомлення прогресу Matrix. Коли ввімкнено попередній перегляд під час streaming, Matrix зберігає живу чернетку для поточного блоку та залишає завершені блоки як окремі повідомлення. -- Коли попередній перегляд увімкнено, а `blockStreaming` вимкнено, Matrix редагує живу чернетку на місці й фіналізує цю саму подію, коли блок або хід завершується. -- Якщо попередній перегляд більше не вміщується в одну подію Matrix, OpenClaw припиняє streaming попереднього перегляду й повертається до звичайної фінальної доставки. -- Відповіді з медіа все одно надсилають вкладення звичайним способом. Якщо застарілий попередній перегляд більше не можна безпечно повторно використати, OpenClaw редагує його перед надсиланням фінальної відповіді з медіа. -- Редагування попереднього перегляду потребують додаткових викликів Matrix API. Залишайте streaming вимкненим, якщо хочете найконсервативнішу поведінку щодо обмеження швидкості. +- `streaming: "partial"` створює одне редаговане повідомлення попереднього перегляду для поточного блоку асистента, використовуючи звичайні текстові повідомлення Matrix. Це зберігає застарілу поведінку Matrix зі сповіщенням за першим попереднім повідомленням, тому стандартні клієнти можуть сповіщати про перший потоковий попередній текст, а не про завершений блок. +- `streaming: "quiet"` створює одне редаговане тихе повідомлення-попередній перегляд для поточного блоку асистента. Використовуйте це лише тоді, коли також налаштовуєте правила push для одержувачів щодо фіналізованих редагувань попереднього перегляду. +- `blockStreaming: true` вмикає окремі повідомлення про прогрес Matrix. Коли потоковий попередній перегляд увімкнено, Matrix зберігає живу чернетку для поточного блоку та залишає завершені блоки як окремі повідомлення. +- Коли попередній потоковий перегляд увімкнений, а `blockStreaming` вимкнений, Matrix редагує живу чернетку на місці й фіналізує ту саму подію, коли блок або хід завершується. +- Якщо попередній перегляд більше не вміщується в одну подію Matrix, OpenClaw припиняє потоковий попередній перегляд і повертається до звичайної фінальної доставки. +- Відповіді з медіа й далі надсилають вкладення звичайним способом. Якщо застарілий попередній перегляд більше не можна безпечно повторно використати, OpenClaw редагує його перед надсиланням фінальної медіавідповіді. +- Редагування попереднього перегляду створюють додаткові виклики API Matrix. Залишайте streaming вимкненим, якщо хочете максимально консервативну поведінку щодо лімітів частоти. -`blockStreaming` сам по собі не вмикає попередні чернетки. -Використовуйте `streaming: "partial"` або `streaming: "quiet"` для редагування попереднього перегляду; потім додайте `blockStreaming: true`, лише якщо також хочете, щоб завершені блоки асистента залишалися видимими як окремі повідомлення прогресу. +`blockStreaming` сам по собі не вмикає чернетки попереднього перегляду. +Використовуйте `streaming: "partial"` або `streaming: "quiet"` для редагувань попереднього перегляду; потім додавайте `blockStreaming: true` лише якщо також хочете, щоб завершені блоки асистента залишалися видимими як окремі повідомлення про прогрес. -Якщо вам потрібні стандартні сповіщення Matrix без власних push-правил, використовуйте `streaming: "partial"` для поведінки з попереднім переглядом спочатку або залиште `streaming` вимкненим для доставки лише фінальної відповіді. Коли `streaming: "off"`: +Якщо вам потрібні стандартні сповіщення Matrix без користувацьких push-правил, використовуйте `streaming: "partial"` для поведінки з попереднім переглядом або залиште `streaming` вимкненим для доставки лише фінальної відповіді. Із `streaming: "off"`: - `blockStreaming: true` надсилає кожен завершений блок як звичайне повідомлення Matrix зі сповіщенням. - `blockStreaming: false` надсилає лише фінальну завершену відповідь як звичайне повідомлення Matrix зі сповіщенням. -### Самохостинг push-правил для тихих фіналізованих попередніх переглядів +### Самостійно розгорнуті push-правила для тихих фіналізованих попередніх переглядів -Якщо ви використовуєте власну інфраструктуру Matrix і хочете, щоб тихі попередні перегляди сповіщали лише тоді, коли блок або -фінальна відповідь готові, установіть `streaming: "quiet"` і додайте push-правило для кожного користувача для фіналізованих редагувань попереднього перегляду. +Якщо ви запускаєте власну інфраструктуру Matrix і хочете, щоб тихі попередні перегляди надсилали сповіщення лише тоді, коли блок або +фінальна відповідь завершені, установіть `streaming: "quiet"` і додайте push-правило для кожного користувача щодо фіналізованих редагувань попереднього перегляду. -Зазвичай це налаштування на рівні користувача-одержувача, а не глобальна зміна конфігурації homeserver: +Зазвичай це налаштування на боці користувача-одержувача, а не глобальна зміна конфігурації homeserver: Коротка схема перед початком: -- користувач-одержувач = людина, яка має отримати сповіщення -- бот-користувач = обліковий запис Matrix OpenClaw, який надсилає відповідь -- для викликів API нижче використовуйте access token користувача-одержувача -- у push-правилі зіставляйте `sender` з повним MXID бот-користувача +- recipient user = людина, яка має отримати сповіщення +- bot user = обліковий запис Matrix OpenClaw, який надсилає відповідь +- для викликів API нижче використовуйте токен доступу користувача-одержувача +- у push-правилі зіставляйте `sender` з повним MXID користувача-бота 1. Налаштуйте OpenClaw на використання тихих попередніх переглядів: @@ -243,13 +248,13 @@ Matrix екранує розділові знаки в ID облікових з } ``` -2. Переконайтеся, що обліковий запис одержувача вже отримує звичайні push-сповіщення Matrix. Правила - тихого попереднього перегляду працюють лише тоді, коли в цього користувача вже налаштовано робочі pusher-и/пристрої. +2. Переконайтеся, що обліковий запис одержувача вже отримує звичайні push-сповіщення Matrix. Правила для тихих попередніх переглядів + працюють лише тоді, коли в цього користувача вже є працездатні pushers/пристрої. -3. Отримайте access token користувача-одержувача. - - Використовуйте token користувача, який отримує повідомлення, а не token бота. - - Зазвичай найпростіше повторно використати token наявної сесії клієнта. - - Якщо вам потрібно створити новий token, ви можете увійти через стандартний Matrix Client-Server API: +3. Отримайте токен доступу користувача-одержувача. + - Використовуйте токен користувача-одержувача, а не токен бота. + - Найпростіше зазвичай повторно використати токен наявної клієнтської сесії. + - Якщо потрібно випустити новий токен, можна увійти через стандартний Matrix Client-Server API: ```bash curl -sS -X POST \ @@ -265,7 +270,7 @@ curl -sS -X POST \ }' ``` -4. Переконайтеся, що обліковий запис одержувача вже має pusher-и: +4. Перевірте, що обліковий запис одержувача вже має pushers: ```bash curl -sS \ @@ -273,7 +278,7 @@ curl -sS \ "https://matrix.example.org/_matrix/client/v3/pushers" ``` -Якщо це повертає відсутність активних pusher-ів/пристроїв, спочатку виправте звичайні сповіщення Matrix, а вже потім додавайте +Якщо це повертає жодних активних pushers/пристроїв, спочатку виправте звичайні сповіщення Matrix, а вже потім додавайте наведене нижче правило OpenClaw. OpenClaw позначає фіналізовані редагування попереднього перегляду лише з текстом так: @@ -314,22 +319,22 @@ curl -sS -X PUT \ }' ``` -Замініть ці значення перед запуском команди: +Замініть ці значення перед виконанням команди: - `https://matrix.example.org`: базовий URL вашого homeserver -- `$USER_ACCESS_TOKEN`: access token користувача, який отримує повідомлення -- `openclaw-finalized-preview-botname`: ID правила, унікальний для цього бота для цього користувача-одержувача -- `@bot:example.org`: MXID вашого бота Matrix OpenClaw, а не MXID користувача-одержувача +- `$USER_ACCESS_TOKEN`: токен доступу користувача-одержувача +- `openclaw-finalized-preview-botname`: `rule ID`, унікальний для цього бота для цього користувача-одержувача +- `@bot:example.org`: MXID вашого Matrix-бота OpenClaw, а не MXID користувача-одержувача -Важливо для сценаріїв із кількома ботами: +Важливо для конфігурацій із кількома ботами: -- Push-правила визначаються за `ruleId`. Повторний запуск `PUT` із тим самим ID правила оновлює саме це правило. -- Якщо один користувач-одержувач має отримувати сповіщення від кількох облікових записів ботів Matrix OpenClaw, створіть окреме правило для кожного бота з унікальним ID правила для кожного збігу `sender`. +- Push-правила прив’язуються до `ruleId`. Повторний `PUT` для того самого rule ID оновлює це одне правило. +- Якщо один користувач-одержувач має отримувати сповіщення від кількох облікових записів Matrix-ботів OpenClaw, створіть по одному правилу на кожного бота з унікальним rule ID для кожного збігу sender. - Простий шаблон — `openclaw-finalized-preview-`, наприклад `openclaw-finalized-preview-ops` або `openclaw-finalized-preview-support`. -Правило оцінюється щодо відправника події: +Правило оцінюється відносно відправника події: -- автентифікуйтеся за допомогою token користувача-одержувача +- автентифікуйтеся токеном користувача-одержувача - зіставте `sender` з MXID бота OpenClaw 6. Переконайтеся, що правило існує: @@ -341,9 +346,9 @@ curl -sS \ ``` 7. Протестуйте потокову відповідь. У тихому режимі в кімнаті має з’явитися тиха чернетка попереднього перегляду, а фінальне - редагування на місці має надіслати сповіщення, щойно блок або хід завершиться. + редагування на місці має надіслати сповіщення, коли блок або хід завершиться. -Якщо згодом вам потрібно видалити правило, видаліть той самий ID правила за допомогою token користувача-одержувача: +Якщо пізніше потрібно видалити правило, видаліть той самий rule ID токеном користувача-одержувача: ```bash curl -sS -X DELETE \ @@ -353,37 +358,37 @@ curl -sS -X DELETE \ Примітки: -- Створюйте правило за допомогою access token користувача-одержувача, а не бота. -- Нові користувацькі правила `override` вставляються перед типовими правилами приглушення, тому додатковий параметр порядку не потрібен. -- Це впливає лише на редагування попереднього перегляду лише з текстом, які OpenClaw може безпечно фіналізувати на місці. Відкати для медіа та застарілих попередніх переглядів, як і раніше, використовують звичайну доставку Matrix. -- Якщо `GET /_matrix/client/v3/pushers` не показує жодного pusher-а, у користувача ще не налаштовано робочу доставку push-повідомлень Matrix для цього облікового запису/пристрою. +- Створюйте правило за допомогою токена доступу користувача-одержувача, а не токена бота. +- Нові визначені користувачем правила `override` вставляються перед типовими правилами придушення, тому додатковий параметр порядку не потрібен. +- Це впливає лише на редагування попереднього перегляду лише з текстом, які OpenClaw може безпечно фіналізувати на місці. Для fallback із медіа та fallback застарілого попереднього перегляду й далі використовується звичайна доставка Matrix. +- Якщо `GET /_matrix/client/v3/pushers` не показує pushers, користувач ще не має працездатної доставки Matrix push для цього облікового запису/пристрою. #### Synapse -Для Synapse зазвичай достатньо наведеного вище налаштування: +Для Synapse наведене вище налаштування зазвичай саме по собі є достатнім: -- Спеціальна зміна `homeserver.yaml` для фіналізованих сповіщень попереднього перегляду OpenClaw не потрібна. -- Якщо ваше розгортання Synapse вже надсилає звичайні push-сповіщення Matrix, token користувача + наведений вище виклик `pushrules` — основний крок налаштування. +- Не потрібна спеціальна зміна `homeserver.yaml` для сповіщень про фіналізований попередній перегляд OpenClaw. +- Якщо ваше розгортання Synapse уже надсилає звичайні push-сповіщення Matrix, основним кроком налаштування є токен користувача + виклик `pushrules`, наведений вище. - Якщо ви запускаєте Synapse за reverse proxy або workers, переконайтеся, що `/_matrix/client/.../pushrules/` коректно доходить до Synapse. -- Якщо ви використовуєте Synapse workers, переконайтеся, що pusher-и працездатні. Доставка push-повідомлень обробляється головним процесом або `synapse.app.pusher` / налаштованими pusher workers. +- Якщо ви використовуєте Synapse workers, переконайтеся, що pushers справні. Доставка push виконується головним процесом або `synapse.app.pusher` / налаштованими pusher workers. #### Tuwunel -Для Tuwunel використовуйте той самий процес налаштування та виклик API `pushrules`, наведені вище: +Для Tuwunel використовуйте той самий потік налаштування та виклик API `pushrules`, наведений вище: -- Спеціальна конфігурація Tuwunel для самого маркера фіналізованого попереднього перегляду не потрібна. -- Якщо звичайні сповіщення Matrix уже працюють для цього користувача, token користувача + наведений вище виклик `pushrules` — основний крок налаштування. -- Якщо сповіщення наче зникають, коли користувач активний на іншому пристрої, перевірте, чи ввімкнено `suppress_push_when_active`. Tuwunel додав цей параметр у Tuwunel 1.4.2 12 вересня 2025 року, і він може навмисно приглушувати push-повідомлення на інші пристрої, поки один пристрій активний. +- Жодна конфігурація, специфічна для Tuwunel, не потрібна для самого маркера фіналізованого попереднього перегляду. +- Якщо звичайні сповіщення Matrix уже працюють для цього користувача, основним кроком налаштування є токен користувача + виклик `pushrules`, наведений вище. +- Якщо сповіщення ніби зникають, коли користувач активний на іншому пристрої, перевірте, чи ввімкнено `suppress_push_when_active`. Tuwunel додав цю опцію в Tuwunel 1.4.2 12 вересня 2025 року, і вона може навмисно приглушувати push на інші пристрої, поки один пристрій активний. -## Шифрування і верифікація +## Шифрування та верифікація -У зашифрованих (E2EE) кімнатах вихідні події зображень використовують `thumbnail_file`, тож попередні перегляди зображень шифруються разом із повним вкладенням. У незашифрованих кімнатах і далі використовується звичайний `thumbnail_url`. Конфігурація не потрібна — плагін автоматично визначає стан E2EE. +У зашифрованих кімнатах (E2EE) вихідні події зображень використовують `thumbnail_file`, тож попередні перегляди зображень шифруються разом із повним вкладенням. У незашифрованих кімнатах і далі використовується звичайний `thumbnail_url`. Жодної конфігурації не потрібно — плагін автоматично визначає стан E2EE. ### Кімнати бот-до-бота За замовчуванням повідомлення Matrix від інших налаштованих облікових записів Matrix OpenClaw ігноруються. -Використовуйте `allowBots`, якщо ви свідомо хочете дозволити міжагентний трафік Matrix: +Використовуйте `allowBots`, якщо ви навмисно хочете міжагентний трафік Matrix: ```json5 { @@ -400,13 +405,13 @@ curl -sS -X DELETE \ } ``` -- `allowBots: true` приймає повідомлення від інших налаштованих облікових записів ботів Matrix у дозволених кімнатах і DM. -- `allowBots: "mentions"` приймає ці повідомлення лише тоді, коли вони явно згадують цього бота в кімнатах. DM, як і раніше, дозволені. -- `groups..allowBots` перевизначає налаштування рівня облікового запису для однієї кімнати. -- OpenClaw все одно ігнорує повідомлення від того самого Matrix user ID, щоб уникнути циклів самовідповіді. -- Matrix тут не має вбудованого прапорця бота; OpenClaw трактує «створене ботом» як «надіслане іншим налаштованим обліковим записом Matrix на цьому gateway OpenClaw». +- `allowBots: true` приймає повідомлення від інших налаштованих облікових записів Matrix-ботів у дозволених кімнатах і DM. +- `allowBots: "mentions"` приймає такі повідомлення лише тоді, коли вони явно згадують цього бота в кімнатах. DM і далі дозволені. +- `groups..allowBots` перевизначає налаштування на рівні облікового запису для однієї кімнати. +- OpenClaw і далі ігнорує повідомлення від того самого Matrix user ID, щоб уникнути циклів самовідповідей. +- Matrix тут не надає нативного прапорця бота; OpenClaw трактує "створено ботом" як "надіслано іншим налаштованим обліковим записом Matrix на цьому gateway OpenClaw". -Використовуйте строгі allowlist для кімнат і вимоги щодо згадувань, коли вмикаєте трафік бот-до-бота в спільних кімнатах. +Використовуйте суворі allowlist кімнат і вимоги щодо згадок, коли вмикаєте трафік бот-до-бота в спільних кімнатах. Увімкнення шифрування: @@ -424,33 +429,33 @@ curl -sS -X DELETE \ } ``` -Перевірка стану верифікації: +Перевірка статусу верифікації: ```bash openclaw matrix verify status ``` -Розширений стан (повна діагностика): +Докладний статус (повна діагностика): ```bash openclaw matrix verify status --verbose ``` -Включити збережений recovery key у машиночитний вивід: +Включити збережений recovery key у вивід, придатний для машинної обробки: ```bash openclaw matrix verify status --include-recovery-key --json ``` -Ініціалізація cross-signing і стану верифікації: +Ініціалізувати cross-signing і стан верифікації: ```bash openclaw matrix verify bootstrap ``` -Підтримка кількох облікових записів: використовуйте `channels.matrix.accounts` з обліковими даними для кожного облікового запису та необов’язковим `name`. Див. [Довідник конфігурації](/uk/gateway/configuration-reference#multi-account-all-channels) для спільного шаблону. +Підтримка кількох облікових записів: використовуйте `channels.matrix.accounts` з обліковими даними для кожного облікового запису та необов’язковим `name`. Див. [Довідник з конфігурації](/uk/gateway/configuration-reference#multi-account-all-channels) щодо спільного шаблону. -Розширена діагностика bootstrap: +Докладна діагностика bootstrap: ```bash openclaw matrix verify bootstrap --verbose @@ -462,56 +467,56 @@ openclaw matrix verify bootstrap --verbose openclaw matrix verify bootstrap --force-reset-cross-signing ``` -Верифікація цього пристрою за допомогою recovery key: +Верифікувати цей пристрій за допомогою recovery key: ```bash openclaw matrix verify device "" ``` -Докладна інформація про верифікацію пристрою: +Докладні відомості про верифікацію пристрою: ```bash openclaw matrix verify device "" --verbose ``` -Перевірка стану резервної копії ключів кімнат: +Перевірка стану резервного копіювання ключів кімнат: ```bash openclaw matrix verify backup status ``` -Розширена діагностика стану резервної копії: +Докладна діагностика стану резервного копіювання: ```bash openclaw matrix verify backup status --verbose ``` -Відновлення ключів кімнат із серверної резервної копії: +Відновити ключі кімнат із серверної резервної копії: ```bash openclaw matrix verify backup restore ``` -Розширена діагностика відновлення: +Докладна діагностика відновлення: ```bash openclaw matrix verify backup restore --verbose ``` -Видалити поточну серверну резервну копію й створити нову базову резервну копію. Якщо збережений -ключ резервної копії не вдається коректно завантажити, це скидання також може відтворити secret storage, щоб -майбутні холодні запуски могли завантажувати новий ключ резервної копії: +Видалити поточну серверну резервну копію та створити нову базову резервну копію. Якщо збережений +backup key не вдається коректно завантажити, це скидання також може повторно створити secret storage, щоб +майбутні холодні запуски могли завантажити новий backup key: ```bash openclaw matrix verify backup reset --yes ``` Усі команди `verify` за замовчуванням лаконічні (включно з тихим внутрішнім логуванням SDK) і показують детальну діагностику лише з `--verbose`. -Для скриптів використовуйте `--json` для повного машиночитного виводу. +Використовуйте `--json` для повного виводу, придатного для машинної обробки, у скриптах. -У конфігураціях із кількома обліковими записами команди Matrix CLI використовують неявний обліковий запис Matrix за замовчуванням, якщо ви не передасте `--account `. -Якщо у вас налаштовано кілька іменованих облікових записів, спочатку задайте `channels.matrix.defaultAccount`, інакше ці неявні операції CLI зупинятимуться й проситимуть вас явно вибрати обліковий запис. -Використовуйте `--account`, коли хочете, щоб операції верифікації або з пристроями явно були спрямовані на іменований обліковий запис: +У конфігураціях із кількома обліковими записами команди Matrix CLI використовують неявний обліковий запис Matrix за замовчуванням, якщо ви не передали `--account `. +Якщо у вас налаштовано кілька іменованих облікових записів, спочатку встановіть `channels.matrix.defaultAccount`, інакше ці неявні операції CLI зупиняться та попросять вас явно вибрати обліковий запис. +Використовуйте `--account`, коли хочете, щоб операції верифікації або з пристроями явно були націлені на конкретний іменований обліковий запис: ```bash openclaw matrix verify status --account assistant @@ -519,11 +524,11 @@ openclaw matrix verify backup restore --account assistant openclaw matrix devices list --account assistant ``` -Коли шифрування вимкнено або недоступне для іменованого облікового запису, попередження Matrix і помилки верифікації вказують на ключ конфігурації цього облікового запису, наприклад `channels.matrix.accounts.assistant.encryption`. +Коли шифрування вимкнене або недоступне для іменованого облікового запису, попередження Matrix і помилки верифікації вказують на ключ конфігурації цього облікового запису, наприклад `channels.matrix.accounts.assistant.encryption`. ### Що означає "verified" -OpenClaw вважає цей пристрій Matrix verified лише тоді, коли його верифіковано вашою власною identity cross-signing. +OpenClaw вважає цей пристрій Matrix верифікованим лише тоді, коли його верифіковано вашою власною identity cross-signing. На практиці `openclaw matrix verify status --verbose` показує три сигнали довіри: - `Locally trusted`: цьому пристрою довіряє лише поточний клієнт @@ -531,31 +536,31 @@ OpenClaw вважає цей пристрій Matrix verified лише тоді, - `Signed by owner`: пристрій підписано вашим власним self-signing key `Verified by owner` стає `yes` лише тоді, коли є верифікація cross-signing або підпис власника. -Локальної довіри самої по собі недостатньо, щоб OpenClaw вважав пристрій повністю верифікованим. +Самої локальної довіри недостатньо, щоб OpenClaw вважав пристрій повністю верифікованим. ### Що робить bootstrap `openclaw matrix verify bootstrap` — це команда відновлення та налаштування для зашифрованих облікових записів Matrix. -Вона послідовно робить усе наведене нижче: +Вона виконує все наведене нижче в такому порядку: - ініціалізує secret storage, повторно використовуючи наявний recovery key, коли це можливо - ініціалізує cross-signing і завантажує відсутні публічні ключі cross-signing - намагається позначити та підписати поточний пристрій через cross-signing - створює нову серверну резервну копію ключів кімнат, якщо її ще не існує -Якщо homeserver вимагає інтерактивної автентифікації для завантаження ключів cross-signing, OpenClaw спочатку намагається завантажити їх без автентифікації, потім із `m.login.dummy`, а потім із `m.login.password`, якщо налаштовано `channels.matrix.password`. +Якщо homeserver вимагає інтерактивної автентифікації для завантаження ключів cross-signing, OpenClaw спершу пробує завантаження без автентифікації, потім з `m.login.dummy`, а потім з `m.login.password`, коли налаштовано `channels.matrix.password`. -Використовуйте `--force-reset-cross-signing` лише тоді, коли ви свідомо хочете відкинути поточну identity cross-signing і створити нову. +Використовуйте `--force-reset-cross-signing` лише тоді, коли ви навмисно хочете відкинути поточну identity cross-signing і створити нову. -Якщо ви свідомо хочете відкинути поточну резервну копію ключів кімнат і почати нову +Якщо ви навмисно хочете відкинути поточну резервну копію ключів кімнат і почати нову базову резервну копію для майбутніх повідомлень, використовуйте `openclaw matrix verify backup reset --yes`. -Робіть це лише тоді, коли приймаєте, що невідновлювана стара зашифрована історія залишиться -недоступною й що OpenClaw може повторно створити secret storage, якщо поточний секрет резервної копії +Робіть це лише тоді, коли ви погоджуєтеся, що невідновна стара зашифрована історія залишиться +недоступною, і що OpenClaw може повторно створити secret storage, якщо поточний секрет резервної копії не вдається безпечно завантажити. ### Нова базова резервна копія -Якщо ви хочете зберегти працездатність майбутніх зашифрованих повідомлень і погоджуєтеся втратити невідновлювану стару історію, виконайте ці команди по черзі: +Якщо ви хочете зберегти працездатність майбутніх зашифрованих повідомлень і погоджуєтеся втратити невідновну стару історію, виконайте ці команди в такому порядку: ```bash openclaw matrix verify backup reset --yes @@ -563,64 +568,64 @@ openclaw matrix verify backup status --verbose openclaw matrix verify status ``` -Додайте `--account ` до кожної команди, якщо хочете явно націлити її на іменований обліковий запис Matrix. +Додавайте `--account ` до кожної команди, якщо хочете явно націлити їх на іменований обліковий запис Matrix. ### Поведінка під час запуску Коли `encryption: true`, Matrix за замовчуванням встановлює `startupVerification` у `"if-unverified"`. -Під час запуску, якщо цей пристрій ще не верифікований, Matrix надішле запит на самоверифікацію в іншому клієнті Matrix, +Під час запуску, якщо цей пристрій усе ще не верифікований, Matrix надішле запит на самоверифікацію в інший Matrix-клієнт, пропустить дублікати запитів, якщо один уже очікує, і застосує локальний cooldown перед повторною спробою після перезапусків. -Невдалі спроби запиту за замовчуванням повторюються раніше, ніж успішне створення запиту. +Повторні спроби після невдалих запитів за замовчуванням відбуваються швидше, ніж після успішного створення запиту. Установіть `startupVerification: "off"`, щоб вимкнути автоматичні запити під час запуску, або налаштуйте `startupVerificationCooldownHours`, -якщо хочете коротше чи довше вікно повторної спроби. +якщо хочете коротше або довше вікно повторної спроби. -Під час запуску також автоматично виконується консервативний прохід bootstrap для криптографії. -Цей прохід спочатку намагається повторно використати поточні secret storage та identity cross-signing і не скидає cross-signing, якщо ви не запускаєте явний потік відновлення bootstrap. +Під час запуску також автоматично виконується консервативний прохід crypto bootstrap. +Цей прохід спершу намагається повторно використати поточні secret storage та identity cross-signing і не скидає cross-signing, якщо ви не запускаєте явний потік bootstrap-відновлення. -Якщо під час запуску виявлено пошкоджений стан bootstrap і налаштовано `channels.matrix.password`, OpenClaw може спробувати суворіший шлях відновлення. -Якщо поточний пристрій уже підписаний власником, OpenClaw зберігає цю identity замість автоматичного скидання. +Якщо під час запуску виявлено зламаний стан bootstrap і налаштовано `channels.matrix.password`, OpenClaw може спробувати суворіший шлях відновлення. +Якщо поточний пристрій уже підписано власником, OpenClaw зберігає цю identity замість автоматичного скидання. Оновлення з попереднього публічного плагіна Matrix: -- OpenClaw автоматично повторно використовує той самий обліковий запис Matrix, access token і identity пристрою, коли це можливо. -- Перш ніж застосовувати будь-які зміни міграції Matrix, OpenClaw створює або повторно використовує recovery snapshot у `~/Backups/openclaw-migrations/`. -- Якщо ви використовуєте кілька облікових записів Matrix, установіть `channels.matrix.defaultAccount` перед оновленням зі старого плоского layout сховища, щоб OpenClaw знав, який обліковий запис має отримати цей спільний застарілий стан. -- Якщо попередній плагін зберігав локально ключ розшифрування резервної копії ключів кімнат Matrix, startup або `openclaw doctor --fix` автоматично імпортують його в новий потік recovery key. -- Якщо access token Matrix змінився після підготовки міграції, startup тепер сканує сусідні корені сховища з hash token для очікуваного застарілого стану відновлення, перш ніж відмовитися від автоматичного відновлення резервної копії. -- Якщо access token Matrix пізніше зміниться для того самого облікового запису, homeserver і користувача, OpenClaw тепер надає перевагу повторному використанню найбільш повного наявного кореня сховища з hash token замість початку з порожнього каталогу стану Matrix. -- Під час наступного запуску gateway резервні ключі кімнат буде автоматично відновлено в нове криптосховище. -- Якщо старий плагін мав лише локальні ключі кімнат, які ніколи не резервувалися, OpenClaw чітко попередить про це. Ці ключі неможливо автоматично експортувати з попереднього rust crypto store, тому частина старої зашифрованої історії може залишатися недоступною, доки її не буде відновлено вручну. +- OpenClaw автоматично повторно використовує той самий обліковий запис Matrix, токен доступу та identity пристрою, коли це можливо. +- Перед виконанням будь-яких міграцій Matrix, що потребують дій, OpenClaw створює або повторно використовує recovery snapshot у `~/Backups/openclaw-migrations/`. +- Якщо ви використовуєте кілька облікових записів Matrix, установіть `channels.matrix.defaultAccount` перед оновленням зі старого flat-store layout, щоб OpenClaw знав, який обліковий запис має отримати цей спільний застарілий стан. +- Якщо попередній плагін зберігав локально ключ розшифрування резервної копії ключів кімнат Matrix, під час запуску або `openclaw doctor --fix` він буде автоматично імпортований у новий потік recovery key. +- Якщо токен доступу Matrix змінився після підготовки міграції, під час запуску тепер виконується сканування сусідніх коренів сховища з хешем токена на наявність незавершеного застарілого стану відновлення, перш ніж відмовитися від автоматичного відновлення резервної копії. +- Якщо токен доступу Matrix зміниться пізніше для того самого облікового запису, homeserver і користувача, OpenClaw тепер віддає перевагу повторному використанню найповнішого наявного кореня сховища з хешем токена замість початку з порожнього каталогу стану Matrix. +- Під час наступного запуску gateway резервні ключі кімнат будуть автоматично відновлені в нове crypto store. +- Якщо старий плагін мав лише локальні ключі кімнат, які ніколи не резервувалися, OpenClaw чітко попередить про це. Ці ключі не можна автоматично експортувати з попереднього rust crypto store, тому частина старої зашифрованої історії може залишатися недоступною, доки її не буде відновлено вручну. - Див. [Міграція Matrix](/uk/install/migrating-matrix) для повного процесу оновлення, обмежень, команд відновлення та поширених повідомлень міграції. -Зашифрований стан runtime організовано в коренях із hash token для кожного облікового запису й користувача в +Зашифрований runtime-стан організовано в коренях з хешем токена для кожного облікового запису й користувача за шляхом `~/.openclaw/matrix/accounts//__//`. Цей каталог містить sync store (`bot-storage.json`), crypto store (`crypto/`), файл recovery key (`recovery-key.json`), snapshot IndexedDB (`crypto-idb-snapshot.json`), -прив’язки гілок (`thread-bindings.json`) і стан startup verification (`startup-verification.json`), -коли ці функції використовуються. -Коли token змінюється, але identity облікового запису залишається тією самою, OpenClaw повторно використовує найкращий наявний -корінь для цього кортежу account/homeserver/user, щоб попередній стан sync, crypto state, прив’язки гілок -і стан startup verification залишалися доступними. +прив’язки тредів (`thread-bindings.json`) і стан стартової верифікації (`startup-verification.json`), +коли ці можливості використовуються. +Коли токен змінюється, але identity облікового запису залишається тією самою, OpenClaw повторно використовує найкращий наявний +корінь для цього кортежу account/homeserver/user, щоб попередній sync-стан, crypto-стан, прив’язки тредів +і стан стартової верифікації залишалися видимими. ### Модель Node crypto store Matrix E2EE у цьому плагіні використовує офіційний шлях Rust crypto з `matrix-js-sdk` у Node. -Цей шлях очікує persistence на основі IndexedDB, якщо ви хочете, щоб криптографічний стан переживав перезапуски. +Цей шлях очікує persistence на основі IndexedDB, якщо ви хочете, щоб crypto-стан зберігався між перезапусками. -Наразі OpenClaw забезпечує це в Node так: +Зараз OpenClaw забезпечує це в Node таким чином: - використовує `fake-indexeddb` як shim API IndexedDB, якого очікує SDK -- відновлює вміст IndexedDB Rust crypto з `crypto-idb-snapshot.json` перед `initRustCrypto` +- відновлює вміст Rust crypto IndexedDB із `crypto-idb-snapshot.json` перед `initRustCrypto` - зберігає оновлений вміст IndexedDB назад у `crypto-idb-snapshot.json` після ініціалізації та під час runtime -- серіалізує відновлення й збереження snapshot для `crypto-idb-snapshot.json` за допомогою advisory file lock, щоб persistence runtime gateway і обслуговування CLI не змагалися за один і той самий файл snapshot +- серіалізує відновлення і збереження snapshot щодо `crypto-idb-snapshot.json` за допомогою advisory file lock, щоб runtime persistence gateway і CLI-обслуговування не конфліктували щодо одного й того самого файла snapshot -Це plumbing сумісності/сховища, а не власна реалізація криптографії. -Файл snapshot є чутливим станом runtime і зберігається з обмеженими правами доступу до файлів. -У межах моделі безпеки OpenClaw хост gateway і локальний каталог стану OpenClaw уже належать до довіреної межі оператора, тому це передусім питання операційної надійності, а не окрема віддалена межа довіри. +Це plumbing сумісності/сховища, а не користувацька crypto-реалізація. +Файл snapshot є чутливим runtime-станом і зберігається з обмеженими правами доступу до файла. +У межах моделі безпеки OpenClaw хост gateway і локальний каталог стану OpenClaw уже входять до довіреної межі оператора, тому це переважно питання операційної надійності, а не окрема віддалена межа довіри. Заплановане покращення: -- додати підтримку SecretRef для постійного матеріалу ключів Matrix, щоб recovery key та пов’язані секрети шифрування сховища можна було отримувати з постачальників секретів OpenClaw, а не лише з локальних файлів +- додати підтримку SecretRef для постійного матеріалу ключів Matrix, щоб recovery keys і пов’язані секрети шифрування сховища можна було отримувати з постачальників секретів OpenClaw, а не лише з локальних файлів ## Керування профілем @@ -633,101 +638,101 @@ openclaw matrix profile set --avatar-url https://cdn.example.org/avatar.png Додайте `--account `, якщо хочете явно націлити команду на іменований обліковий запис Matrix. -Matrix безпосередньо приймає URL аватарів `mxc://`. Коли ви передаєте URL аватара `http://` або `https://`, OpenClaw спочатку завантажує його в Matrix, а потім зберігає визначений URL `mxc://` назад у `channels.matrix.avatarUrl` (або в перевизначення вибраного облікового запису). +Matrix напряму приймає URL аватара `mxc://`. Коли ви передаєте URL аватара `http://` або `https://`, OpenClaw спочатку завантажує його в Matrix, а потім зберігає розв’язаний URL `mxc://` назад у `channels.matrix.avatarUrl` (або у вибране перевизначення облікового запису). ## Автоматичні сповіщення про верифікацію -Тепер Matrix публікує повідомлення про життєвий цикл верифікації безпосередньо в строгій DM-кімнаті верифікації як повідомлення `m.notice`. -Сюди входять: +Тепер Matrix публікує повідомлення про життєвий цикл верифікації безпосередньо в сувору DM-кімнату верифікації як повідомлення `m.notice`. +Це включає: -- повідомлення про запит верифікації +- повідомлення про запит на верифікацію - повідомлення про готовність до верифікації (з явною підказкою "Verify by emoji") - повідомлення про початок і завершення верифікації -- деталі SAS (emoji і десяткові значення), коли вони доступні +- деталі SAS (emoji і decimal), коли вони доступні -Вхідні запити на верифікацію з іншого клієнта Matrix відстежуються й автоматично приймаються OpenClaw. -Для потоків самоверифікації OpenClaw також автоматично запускає потік SAS, коли стає доступною верифікація emoji, і підтверджує свій бік. -Для запитів на верифікацію від іншого користувача/пристрою Matrix OpenClaw автоматично приймає запит, а потім чекає, поки потік SAS продовжиться звичайним чином. -Вам усе одно потрібно порівняти emoji або десятковий SAS у вашому клієнті Matrix і підтвердити "They match", щоб завершити верифікацію. +Вхідні запити на верифікацію з іншого клієнта Matrix відстежуються та автоматично приймаються OpenClaw. +Для потоків самоверифікації OpenClaw також автоматично запускає SAS-потік, коли стає доступною emoji-верифікація, і підтверджує свій бік. +Для запитів на верифікацію від іншого користувача/пристрою Matrix OpenClaw автоматично приймає запит, а потім чекає, поки SAS-потік продовжиться у звичайному режимі. +Вам все одно потрібно порівняти emoji або decimal SAS у вашому Matrix-клієнті та підтвердити "They match" там, щоб завершити верифікацію. -OpenClaw не приймає автоматично самостійно ініційовані дубльовані потоки бездумно. Під час startup він не створює новий запит, якщо запит на самоверифікацію вже очікує. +OpenClaw не приймає сліпо дубльовані потоки, ініційовані самим собою. Під час запуску пропускається створення нового запиту, якщо запит на самоверифікацію вже очікує. -Повідомлення протоколу/системи верифікації не пересилаються до конвеєра чату агента, тому вони не створюють `NO_REPLY`. +Повідомлення протоколу/системи верифікації не пересилаються в конвеєр чату агента, тож вони не створюють `NO_REPLY`. ### Гігієна пристроїв Старі пристрої Matrix, керовані OpenClaw, можуть накопичуватися в обліковому записі й ускладнювати розуміння довіри в зашифрованих кімнатах. -Переглянути їх можна так: +Перелічіть їх за допомогою: ```bash openclaw matrix devices list ``` -Видалити застарілі пристрої Matrix, керовані OpenClaw: +Видаліть застарілі пристрої Matrix, керовані OpenClaw, за допомогою: ```bash openclaw matrix devices prune-stale ``` -### Відновлення Direct Room +### Відновлення direct room -Якщо стан direct-message виходить із синхронізації, OpenClaw може отримати застарілі прив’язки `m.direct`, які вказують на старі індивідуальні кімнати замість активного DM. Перегляньте поточне зіставлення для співрозмовника так: +Якщо стан direct-message виходить із синхронізації, OpenClaw може отримати застарілі прив’язки `m.direct`, які вказують на старі сольні кімнати замість актуального DM. Перегляньте поточну прив’язку для peer за допомогою: ```bash openclaw matrix direct inspect --user-id @alice:example.org ``` -Відновіть його так: +Відновіть її за допомогою: ```bash openclaw matrix direct repair --user-id @alice:example.org ``` -Відновлення зберігає специфічну для Matrix логіку всередині плагіна: +Відновлення зберігає Matrix-специфічну логіку всередині плагіна: -- воно надає перевагу строгому DM 1:1, який уже зіставлений у `m.direct` -- інакше повертається до будь-якого поточного приєднаного строгого DM 1:1 з цим користувачем -- якщо здорового DM не існує, воно створює нову direct room і переписує `m.direct`, щоб указувати на неї +- воно надає перевагу строгому DM 1:1, який уже прив’язано в `m.direct` +- інакше повертається до будь-якого поточного strict DM 1:1 з цим користувачем +- якщо справного DM не існує, створює нову direct room і переписує `m.direct`, щоб вона вказувала на неї -Процес відновлення не видаляє старі кімнати автоматично. Він лише вибирає здоровий DM та оновлює зіставлення, щоб нові надсилання Matrix, повідомлення верифікації та інші direct-message потоки знову націлювалися на правильну кімнату. +Потік відновлення не видаляє старі кімнати автоматично. Він лише вибирає справний DM і оновлює прив’язку, щоб нові Matrix-відправлення, повідомлення верифікації та інші потоки direct-message знову націлювалися на правильну кімнату. -## Гілки +## Треди -Matrix підтримує нативні гілки Matrix як для автоматичних відповідей, так і для надсилань через message-tool. +Matrix підтримує нативні треди Matrix як для автоматичних відповідей, так і для відправлень через message-tool. -- `dm.sessionScope: "per-user"` (за замовчуванням) зберігає маршрутизацію Matrix DM з областю відправника, тож кілька DM-кімнат можуть спільно використовувати один сеанс, якщо вони визначаються як один і той самий співрозмовник. -- `dm.sessionScope: "per-room"` ізолює кожну Matrix DM-кімнату у власний ключ сеансу, водночас зберігаючи звичайну автентифікацію DM і перевірки allowlist. -- Явні прив’язки розмов Matrix усе одно мають пріоритет над `dm.sessionScope`, тож прив’язані кімнати й гілки зберігають свій вибраний цільовий сеанс. -- `threadReplies: "off"` зберігає відповіді на верхньому рівні та залишає вхідні повідомлення в гілках на сеансі батьківського повідомлення. -- `threadReplies: "inbound"` відповідає всередині гілки лише тоді, коли вхідне повідомлення вже було в цій гілці. -- `threadReplies: "always"` зберігає відповіді в кімнаті в гілці, коренем якої є повідомлення-тригер, і маршрутизує цю розмову через відповідний сеанс із областю цієї гілки, починаючи з першого повідомлення-тригера. -- `dm.threadReplies` перевизначає верхньорівневе налаштування лише для DM. Наприклад, ви можете ізолювати гілки в кімнатах і водночас залишити DM пласкими. -- Вхідні повідомлення в гілках включають кореневе повідомлення гілки як додатковий контекст агента. -- Надсилання через message-tool тепер автоматично успадковують поточну гілку Matrix, коли ціллю є та сама кімната або той самий цільовий користувач DM, якщо не задано явний `threadId`. -- Повторне використання DM user target для того самого сеансу спрацьовує лише тоді, коли метадані поточного сеансу підтверджують того самого співрозмовника DM в тому самому обліковому записі Matrix; інакше OpenClaw повертається до звичайної маршрутизації з областю користувача. -- Коли OpenClaw бачить, що Matrix DM-кімната конфліктує з іншою DM-кімнатою на тому самому спільному сеансі Matrix DM, він публікує одноразове `m.notice` у цій кімнаті з escape hatch `/focus`, коли ввімкнено прив’язки гілок, і з підказкою `dm.sessionScope`. -- Прив’язки гілок runtime підтримуються для Matrix. `/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age` і `/acp spawn`, прив’язаний до гілки, тепер працюють у кімнатах і DM Matrix. -- Верхньорівневий `/focus` у кімнаті/DM Matrix створює нову гілку Matrix і прив’язує її до цільового сеансу, коли `threadBindings.spawnSubagentSessions=true`. -- Виконання `/focus` або `/acp spawn --thread here` всередині наявної гілки Matrix натомість прив’язує саме цю поточну гілку. +- `dm.sessionScope: "per-user"` (за замовчуванням) зберігає sender-scoped маршрутизацію Matrix DM, тому кілька DM-кімнат можуть ділити одну сесію, якщо вони розв’язуються до того самого peer. +- `dm.sessionScope: "per-room"` ізолює кожну Matrix DM-кімнату у власний ключ сесії, зберігаючи звичайні перевірки автентифікації DM та allowlist. +- Явні Matrix conversation bindings і далі мають пріоритет над `dm.sessionScope`, тому прив’язані кімнати й треди зберігають обраний цільовий сеанс. +- `threadReplies: "off"` залишає відповіді на верхньому рівні й прив’язує вхідні повідомлення з тредів до сеансу батьківського повідомлення. +- `threadReplies: "inbound"` відповідає всередині треду лише тоді, коли вхідне повідомлення вже було в цьому треді. +- `threadReplies: "always"` зберігає відповіді кімнати в треді, коренем якого є повідомлення-тригер, і спрямовує цю розмову через відповідний сеанс з областю треду від першого повідомлення-тригера. +- `dm.threadReplies` перевизначає налаштування верхнього рівня лише для DM. Наприклад, ви можете тримати треди кімнат ізольованими, залишаючи DM плоскими. +- Вхідні повідомлення з тредів включають кореневе повідомлення треду як додатковий контекст агента. +- Відправлення через message-tool тепер автоматично успадковують поточний Matrix thread, коли ціль — та сама кімната або той самий користувач DM, якщо не передано явний `threadId`. +- Повторне використання тієї самої DM user-target session спрацьовує лише тоді, коли поточні метадані сеансу підтверджують того самого DM peer в тому самому обліковому записі Matrix; інакше OpenClaw повертається до звичайної маршрутизації з областю користувача. +- Коли OpenClaw бачить, що Matrix DM-кімната конфліктує з іншою DM-кімнатою в межах того самого спільного Matrix DM-сеансу, він публікує в цій кімнаті одноразове `m.notice` з escape hatch `/focus`, коли ввімкнено прив’язки тредів і підказку `dm.sessionScope`. +- Runtime-прив’язки тредів підтримуються для Matrix. `/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age` і прив’язаний до треду `/acp spawn` тепер працюють у Matrix-кімнатах і DM. +- Верхньорівневий Matrix room/DM `/focus` створює новий Matrix thread і прив’язує його до цільового сеансу, коли `threadBindings.spawnSubagentSessions=true`. +- Запуск `/focus` або `/acp spawn --thread here` всередині наявного Matrix thread натомість прив’язує цей поточний thread. ## Прив’язки розмов ACP -Кімнати Matrix, DM і наявні гілки Matrix можна перетворити на довговічні робочі простори ACP без зміни поверхні чату. +Matrix-кімнати, DM і наявні Matrix threads можна перетворити на довговічні робочі простори ACP без зміни поверхні чату. -Швидкий операторський сценарій: +Швидкий потік для оператора: -- Виконайте `/acp spawn codex --bind here` у Matrix DM, кімнаті або наявній гілці, яку ви хочете й далі використовувати. -- У верхньорівневому Matrix DM або кімнаті поточний DM/кімната залишаються поверхнею чату, а майбутні повідомлення маршрутизуються до створеного сеансу ACP. -- Усередині наявної гілки Matrix `--bind here` прив’язує цю поточну гілку на місці. -- `/new` і `/reset` скидають той самий прив’язаний сеанс ACP на місці. -- `/acp close` закриває сеанс ACP і видаляє прив’язку. +- Запустіть `/acp spawn codex --bind here` у Matrix DM, кімнаті або наявному thread, який ви хочете й далі використовувати. +- У верхньорівневому Matrix DM або кімнаті поточний DM/кімната залишається поверхнею чату, а майбутні повідомлення маршрутизуються до створеного ACP-сеансу. +- Усередині наявного Matrix thread `--bind here` прив’язує цей поточний thread на місці. +- `/new` і `/reset` скидають той самий прив’язаний ACP-сеанс на місці. +- `/acp close` закриває ACP-сеанс і видаляє прив’язку. Примітки: -- `--bind here` не створює дочірню гілку Matrix. -- `threadBindings.spawnAcpSessions` потрібен лише для `/acp spawn --thread auto|here`, коли OpenClaw потрібно створити або прив’язати дочірню гілку Matrix. +- `--bind here` не створює дочірній Matrix thread. +- `threadBindings.spawnAcpSessions` потрібний лише для `/acp spawn --thread auto|here`, де OpenClaw має створити або прив’язати дочірній Matrix thread. -### Конфігурація прив’язки гілок +### Конфігурація прив’язки тредів Matrix успадковує глобальні значення за замовчуванням із `session.threadBindings`, а також підтримує перевизначення для каналу: @@ -737,67 +742,67 @@ Matrix успадковує глобальні значення за замов - `threadBindings.spawnSubagentSessions` - `threadBindings.spawnAcpSessions` -Прапорці створення сеансів, прив’язаних до гілок Matrix, вмикаються лише за бажанням: +Прапорці створення з прив’язкою до треду для Matrix є опціональними: -- Установіть `threadBindings.spawnSubagentSessions: true`, щоб дозволити верхньорівневому `/focus` створювати й прив’язувати нові гілки Matrix. -- Установіть `threadBindings.spawnAcpSessions: true`, щоб дозволити `/acp spawn --thread auto|here` прив’язувати сеанси ACP до гілок Matrix. +- Установіть `threadBindings.spawnSubagentSessions: true`, щоб дозволити верхньорівневому `/focus` створювати й прив’язувати нові Matrix threads. +- Установіть `threadBindings.spawnAcpSessions: true`, щоб дозволити `/acp spawn --thread auto|here` прив’язувати ACP-сеанси до Matrix threads. ## Реакції -Matrix підтримує вихідні дії з реакціями, вхідні сповіщення про реакції та вхідні ack reactions. +Matrix підтримує вихідні дії реакцій, вхідні сповіщення про реакції та вхідні реакції-підтвердження. -- Інструменти вихідних реакцій контролюються через `channels["matrix"].actions.reactions`. -- `react` додає реакцію до конкретної події Matrix. -- `reactions` показує поточне зведення реакцій для конкретної події Matrix. +- Інструментарій вихідних реакцій керується `channels["matrix"].actions.reactions`. +- `react` додає реакцію до певної події Matrix. +- `reactions` перелічує поточне зведення реакцій для певної події Matrix. - `emoji=""` видаляє власні реакції облікового запису бота на цю подію. -- `remove: true` видаляє лише вказану реакцію emoji з облікового запису бота. +- `remove: true` видаляє лише вказану emoji-реакцію з облікового запису бота. -Область ack reactions визначається у стандартному порядку розв’язання OpenClaw: +Область реакцій-підтверджень розв’язується в стандартному порядку OpenClaw: - `channels["matrix"].accounts..ackReaction` - `channels["matrix"].ackReaction` - `messages.ackReaction` -- запасний emoji з identity агента +- резервне emoji ідентичності агента -Область ack reaction визначається в такому порядку: +Область дії реакції-підтвердження розв’язується в такому порядку: - `channels["matrix"].accounts..ackReactionScope` - `channels["matrix"].ackReactionScope` - `messages.ackReactionScope` -Режим сповіщень про реакції визначається в такому порядку: +Режим сповіщень про реакції розв’язується в такому порядку: - `channels["matrix"].accounts..reactionNotifications` - `channels["matrix"].reactionNotifications` -- значення за замовчуванням: `own` +- за замовчуванням: `own` Поточна поведінка: -- `reactionNotifications: "own"` пересилає додані події `m.reaction`, коли вони націлені на повідомлення Matrix, створені ботом. +- `reactionNotifications: "own"` пересилає додані події `m.reaction`, коли вони націлені на створені ботом повідомлення Matrix. - `reactionNotifications: "off"` вимикає системні події реакцій. -- Видалення реакцій усе ще не синтезуються в системні події, тому що Matrix представляє їх як redaction, а не як окремі видалення `m.reaction`. +- Видалення реакцій усе ще не синтезується в системні події, оскільки Matrix показує їх як redactions, а не як окремі видалення `m.reaction`. ## Контекст історії -- `channels.matrix.historyLimit` керує тим, скільки недавніх повідомлень кімнати включаються як `InboundHistory`, коли повідомлення Matrix у кімнаті запускає агента. -- Воно повертається до `messages.groupChat.historyLimit`. Установіть `0`, щоб вимкнути. -- Історія кімнати Matrix обмежується кімнатою. DM, як і раніше, використовують звичайну історію сеансу. -- Історія кімнати Matrix стосується лише pending: OpenClaw буферизує повідомлення кімнати, які ще не спричинили відповідь, а потім робить snapshot цього вікна, коли надходить згадка або інший тригер. +- `channels.matrix.historyLimit` керує тим, скільки нещодавніх повідомлень кімнати включається як `InboundHistory`, коли повідомлення кімнати Matrix запускає агента. +- Використовується fallback до `messages.groupChat.historyLimit`. Установіть `0`, щоб вимкнути. +- Історія кімнати Matrix є лише кімнатною. DM і далі використовують звичайну історію сеансу. +- Історія кімнати Matrix є лише для pending: OpenClaw буферизує повідомлення кімнати, які ще не спричинили відповідь, а потім робить snapshot цього вікна, коли надходить згадка або інший тригер. - Поточне повідомлення-тригер не включається до `InboundHistory`; воно залишається в основному вхідному тілі для цього ходу. -- Повторні спроби для тієї самої події Matrix повторно використовують вихідний snapshot історії замість зміщення вперед до новіших повідомлень кімнати. +- Повторні спроби для тієї самої події Matrix повторно використовують вихідний snapshot історії замість зсуву вперед до новіших повідомлень кімнати. ## Видимість контексту -Matrix підтримує спільний елемент керування `contextVisibility` для додаткового контексту кімнати, як-от отриманий текст відповіді, корені гілок і pending history. +Matrix підтримує спільний елемент керування `contextVisibility` для додаткового контексту кімнати, такого як отриманий текст відповіді, корені тредів і очікувана історія. -- `contextVisibility: "all"` — значення за замовчуванням. Додатковий контекст зберігається як отримано. -- `contextVisibility: "allowlist"` фільтрує додатковий контекст до відправників, дозволених активними перевірками allowlist для кімнати/користувача. -- `contextVisibility: "allowlist_quote"` працює як `allowlist`, але все ж зберігає одну явну процитовану відповідь. +- `contextVisibility: "all"` — значення за замовчуванням. Додатковий контекст зберігається без змін. +- `contextVisibility: "allowlist"` фільтрує додатковий контекст до відправників, дозволених активними перевірками allowlist кімнати/користувача. +- `contextVisibility: "allowlist_quote"` працює як `allowlist`, але все одно зберігає одну явну цитовану відповідь. Це налаштування впливає на видимість додаткового контексту, а не на те, чи може саме вхідне повідомлення запускати відповідь. -Авторизація тригера, як і раніше, походить із налаштувань `groupPolicy`, `groups`, `groupAllowFrom` і політик DM. +Авторизація тригера й далі визначається `groupPolicy`, `groups`, `groupAllowFrom` і налаштуваннями політики DM. -## Приклад політики для DM і кімнат +## Приклад політики DM і кімнат ```json5 { @@ -820,7 +825,7 @@ Matrix підтримує спільний елемент керування `co } ``` -Див. [Групи](/uk/channels/groups) щодо поведінки mention-gating і allowlist. +Див. [Групи](/uk/channels/groups) щодо поведінки mention-gating та allowlist. Приклад pairing для Matrix DM: @@ -829,45 +834,45 @@ openclaw pairing list matrix openclaw pairing approve matrix ``` -Якщо неавторизований користувач Matrix продовжує писати вам до схвалення, OpenClaw повторно використовує той самий код pairing, що очікує, і може знову надіслати відповідь-нагадування після короткого cooldown замість створення нового коду. +Якщо непідтверджений користувач Matrix продовжує надсилати вам повідомлення до схвалення, OpenClaw повторно використає той самий pending pairing code і може знову надіслати відповідь-нагадування після короткого cooldown замість створення нового коду. -Див. [Pairing](/uk/channels/pairing) щодо спільного процесу pairing для DM і структури сховища. +Див. [Pairing](/uk/channels/pairing) щодо спільного потоку DM pairing і структури зберігання. ## Погодження exec Matrix може виступати клієнтом погодження exec для облікового запису Matrix. - `channels.matrix.execApprovals.enabled` -- `channels.matrix.execApprovals.approvers` (необов’язково; повертається до `channels.matrix.dm.allowFrom`) +- `channels.matrix.execApprovals.approvers` (необов’язково; використовується fallback до `channels.matrix.dm.allowFrom`) - `channels.matrix.execApprovals.target` (`dm` | `channel` | `both`, за замовчуванням: `dm`) - `channels.matrix.execApprovals.agentFilter` - `channels.matrix.execApprovals.sessionFilter` -Погоджувачі мають бути Matrix user ID, наприклад `@owner:example.org`. Matrix автоматично вмикає нативні погодження exec, коли `enabled` не задано або дорівнює `"auto"` і можна визначити принаймні одного погоджувача — або з `execApprovals.approvers`, або з `channels.matrix.dm.allowFrom`. Установіть `enabled: false`, щоб явно вимкнути Matrix як нативний клієнт погодження. Інакше запити на погодження повертаються до інших налаштованих маршрутів погодження або до fallback policy погодження exec. +Ті, хто погоджує, мають бути Matrix user ID на кшталт `@owner:example.org`. Matrix автоматично вмикає нативні погодження exec, коли `enabled` не задано або дорівнює `"auto"` і можна розв’язати принаймні одного approver, або з `execApprovals.approvers`, або з `channels.matrix.dm.allowFrom`. Установіть `enabled: false`, щоб явно вимкнути Matrix як нативний клієнт погодження. Інакше запити на погодження переходять на інші налаштовані маршрути погодження або на fallback policy погодження exec. -Нативна маршрутизація Matrix сьогодні стосується лише exec: +Нативна маршрутизація Matrix наразі стосується лише exec: -- `channels.matrix.execApprovals.*` керує нативною маршрутизацією DM/каналу лише для погоджень exec. -- Погодження плагінів і далі використовують спільну `/approve` у тому ж чаті плюс будь-яке налаштоване пересилання `approvals.plugin`. -- Matrix все ще може повторно використовувати `channels.matrix.dm.allowFrom` для авторизації погоджень плагінів, коли може безпечно визначити погоджувачів, але не надає окремого нативного шляху fanout DM/каналу для погодження плагінів. +- `channels.matrix.execApprovals.*` керує нативною маршрутизацією DM/channel для погоджень exec. +- Погодження плагінів і далі використовують спільний `/approve` у тому самому чаті плюс будь-яке налаштоване пересилання `approvals.plugin`. +- Matrix і далі може повторно використовувати `channels.matrix.dm.allowFrom` для авторизації погодження плагінів, коли може безпечно визначити approvers, але не надає окремого нативного fanout-шляху DM/channel для погодження плагінів. Правила доставки: -- `target: "dm"` надсилає запити на погодження в DM погоджувачів -- `target: "channel"` надсилає запит назад у вихідну кімнату або DM Matrix -- `target: "both"` надсилає як у DM погоджувачів, так і у вихідну кімнату або DM Matrix +- `target: "dm"` надсилає запити на погодження до DM тих, хто погоджує +- `target: "channel"` надсилає запит назад до вихідної Matrix-кімнати або DM +- `target: "both"` надсилає до DM тих, хто погоджує, і до вихідної Matrix-кімнати або DM -Підказки погодження Matrix додають скорочення реакцій у головне повідомлення погодження: +Запити на погодження Matrix додають ярлики реакцій до основного повідомлення погодження: - `✅` = дозволити один раз - `❌` = відхилити -- `♾️` = дозволити завжди, коли таке рішення дозволене ефективною політикою exec +- `♾️` = дозволити завжди, коли таке рішення дозволене ефективною policy exec -Погоджувачі можуть реагувати на це повідомлення або використовувати запасні slash-команди: `/approve allow-once`, `/approve allow-always` або `/approve deny`. +Ті, хто погоджує, можуть реагувати на це повідомлення або використовувати резервні slash-команди: `/approve allow-once`, `/approve allow-always` або `/approve deny`. -Лише визначені погоджувачі можуть дозволяти або відхиляти. Доставка в канал включає текст команди, тому вмикайте `channel` або `both` лише в довірених кімнатах. +Погоджувати або відхиляти можуть лише розв’язані approvers. Доставка в канал містить текст команди, тож вмикайте `channel` або `both` лише в довірених кімнатах. -Підказки погодження Matrix повторно використовують спільний core approval planner. Нативна поверхня, специфічна для Matrix, є лише транспортним шаром для погоджень exec: маршрутизація кімнати/DM і поведінка надсилання/оновлення/видалення повідомлень. +Запити на погодження Matrix повторно використовують спільний core approval planner. Нативна поверхня, специфічна для Matrix, — це лише транспорт для погоджень exec: маршрутизація room/DM і поведінка надсилання/оновлення/видалення повідомлень. Перевизначення для облікового запису: @@ -875,7 +880,7 @@ Matrix може виступати клієнтом погодження exec д Пов’язана документація: [Погодження exec](/uk/tools/exec-approvals) -## Приклад із кількома обліковими записами +## Приклад кількох облікових записів ```json5 { @@ -905,21 +910,21 @@ Matrix може виступати клієнтом погодження exec д } ``` -Верхньорівневі значення `channels.matrix` працюють як значення за замовчуванням для іменованих облікових записів, якщо обліковий запис не перевизначає їх. -Ви можете обмежити успадкований запис кімнати одним обліковим записом Matrix за допомогою `groups..account` (або застарілого `rooms..account`). -Записи без `account` залишаються спільними для всіх облікових записів Matrix, а записи з `account: "default"` і далі працюють, коли обліковий запис за замовчуванням налаштований безпосередньо на верхньому рівні `channels.matrix.*`. -Часткові спільні значення автентифікації за замовчуванням самі по собі не створюють окремий неявний обліковий запис за замовчуванням. OpenClaw синтезує верхньорівневий обліковий запис `default` лише тоді, коли цей обліковий запис за замовчуванням має актуальну автентифікацію (`homeserver` плюс `accessToken` або `homeserver` плюс `userId` і `password`); іменовані облікові записи все одно можуть залишатися доступними з `homeserver` плюс `userId`, коли кешовані облікові дані пізніше задовольняють вимоги автентифікації. -Якщо Matrix уже має рівно один іменований обліковий запис або `defaultAccount` вказує на наявний ключ іменованого облікового запису, під час відновлення/перенесення з конфігурації одного облікового запису на кілька облікових записів цей обліковий запис зберігається замість створення нового запису `accounts.default`. До цього перенесеного облікового запису переміщуються лише ключі Matrix auth/bootstrap; спільні ключі політики доставки залишаються на верхньому рівні. -Установіть `defaultAccount`, якщо хочете, щоб OpenClaw надавав перевагу одному іменованому обліковому запису Matrix для неявної маршрутизації, probe і операцій CLI. -Якщо у вас налаштовано кілька іменованих облікових записів, установіть `defaultAccount` або передавайте `--account ` для команд CLI, які покладаються на неявний вибір облікового запису. -Передавайте `--account ` до `openclaw matrix verify ...` і `openclaw matrix devices ...`, якщо хочете перевизначити цей неявний вибір для однієї команди. +Значення верхнього рівня `channels.matrix` діють як значення за замовчуванням для іменованих облікових записів, якщо обліковий запис не перевизначає їх. +Ви можете обмежити успадкований запис кімнати одним обліковим записом Matrix через `groups..account` (або застарілий `rooms..account`). +Записи без `account` залишаються спільними для всіх облікових записів Matrix, а записи з `account: "default"` і далі працюють, коли обліковий запис за замовчуванням налаштовано безпосередньо на верхньому рівні `channels.matrix.*`. +Часткові спільні значення автентифікації за замовчуванням самі по собі не створюють окремий неявний обліковий запис за замовчуванням. OpenClaw синтезує верхньорівневий обліковий запис `default` лише тоді, коли цей обліковий запис за замовчуванням має актуальну автентифікацію (`homeserver` плюс `accessToken`, або `homeserver` плюс `userId` і `password`); іменовані облікові записи все ще можуть залишатися доступними для виявлення через `homeserver` плюс `userId`, коли кешовані облікові дані задовольнять автентифікацію пізніше. +Якщо Matrix уже має рівно один іменований обліковий запис або `defaultAccount` вказує на наявний ключ іменованого облікового запису, відновлення/підвищення з однооблікового до багатооблікового налаштування зберігає цей обліковий запис замість створення нового запису `accounts.default`. У цей підвищений обліковий запис переміщуються лише ключі автентифікації/bootstrap Matrix; спільні ключі policy доставки залишаються на верхньому рівні. +Установіть `defaultAccount`, якщо хочете, щоб OpenClaw віддавав перевагу одному іменованому обліковому запису Matrix для неявної маршрутизації, probing і операцій CLI. +Якщо у вас налаштовано кілька іменованих облікових записів, установіть `defaultAccount` або передавайте `--account ` для команд CLI, що покладаються на неявний вибір облікового запису. +Передавайте `--account ` до `openclaw matrix verify ...` і `openclaw matrix devices ...`, коли хочете перевизначити цей неявний вибір для однієї команди. -## Приватні/LAN homeserver-и +## Приватні/LAN homeserver -За замовчуванням OpenClaw блокує приватні/внутрішні homeserver-и Matrix для захисту від SSRF, якщо ви -явно не ввімкнете це для кожного облікового запису. +За замовчуванням OpenClaw блокує приватні/внутрішні Matrix homeserver для захисту від SSRF, якщо ви +явно не надасте дозвіл для кожного облікового запису. -Якщо ваш homeserver працює на localhost, LAN/Tailscale IP або внутрішньому hostname, увімкніть +Якщо ваш homeserver працює на localhost, LAN/Tailscale IP або внутрішньому імені хоста, увімкніть `allowPrivateNetwork` для цього облікового запису Matrix: ```json5 @@ -944,12 +949,12 @@ openclaw matrix account add \ --access-token syt_ops_xxx ``` -Це явне ввімкнення дозволяє лише довірені приватні/внутрішні цілі. Публічні homeserver-и без шифрування, такі як -`http://matrix.example.org:8008`, і далі блокуються. За можливості віддавайте перевагу `https://`. +Ця явна згода дозволяє лише довірені приватні/внутрішні цілі. Публічні homeserver без шифрування, наприклад +`http://matrix.example.org:8008`, і далі блокуються. Коли це можливо, надавайте перевагу `https://`. ## Проксіювання трафіку Matrix -Якщо для вашого розгортання Matrix потрібен явний вихідний HTTP(S) proxy, задайте `channels.matrix.proxy`: +Якщо вашому розгортанню Matrix потрібен явний вихідний HTTP(S)-proxy, задайте `channels.matrix.proxy`: ```json5 { @@ -963,86 +968,87 @@ openclaw matrix account add \ } ``` -Іменовані облікові записи можуть перевизначати верхньорівневе значення за замовчуванням через `channels.matrix.accounts..proxy`. +Іменовані облікові записи можуть перевизначити значення верхнього рівня через `channels.matrix.accounts..proxy`. OpenClaw використовує те саме налаштування proxy як для runtime-трафіку Matrix, так і для probes стану облікового запису. -## Визначення цілей +## Розв’язання цілей -Matrix приймає такі форми цілей скрізь, де OpenClaw просить вказати цільову кімнату або користувача: +Matrix приймає такі форми цілей усюди, де OpenClaw просить вас указати ціль кімнати або користувача: - Користувачі: `@user:server`, `user:@user:server` або `matrix:user:@user:server` - Кімнати: `!room:server`, `room:!room:server` або `matrix:room:!room:server` - Псевдоніми: `#alias:server`, `channel:#alias:server` або `matrix:channel:#alias:server` -Пошук у живому каталозі використовує обліковий запис Matrix, під яким виконано вхід: +Живий пошук у каталозі використовує обліковий запис Matrix, у який виконано вхід: - Пошук користувачів звертається до каталогу користувачів Matrix на цьому homeserver. -- Пошук кімнат безпосередньо приймає явні ID кімнат і псевдоніми, а потім повертається до пошуку за назвами приєднаних кімнат для цього облікового запису. -- Пошук за назвою приєднаної кімнати працює за найкращим зусиллям. Якщо назву кімнати не вдається визначити як ID або псевдонім, вона ігнорується під час визначення allowlist у runtime. +- Пошук кімнат напряму приймає явні ID кімнат і псевдоніми, а потім використовує fallback до пошуку назв приєднаних кімнат для цього облікового запису. +- Пошук назв приєднаних кімнат є best-effort. Якщо назву кімнати не вдається розв’язати до ID або псевдоніма, вона ігнорується під час runtime-розв’язання allowlist. -## Довідник конфігурації +## Довідник з конфігурації - `enabled`: увімкнути або вимкнути канал. - `name`: необов’язкова мітка для облікового запису. - `defaultAccount`: бажаний ID облікового запису, коли налаштовано кілька облікових записів Matrix. - `homeserver`: URL homeserver, наприклад `https://matrix.example.org`. -- `allowPrivateNetwork`: дозволити цьому обліковому запису Matrix підключатися до приватних/внутрішніх homeserver-ів. Увімкніть це, якщо homeserver визначається як `localhost`, LAN/Tailscale IP або внутрішній хост, наприклад `matrix-synapse`. -- `proxy`: необов’язковий URL HTTP(S) proxy для трафіку Matrix. Іменовані облікові записи можуть перевизначати верхньорівневе значення за замовчуванням власним `proxy`. +- `allowPrivateNetwork`: дозволити цьому обліковому запису Matrix підключатися до приватних/внутрішніх homeserver. Увімкніть це, коли homeserver розв’язується в `localhost`, LAN/Tailscale IP або внутрішній хост, наприклад `matrix-synapse`. +- `proxy`: необов’язковий URL HTTP(S)-proxy для трафіку Matrix. Іменовані облікові записи можуть перевизначати значення верхнього рівня власним `proxy`. - `userId`: повний Matrix user ID, наприклад `@bot:example.org`. -- `accessToken`: access token для автентифікації на основі token. Для `channels.matrix.accessToken` і `channels.matrix.accounts..accessToken` підтримуються значення у відкритому вигляді та значення SecretRef у постачальниках env/file/exec. Див. [Керування секретами](/uk/gateway/secrets). -- `password`: пароль для входу на основі пароля. Підтримуються значення у відкритому вигляді та значення SecretRef. +- `accessToken`: токен доступу для автентифікації на основі токена. Для `channels.matrix.accessToken` і `channels.matrix.accounts..accessToken` підтримуються як значення у відкритому тексті, так і значення SecretRef у провайдерах env/file/exec. Див. [Керування секретами](/uk/gateway/secrets). +- `password`: пароль для входу за паролем. Підтримуються значення у відкритому тексті та значення SecretRef. - `deviceId`: явний Matrix device ID. - `deviceName`: відображувана назва пристрою для входу за паролем. -- `avatarUrl`: збережений URL власного аватара для синхронізації профілю та оновлень `set-profile`. -- `initialSyncLimit`: ліміт подій startup sync. +- `avatarUrl`: збережений URL self-avatar для синхронізації профілю та оновлень `set-profile`. +- `initialSyncLimit`: ліміт подій стартової синхронізації. - `encryption`: увімкнути E2EE. -- `allowlistOnly`: примусово використовувати лише allowlist для DM і кімнат. -- `allowBots`: дозволяти повідомлення від інших налаштованих облікових записів Matrix OpenClaw (`true` або `"mentions"`). +- `allowlistOnly`: примусово використовувати поведінку лише за allowlist для DM і кімнат. +- `allowBots`: дозволити повідомлення від інших налаштованих облікових записів Matrix OpenClaw (`true` або `"mentions"`). - `groupPolicy`: `open`, `allowlist` або `disabled`. - `contextVisibility`: режим видимості додаткового контексту кімнати (`all`, `allowlist`, `allowlist_quote`). - `groupAllowFrom`: allowlist user ID для трафіку кімнат. -- Записи `groupAllowFrom` мають бути повними Matrix user ID. Невизначені імена ігноруються в runtime. -- `historyLimit`: максимальна кількість повідомлень кімнати, які включаються як контекст історії групи. Повертається до `messages.groupChat.historyLimit`. Установіть `0`, щоб вимкнути. +- Записи `groupAllowFrom` мають бути повними Matrix user ID. Нерозв’язані імена ігноруються під час runtime. +- `historyLimit`: максимальна кількість повідомлень кімнати для включення до контексту історії групи. Використовується fallback до `messages.groupChat.historyLimit`. Установіть `0`, щоб вимкнути. - `replyToMode`: `off`, `first` або `all`. - `markdown`: необов’язкова конфігурація рендерингу Markdown для вихідного тексту Matrix. -- `streaming`: `off` (за замовчуванням), `partial`, `quiet`, `true` або `false`. `partial` і `true` вмикають оновлення чернетки за схемою preview-first за допомогою звичайних текстових повідомлень Matrix. `quiet` використовує попередні повідомлення без сповіщень для самохостингових конфігурацій push-правил. -- `blockStreaming`: `true` вмикає окремі повідомлення прогресу для завершених блоків асистента, поки активне потокове надсилання чернетки попереднього перегляду. +- `streaming`: `off` (за замовчуванням), `partial`, `quiet`, `true` або `false`. `partial` і `true` вмикають оновлення чернетки за принципом "спочатку попередній перегляд" через звичайні текстові повідомлення Matrix. `quiet` використовує попередні повідомлення без сповіщень для самостійно розгорнутих конфігурацій push-правил. +- `blockStreaming`: `true` вмикає окремі повідомлення про прогрес для завершених блоків асистента, поки активне потокове передавання чернетки попереднього перегляду. - `threadReplies`: `off`, `inbound` або `always`. -- `threadBindings`: перевизначення на рівні каналу для маршрутизації та життєвого циклу сеансів, прив’язаних до гілок. +- `threadBindings`: перевизначення для каналу щодо маршрутизації та життєвого циклу сеансів, прив’язаних до тредів. - `startupVerification`: режим автоматичного запиту на самоверифікацію під час запуску (`if-unverified`, `off`). -- `startupVerificationCooldownHours`: cooldown перед повторною спробою автоматичних запитів на верифікацію під час запуску. +- `startupVerificationCooldownHours`: cooldown перед повторною спробою автоматичних запитів верифікації під час запуску. - `textChunkLimit`: розмір фрагмента вихідного повідомлення. - `chunkMode`: `length` або `newline`. - `responsePrefix`: необов’язковий префікс повідомлення для вихідних відповідей. -- `ackReaction`: необов’язкове перевизначення ack reaction для цього каналу/облікового запису. -- `ackReactionScope`: необов’язкове перевизначення області ack reaction (`group-mentions`, `group-all`, `direct`, `all`, `none`, `off`). +- `ackReaction`: необов’язкове перевизначення реакції-підтвердження для цього каналу/облікового запису. +- `ackReactionScope`: необов’язкове перевизначення області дії реакції-підтвердження (`group-mentions`, `group-all`, `direct`, `all`, `none`, `off`). - `reactionNotifications`: режим вхідних сповіщень про реакції (`own`, `off`). -- `mediaMaxMb`: обмеження розміру медіа в MB для обробки медіа в Matrix. Застосовується до вихідних надсилань і обробки вхідних медіа. -- `autoJoin`: політика автоматичного приєднання за запрошенням (`always`, `allowlist`, `off`). За замовчуванням: `off`. -- `autoJoinAllowlist`: кімнати/псевдоніми, дозволені, коли `autoJoin` дорівнює `allowlist`. Записи псевдонімів визначаються до ID кімнат під час обробки запрошень; OpenClaw не довіряє стану псевдоніма, заявленому запрошеною кімнатою. +- `mediaMaxMb`: ліміт розміру медіа в МБ для обробки медіа Matrix. Він застосовується до вихідних відправлень і обробки вхідних медіа. +- `autoJoin`: політика автоматичного приєднання до запрошень (`always`, `allowlist`, `off`). За замовчуванням: `off`. Це застосовується до запрошень Matrix загалом, включно із запрошеннями у стилі DM, а не лише до запрошень у кімнати/групи. OpenClaw приймає це рішення в момент запрошення, до того як може надійно класифікувати приєднану кімнату як DM чи групу. +- `autoJoinAllowlist`: кімнати/псевдоніми, дозволені, коли `autoJoin` має значення `allowlist`. Записи псевдонімів розв’язуються до ID кімнат під час обробки запрошення; OpenClaw не довіряє стану псевдоніма, заявленому запрошеною кімнатою. - `dm`: блок політики DM (`enabled`, `policy`, `allowFrom`, `sessionScope`, `threadReplies`). -- Записи `dm.allowFrom` мають бути повними Matrix user ID, якщо ви вже не визначили їх через пошук у живому каталозі. +- `dm.policy`: керує доступом до DM після того, як OpenClaw приєднався до кімнати й класифікував її як DM. Це не змінює того, чи буде запрошення автоматично прийняте. +- Записи `dm.allowFrom` мають бути повними Matrix user ID, якщо ви вже не розв’язали їх через живий пошук у каталозі. - `dm.sessionScope`: `per-user` (за замовчуванням) або `per-room`. Використовуйте `per-room`, якщо хочете, щоб кожна Matrix DM-кімната зберігала окремий контекст, навіть якщо співрозмовник той самий. -- `dm.threadReplies`: перевизначення політики гілок лише для DM (`off`, `inbound`, `always`). Воно перевизначає верхньорівневе налаштування `threadReplies` як для розміщення відповідей, так і для ізоляції сеансів у DM. +- `dm.threadReplies`: перевизначення політики тредів лише для DM (`off`, `inbound`, `always`). Воно перевизначає верхньорівневе налаштування `threadReplies` як для розміщення відповідей, так і для ізоляції сеансів у DM. - `execApprovals`: нативна доставка погоджень exec через Matrix (`enabled`, `approvers`, `target`, `agentFilter`, `sessionFilter`). -- `execApprovals.approvers`: Matrix user ID, яким дозволено погоджувати запити exec. Необов’язково, якщо `dm.allowFrom` уже визначає погоджувачів. +- `execApprovals.approvers`: Matrix user ID, яким дозволено погоджувати запити exec. Необов’язково, якщо `dm.allowFrom` уже визначає тих, хто погоджує. - `execApprovals.target`: `dm | channel | both` (за замовчуванням: `dm`). -- `accounts`: іменовані перевизначення для окремих облікових записів. Верхньорівневі значення `channels.matrix` діють як значення за замовчуванням для цих записів. -- `groups`: мапа політик для кімнат. Віддавайте перевагу ID кімнат або псевдонімам; невизначені назви кімнат ігноруються в runtime. Ідентичність сеансу/групи після визначення використовує стабільний ID кімнати, тоді як читабельні мітки все ще походять із назв кімнат. +- `accounts`: іменовані перевизначення для кожного облікового запису. Значення верхнього рівня `channels.matrix` діють як значення за замовчуванням для цих записів. +- `groups`: мапа політик для кожної кімнати. Віддавайте перевагу ID кімнат або псевдонімам; нерозв’язані назви кімнат ігноруються під час runtime. Ідентичність сеансу/групи використовує стабільний room ID після розв’язання, а читабельні мітки для людей і далі походять із назв кімнат. - `groups..account`: обмежити один успадкований запис кімнати конкретним обліковим записом Matrix у конфігураціях із кількома обліковими записами. -- `groups..allowBots`: перевизначення на рівні кімнати для відправників-налаштованих ботів (`true` або `"mentions"`). -- `groups..users`: allowlist відправників для кімнати. -- `groups..tools`: перевизначення allow/deny інструментів для кімнати. -- `groups..autoReply`: перевизначення mention-gating на рівні кімнати. `true` вимикає вимогу згадування для цієї кімнати; `false` знову примусово вмикає її. +- `groups..allowBots`: перевизначення на рівні кімнати для відправників із налаштованих ботів (`true` або `"mentions"`). +- `groups..users`: allowlist відправників для певної кімнати. +- `groups..tools`: перевизначення allow/deny інструментів для певної кімнати. +- `groups..autoReply`: перевизначення mention-gating на рівні кімнати. `true` вимикає вимоги щодо згадок для цієї кімнати; `false` знову примусово вмикає їх. - `groups..skills`: необов’язковий фільтр Skills на рівні кімнати. - `groups..systemPrompt`: необов’язковий фрагмент system prompt на рівні кімнати. - `rooms`: застарілий псевдонім для `groups`. -- `actions`: контроль доступу до інструментів для окремих дій (`messages`, `reactions`, `pins`, `profile`, `memberInfo`, `channelInfo`, `verification`). +- `actions`: керування інструментами для окремих дій (`messages`, `reactions`, `pins`, `profile`, `memberInfo`, `channelInfo`, `verification`). ## Пов’язане - [Огляд каналів](/uk/channels) — усі підтримувані канали -- [Pairing](/uk/channels/pairing) — автентифікація DM і процес pairing -- [Групи](/uk/channels/groups) — поведінка групового чату та mention gating -- [Маршрутизація каналів](/uk/channels/channel-routing) — маршрутизація сеансів для повідомлень -- [Безпека](/uk/gateway/security) — модель доступу й посилення захисту +- [Pairing](/uk/channels/pairing) — автентифікація DM і потік pairing +- [Групи](/uk/channels/groups) — поведінка групового чату та gating згадок +- [Маршрутизація каналів](/uk/channels/channel-routing) — маршрутизація сесій для повідомлень +- [Безпека](/uk/gateway/security) — модель доступу та посилення захисту