Довідка / Архів та інтеграції
Telegram · Довідка щодо Case Board
Закладки, точні виділення, фрагменти дій, обговорення, обмежений доступ та історія підписаних анотацій, що використовуються Case Board.
TgWitness / Документація · Розслідування
Case Board надає слідчій групі спільний робочий огляд збережених матеріалів. Додавайте спостереження до закладок, виділяйте конкретні фрагменти, зберігайте послідовність дій та обговорюйте їх із колегами. Картки зберігають посилання на джерела та підписану історію редагувань. Коментарі команди залишаються в робочому просторі, де їх можна легко відрізнити від оригінальних спостережень у Telegram.
Модель доказів · Доступ · Звіти

На цій сторінці
Робота зі справою#
Відкрийте «Розслідування» → «Case Board» у стандартному або експертному режимі. Мова відповідає панелі. Використовуйте кнопку «Додати до дошки» поруч із записом у журналі або збереженим повідомленням у чаті, або виділіть його та натисніть клавішу B. Закладка додається до «Вхідних» одним клацанням. Редагуйте її назву, мітки та примітку або перемістіть її до колекції. Змінена картка доповнюється підписаною версією; її видалення зберігає історію.
Для першого випадку виберіть колекцію та додайте записи, які дають відповідь на одне питання. Використовуйте коментарі для перевірки інтерпретації, а потім — функцію «Презентація», щоб переглянути картки та контекст джерел. Окремо вибирайте матеріали для «Case Board» у «Report Studio» під час підготовки кінцевого результату. Збереження фрагмента не призводить до автоматичного налаштування фільтрів даних звіту.
Виділіть текст у збереженому повідомленні чату, щоб відкрити меню «Виділити → дошка». Виберіть колір і додайте примітку. Сервер перевіряє точну цитату та збережену версію, включаючи емодзі, текст у напрямку справа наліво (RTL) та знаки об’єднання. Інтерфейс не відображає виділений фрагмент у маскованому або перетвореному тексті.
Натисніть Shift і клацніть на двох записах в одному чаті, щоб вибрати «Виділити проміжок між ними», скористайтеся функцією «Виділити за часом» або збережіть поточні фільтри журналу за чатом, періодом та типом події. Збережений проміжок має власний авторитетний предикат: його відкриття в «Журналі» також застосовує фільтри за кількома чатами, обмеженнями кількості повідомлень та учасниками . Функція «Показати записи, додані після створення закладки» виділяє пізніші доповнення. Зміна фільтрів у Journal призводить до виходу зі зрізу. У розділі «Люди» функція «Розділити дії цієї особи» використовує записаний ідентифікатор учасника; вона не припускає, що автор повідомлення редагував, видалив або відреагував на повідомлення.
У діалоговому вікні «Слайс» перед створенням відображається попередній перегляд кількості записів. Термін «all» охоплює всі типи записаних даних,
включно зі знімками екрана, редагуваннями, видаленнями, реакціями, оновленнями членства/послуг, власними діями,
кнопками, мультимедійними результатами, відновленими повідомленнями та майбутніми типами подій. Цей вибір описує
збережені спостереження. Повідомлення про видалення невідомих чатів є окремим контекстом,
доступним лише для користувачів із повним доступом до робочого простору, і ніколи не пов’язуються з жодним із обраних чатів.
Колекції мають визначену область чату. Порожня область означає весь робочий простір. Колекція не може містити картки поза межами своєї області; учасник, обмежений чатом, не може переглядати колекцію, що охоплює ширшу область. «Вхідні» — це віртуальна колекція для непризначених карток. Пошук та фільтри охоплюють лише видимі картки; нитки обговорень та згадки успадковують права доступу батьківської картки. Видалені коментарі мають позначку «видалено» у дискусії. Історія переглядів не фіксується.
У режимі презентації відкриваються всі картки у вибраній колекції з переглядами «Картка», «Контекст джерела» та «Коментарі команди», а також клавішами «Попередня»/«Наступна». Цей режим не надає засобів редагування. Звичайна стрічка має розбивку на сторінки; у режимі презентації список завантажується сторінками, а деталі однієї картки відображаються по черзі.
Дозволи#
Усі операції вимагають доступу до view, робочої області/чату та board.read. board.write додає картки,
коментарі, переміщує та встановлює статуси «відкрито»/«переглянуто». board.manage дозволяє керувати колекцією,
встановлювати статуси «підтверджено»/«відхилено», редагувати або видаляти чужі картки. Статус є рішенням команди,
а не результатом криптографічної верифікації.
Доступ до попередньо встановлених налаштувань форм: «Рецензент» = читання; «Аналітик» = читання/запис; «Оператор» = читання/запис/управління, на додаток до їхніх існуючих дозволів. Існуючі права доступу не передбачають автоматичного отримання нових прав. Головний адміністратор має всі права та публікує як «Головний адміністратор». Використовуйте іменні дозволи для атрибуції. У списку згадок вказано лише поточні доступи, які дозволяють читати повну батьківську картку.
Грант для чату A не може отримати картку або фрагмент для A+B, навіть вгадавши його ID або вказавши
неправильний target.chat_id. Метадані цільового об’єкта визначаються на сервері за підписаним хешем події.
Колекції, кількість обговорень, пов’язані картки та оперативні сповіщення фільтруються перед наданням відповіді.
Для експорту потрібні права «export», а також «board.read»; існуючий експортер без доступу до дошки отримує
звичайний архів доказів без командних нотаток. SSE перед кожним пакетом повторно перевіряє поточні дозволи.
Збережені контракти#
Як і спостереження, анотації записуються транзакційно у таблицю SQLite з можливістю лише додавання даних у
робочій області. Файл annotations.jsonl є її точним канонічним експортом із того самого знімка для читання, що й
events.jsonl. Не існує другого конкуруючого сховища анотацій, а також події журналу board.activity.
Кожен рядок містить саме:
{
"seq": 1,
"at": "2026-11-02T14:00:00.000+00:00",
"access_id": "admin",
"access_label": "Main administrator",
"kind": "board.bookmark",
"payload": {"id": "32 lowercase hex digits", "target": {"event_hash": "64 lowercase hex digits"}},
"previous_hash": "64 zeroes for the first record",
"hash": "SHA-256 described below",
"signature": "base64 Ed25519 signature"
}
Наведений вище скорочений приклад ілюструє конверт; фактичні корисні дані містять свої
значення за замовчуванням та цільові поля, що визначаються сервером. Схеми запитів API знаходяться в папці
tgwitness/schemas, вони генеруються з моделей Pydantic
під час виконання за допомогою скрипту python tools/build_board_schemas.py. Додаткові поля запиту відхиляються. Ідентифікатори
генеруються на стороні сервера, якщо вони пропущені. Авторство, час, знімок та підпис не можуть бути вказані
викликачем. Ідентифікатори іменних дозволів відповідають існуючому 16-гекс-формату Access; ідентифікатори карток — 32-гекс.
Канонічний JSON — це UTF-8, відсортовані ключі об’єктів, відсутність пробілів між токенами, неескеплений Unicode,
а також відсутність значень NaN та нескінченності. Хеш анотації — це SHA-256 канонічного об’єкта, що містить формат «
format: "tgwitness-annotations-v1"» та всі сім полів конверта аж до «previous_hash».
Цей тег формату відокремлює домен хешу від спостережень. Підпис — Ed25519 над
32 байтами необробленого хешу. Послідовність починається з 1. Ревізії зберігають ідентифікатор картки та вказують попередній
хеш анотації у полі «supersedes»; вони не можуть змінювати область дії чату. Переміщення, статуси та видалення є
окремими записами. Таблиця SQLite відхиляє команди UPDATE та DELETE.
Файл case-board.json містить {statement, signature}. Канонічне твердження підписується
ключем робочого простору та містить format: "tgwitness-case-board-v1", public_key, created_at,
journal_head, meaning та state. Стан є детермінованим відтворенням: annotations_head,
впорядкований масив items (колекції, картки, коментарі, включаючи «надгробки») та status_history.
Елементи зберігають хеш останньої анотації, послідовність, автора та час, а також оригінального
творця та час створення у всіх версіях. Повторне відтворення перевіряє версії,
батьківські елементи, посилання на колекції та дублікати ідентифікаторів дій. Файл `manifest.json` та нові контрольні точки
також пов’язують `annotations_head`. Зберігайте контрольну точку окремо, щоб виявити обрізання або перезапис
за допомогою скопійованого ключа підпису.
Текстові версії#
range.start — це зміщення кодової точки Unicode з нульовою базою, length — це додатне значення кількості кодових точок,
а quote має дорівнювати точному підрядку з payload.text або payload.caption у цільовій
події. Не застосовуються NFC/NFKC, перетворення регістру або нормалізація графем. Фрагменти рядків у Python та
Array.from(text) у JavaScript реалізують таке саме індексування. Поєднання знаків та емодзі ZWJ може
займати кілька кодових точок. range.version — це хеш цільової події, а не поточна версія повідомлення
чи зміщення сутності UTF-16 у Telegram. Пізніші редагування ніколи не переміщують виділення автоматично.
Розділ «Ідентифікація та час»#
query приймає рівно один chat_id або непорожні chat_ids, опціональні діапазони from/to,
діапазони ідентифікаторів повідомлень (лише один чат), kinds: "all" або точні/префіксні види з використанням символів-замінників,
явні actors, search, hide_system та include_unscoped. Групи видів журналу розгортаються до
їхніх точних предикатів. Пошук використовує пошук за корисним навантаженням журналу з урахуванням NFC та ігноруванням регістру, не змінюючи
підписаний вихідний текст. Дати вимагають часового поясу та нормалізуються до UTC.
Дати фільтрують `observed_at`. Поле `source_at` Telegram відображається окремо. Видалення без
мітки часу джерела не має вигаданого часу видалення. Пізній запис, спостережений поза часовим інтервалом,
не потрапляє до нього; фрагмент за ідентифікаторами повідомлень може містити пізніші видалення для цих ідентифікаторів повідомлень.
«snapshot» фіксує час створення, межу послідовності/хешу журналу, кількість збігів, першу/останню
послідовність та result_hash. Останній — це SHA-256 канонічного масиву JSON у форматі UTF-8 із хешами збігів
подій, відсортованих за лексикографічним порядком, включаючи [] для порожнього фрагмента. Він також містить точні
підрахунки типів та мініатюру часу спостереження з 24 бінами. Слайс зберігає запит, а не дублікати записів джерел
. Під час експорту файл board/slices/<id>.json містить перелік поточних хешів та доданих/видалених послідовностей.
Верифікатор відтворює початковий результат на межі створення, а потім — поточний результат.
Додані записи повідомляються як факт зміни. Видалення початкової події порушує незмінний
ланцюг доказів; це не сприймається мовчки як звичайне видалення зі зрізу.
Знімки реакцій містять неповні списки останніх учасників. Експлорер порівнює сусідні знімки одного й того самого чату/повідомлення, включаючи попередній знімок поза межами фрагмента, та повідомляє про сумарні зміни кількості між спостереженнями. Відсутність останніх учасників не означає, що реакція була видалена. Перший знімок не має виведеного попереднього стану. Спостереження за учасниками залишаються прив’язаними до знімка, в якому вони були надані, а не до вигаданого часу дії.
API та експорт даних#
GET /api/board, що приймає параметри collection/chat/author/label/state/from/to/q/kind/comments, offset/limit
та порядок newest/oldest. GET /api/board/card/{id} повертає картку, попередній перегляд джерела, ланцюжок повідомлень,
історію статусів та пов’язані картки. Підмаршрут participants повертає відповідні варіанти згадок.
POST /api/board/{bookmark|highlight|slice|collection|comment|status|move|remove} додає запис.
POST /api/board/slice-preview обчислює запит. Записи фрагментів розбиваються на сторінки за допомогою
GET /api/board/slice/{id}/records; для переобчислення завжди використовується поточний стабільний знімок для читання.
Live /api/stream надсилає сповіщення про дошку (board) без корисного навантаження, окремо від курсорів журналу.
GET /api/board/export повертає підписаний документ. Доступ, обмежений чатом, отримує чітко позначене
підписане розкриття інформації, ніколи — анотації з іншого чату або повний ланцюжок. Повні архівні ZIP-файли з доказами
містять файл annotations.jsonl, підписаний файл case-board.json та додатки у форматі JSON із фрагментами. Налаштування звіту у форматі
HTML/PDF/JSON дозволяють вибрати варіант без дошки, закладки/фрагменти без обговорення або картки з коментарями. Цей
розділ чітко відокремлює думки команди від спостережень. Фільтри даних звіту також обмежують
доступні для читання нотатки; повні підписані вихідні файли у ZIP-архіві з доказами залишаються незмінними.
GET /api/board/slice/{id}/export генерує підписаний фрагмент JSON-даних у форматі tgwitness-board-selection-v1;
?format=csv генерує зручну таблицю без окремого підпису. Збережіть формати JSON та ZIP:
python -m tgwitness.verify evidence.zip --fingerprint TRUSTED_KEY_SHA256 --board
python -m tgwitness.verify board-slice.json --evidence evidence.zip --fingerprint TRUSTED_KEY_SHA256
python -m tgwitness.verify case-board.json --evidence evidence.zip --fingerprint TRUSTED_KEY_SHA256
Перевірка відбору підтверджує автентичність підписаної заяви, точність вихідних записів та повноту запиту в межах зазначеної межі. Архів доказів у форматі ZIP може бути новішим, але повинен містити цей префікс. Про відсутню ціль повідомляється явно. Інший знімок вихідного фрагмента, змінена анотація, невідповідність стану відтворення або змінене джерело призводять до відмови. Старі архіви без анотацій зберігають існуючу поведінку перевірки.
За замовчуванням для передачі встановлено значення «Не включати». Явне включення відображає картки проєктів серед вже
згорнутих записів, оминає недоступні/пропущені об’єкти, приховує виділені фрагменти, джерельний текст яких
був згорнутий, очищає текст команди за тими самими правилами згадок/контактів та, за бажанням, замінює
мітки слідчих на R01, R02… у метаданих та відомих згадках у нотатках. Оригінальний файл
annotations.jsonl не розкривається. Підписаний файл-супровідник tgwitness-case-board-handover-v1 та звіт
містять той самий мінімізований матеріал. Кількість фрагментів описує лише розкриті записи, при цьому оригінальні
деталі про учасників знімків/запитів не розкриваються. Імена у вільному тексті, невідомі мінімізатору, як і у звичайних передачах, все ще потребують
перевірки. Цей похідний файл не претендує на збереження оригінальних
підписів анотацій після редагування.
Обмеження щодо використання#
Параметри включають м’які обмеження у 10 000 карток та 50 000 коментарів, сторінку фрагмента, що містить до 5 000 записів, та контроль попереднього перегляду медіафайлів. М’які обмеження видають попередження, не видаляючи історію. Сторінки стрічки містять не більше 200 карток. Розмір автономних уривків у форматі JSON обмежено 64 МіБ; для більших обсягів матеріалів звузьте запит або скористайтеся підписаним ZIP-файлом. Автономний верифікатор обмежує відтворення анотацій до 256 МіБ. Case Board не підтримує та не реалізує зовнішні сповіщення про коментарі.
Автоматизоване приймання функції використовує вигадані дані та імітований канал передачі Telegram для перевірки зберігання, доступу, візуалізації та експорту. Див. розділ «Обсяг перевірки» для ознайомлення з обсягом перевірки доказів.