Як працює Bitchat: архітектура Bluetooth-mesh месенджера

🎯 Архітектура Bitchat: два транспортних рівні

Немає єдиного сервера — немає єдиної точки відмови. Мережа існує доти, доки існують пристрої.

Класична архітектура месенджера — це зірка: всі пристрої з'єднані через центральний сервер. Якщо сервер падає або блокується — зв'язок зникає. Bitchat відмовляється від цієї моделі на користь повністю децентралізованої топології, описаної в README проекту як «dual transport architecture».

Перший рівень: Bluetooth mesh

BLE mesh — основний транспорт. Повідомлення передається між пристроями напряму через Bluetooth без жодної мережевої інфраструктури. Кожен смартфон із запущеним Bitchat є одночасно клієнтом (відправляє і отримує) і ретранслятором (передає далі). Маршрутизація — hop-to-hop із TTL-лічильником: максимум 7 хопів на повідомлення, що обмежує безконтрольне розмноження пакетів у мережі.

Для ефективної передачі через BLE з його обмеженим MTU (Maximum Transmission Unit) Bitchat використовує бінарний протокол із компактним пакетним форматом і стиснення LZ4 для зменшення розміру повідомлень. Великі повідомлення автоматично фрагментуються на частини і збираються на стороні отримувача.

Другий рівень: Nostr як fallback

Nostr — відкритий децентралізований протокол передачі повідомлень через інтернет. Якщо хоча б один вузол у mesh-мережі має інтернет-з'єднання («gateway peer»), він виступає мостом між локальною BLE-мережею і глобальними Nostr-релеями. Для Nostr-повідомлень використовується стандарт NIP-17 (приватні direct messages у Nostr). З версії 1.3.0 додані Geohash-канали через Nostr для геолокаційного чату — користувачі з інтернетом потрапляють у канали за географічними координатами.

Як два рівні взаємодіють

Перемикання між BLE і Nostr прозоре для користувача. Повна схема взаємодії описана у whitepaper: локальна mesh-мережа → gateway peer → Nostr relay → інша mesh-мережа в іншому місці. Це дозволяє з'єднувати географічно розділені mesh-кластери через інтернет-міст, зберігаючи децентралізовану логіку обох кінців.

Чому гібридна модель краща за чисто офлайн

Чисто офлайн-рішення обмежене фізичною дальністю BLE (~300 м через ланцюжок). Гібрид дозволяє: коли інфраструктура є — використовувати її для розширення мережі через Nostr; коли немає — продовжувати працювати локально через BLE без деградації. Користувач у «pure offline» середовищі не помічає жодної різниці.

• ✔️ BLE mesh: локальний зв'язок без інтернету, без сервера, без реєстрації
• ✔️ TTL = 7 хопів: контрольоване розповсюдження пакетів у мережі
• ✔️ LZ4 + бінарний протокол: оптимізація для обмежень BLE
• ✔️ Nostr (NIP-17) fallback: глобальний міст при наявності інтернету
• ✔️ Geohash-канали (v1.3.0+): геолокаційні чати через Nostr-релеї
• ✔️ Перемикання між рівнями — автоматичне, прозоре для користувача

Висновок: Bitchat — гібридна P2P-система з двома незалежними транспортними рівнями і чітко специфікованим протоколом: BLE mesh із TTL-маршрутизацією і Nostr як опціональний інтернет-міст.

📌 Розділ 2. Що таке Bluetooth Mesh і як він працює

У mesh-мережі немає «центру» — є лише вузли. Кожен новий пристрій розширює мережу, а не навантажує сервер.

Bluetooth Low Energy (BLE) — стандарт бездротового зв'язку малого енергоспоживання, вбудований у кожен сучасний смартфон. Bitchat використовує його не як канал парного з'єднання двох пристроїв (як AirDrop чи навушники), а як основу для mesh-топології — розподіленої мережі без центрального вузла, де кожен пристрій є одночасно клієнтом і ретранслятором.

Dual-role архітектура: Central і Peripheral одночасно

Згідно з whitepaper, BLEService реалізує dual-role топологію: кожен пристрій одночасно виконує дві ролі:

• Central role — сканує ефір, знаходить сусідні пристрої, ініціює підключення і відправляє повідомлення через GATT write
• Peripheral role — рекламує свою присутність, приймає підключення від інших Central-пристроїв, відправляє повідомлення через GATT notify

Для взаємного виявлення всі пристрої використовують спільний Characteristic UUID: A1B2C3D4-E5F6-4A5B-8C9D-0E1F2A3B4C5D. Характеристика підтримує і write-without-response (Central → Peripheral), і notify (Peripheral → Central) — що забезпечує двосторонню комунікацію.

Як формується мережа: peer discovery

При запуску застосунок починає BLE-сканування з фільтром за Service UUID. Пристрій рекламує свій PeerID і нікнейм у BLE advertisement. Після виявлення сусіда — GATT handshake: обмін публічними ключами і встановлення зашифрованого Noise-сеансу. Весь процес автоматичний: користувач не виконує жодних ручних дій.

Для збереження заряду батареї BLEService реалізує адаптивний connection budget і scan duty cycle: коли пристрій не в активній розмові — сканування переходить у режим економії. При слабкому RSSI (<–90 dBm) пристрій уникає підключення до цього вузла протягом 30 секунд.

TTL-based flooding із дедуплікацією

Bitchat використовує gossip protocol: кожен пакет містить TTL-лічильник (початкове значення = 7). При кожному ретранслюванні TTL зменшується на 1. Пакет з TTL=0 — не ретранслюється, що обмежує безконтрольне розповсюдження. Максимальний ланцюжок — 7 хопів.

Щоб уникнути повторної обробки одного пакету (який може прийти від кількох вузлів одночасно), Bitchat використовує OptimizedBloomFilter — імовірнісну структуру даних для швидкої перевірки: «чи бачив я вже цей пакет?». Це значно ефективніше за зберігання повного списку ID.

Hop-to-hop routing: як повідомлення долає відстань

Якщо Аліса і Боб поза прямою зоною досяжності, але між ними є Крістіна — повідомлення проходить маршрут Аліса → Крістіна → Боб. Кожен «стрибок» (hop) — передача між двома вузлами в межах BLE-дальності. Від білого паперу: дальність між двома вузлами напряму — ~30 м (indoor), через 7-хоповий ланцюжок — значно більше залежно від щільності.

Динамічна топологія: що відбувається, коли вузол зникає

Якщо вузол іде офлайн — він надсилає graceful leave message сусідам перед відключенням. BLEService запускає maintenance timer кожні 5 секунд: прибирає застарілі фрагменти, видаляє відключених peers із активного списку, оновлює кандидатів на підключення. Мережа автоматично перебудовує маршрути — єдиної точки відмови немає.

• ✔️ Dual-role: кожен пристрій одночасно Central і Peripheral
• ✔️ Автовиявлення через спільний Characteristic UUID
• ✔️ TTL=7 хопів + OptimizedBloomFilter для дедуплікації
• ✔️ Адаптивний connection budget для збереження батареї
• ✔️ Graceful leave + maintenance timer кожні 5 сек
• ✔️ Динамічне перебудування маршрутів без участі користувача

Висновок: BLE mesh у Bitchat — це самоорганізована dual-role мережа з TTL-flooding, Bloom filter дедуплікацією і адаптивним управлінням енергоспоживанням, повністю специфікована у відкритому whitepaper.

📌 Як передаються повідомлення

Store-and-forward — це пошта, а не телефонний дзвінок: відправив, мережа зберегла, адресат отримає коли з'явиться.

У централізованих месенджерах сервер завжди доступний і зберігає повідомлення до моменту доставки. У Bitchat сервера немає — роль буфера виконують самі вузли мережі. Whitepaper v1.1 (25 липня 2025) описує повний шлях повідомлення через протокольний стек.

Повний шлях повідомлення: від UI до отримувача

Згідно з sequence diagram із whitepaper, кожне повідомлення проходить такий маршрут:

1. UI → Encryption Service: перед відправкою генерується випадкова затримка 50–500 мс для захисту від traffic analysis (приховує момент відправки від стороннього спостерігача)
2. Encryption Service → Fragment Handler: повідомлення шифрується залежно від типу (докладніше — у секції 4)
3. Fragment Handler → BLE Transport: якщо повідомлення > 500 байт — фрагментується на частини з міжфрагментною затримкою 20 мс; якщо ≤ 500 байт — надсилається цілком
4. BLE Transport → Mesh Router: пакет передається з TTL=7
5. Mesh Router → перевірка отримувача:

   • Отримувач онлайн → пряма доставка
   • Отримувач офлайн → повідомлення передається до Store & Forward Cache

Store-and-forward: диференційована політика зберігання

Bitchat реалізує tiered retention policy — різний термін зберігання залежно від статусу відправника:

• Звичайний пір → кешування 12 годин, після чого повідомлення видаляється
• «Favorite» контакт → зберігання необмежено до доставки

Коли офлайн-пристрій повертається в мережу — він автоматично отримує всі закешовані повідомлення від вузлів, у зоні яких з'явився. Жодних ручних дій не потрібно.

Типи повідомлень і адресація

Bitchat розрізняє три типи повідомлень із різною адресацією і шифруванням:

Важлива деталь для DM: ретрансляційні вузли бачать лише зашифрований Noise-пакет — вони не можуть розшифрувати вміст або навіть визначити, хто є реальним отримувачем, окрім як за recipientID. Контент залишається конфіденційним на всьому шляху через mesh.

Групові чати: hashtag-кімнати

Групові чати в Bitchat — це IRC-inspired канали з командним інтерфейсом: /join, /msg, /who. Канал ідентифікується хештегом (наприклад, #kyiv). Опціональний пароль захищає канал: повідомлення шифруються ключем, похідним від пароля через Argon2id — memory-hard функцію, стійку до brute-force. Власник каналу може увімкнути Message Retention — збереження історії для нових учасників.

Geohash-канали: геолокаційний чат через Nostr

З версії 1.3.0 з'явились Geohash-канали — чати, прив'язані до географічних координат через протокол Nostr. Geohash — це алгоритм кодування координат у короткий рядок: наприклад, u8c2 відповідає певному квадрату на карті. Пристрої з інтернетом автоматично підписуються на Nostr-канал свого geohash і можуть спілкуватись із людьми в тому ж районі — навіть без прямого BLE-з'єднання між ними.

DeliveryAck: підтвердження доставки

Whitepaper описує окремий тип пакету — DeliveryAck: підтвердження отримання повідомлення. Після успішного розшифрування отримувач надсилає ACK назад через mesh. Це дозволяє відправнику знати, що повідомлення дійшло — аналог «галочок» у WhatsApp, але без центрального сервера.

Захист від traffic analysis: random delay і fixed-size padding

Bitchat реалізує два механізми захисту від пасивного спостереження за мережевим трафіком:

• Random delay 50–500 мс перед відправкою — приховує точний момент відправки і кореляцію між діями користувача і мережевою активністю
• Fixed-size padding для всіх пакетів — унеможливлює визначення типу чи розміру повідомлення за розміром BLE-пакету

• ✔️ Чотиришаровий протокольний стек: UI → Encryption → Fragment → Transport
• ✔️ Фрагментація при >500 байт, міжфрагментна затримка 20 мс
• ✔️ Store-and-forward: 12 год (regular) / необмежено (Favorites)
• ✔️ Три типи повідомлень: DM (X25519), Room (Argon2id), Broadcast (Ed25519)
• ✔️ IRC-командний інтерфейс: /join, /msg, /who
• ✔️ DeliveryAck: підтвердження доставки без сервера
• ✔️ Random delay + fixed padding: захист від traffic analysis
• ✔️ Geohash-канали (v1.3.0+): геолокаційні чати через Nostr

Висновок розділу: Bitchat реалізує повноцінний протокольний стек із диференційованим кешуванням, трьома типами шифрування залежно від типу повідомлення і захистом від traffic analysis — все без єдиного центрального сервера.

📌 Шифрування та identity без акаунта

Відсутність сервера — це не лише перевага приватності, але й виклик для автентифікації: немає центрального реєстру, якому можна довіряти.

Noise Protocol Framework: що це і чому саме він

Noise Protocol Framework — це сімейство криптографічних протоколів для побудови захищених каналів зв'язку. Він використовується в Signal, WireGuard і Lightning Network. Bitchat використовує Noise для шифрування direct messages: між двома сторонами встановлюється зашифрований канал без участі будь-якого сервера.

Ephemeral keys: ключі, які не зберігаються

Ephemeral (тимчасові) ключі генеруються для кожної сесії і не зберігаються після її завершення. Це забезпечує forward secrecy: навіть якщо довгостроковий ключ буде скомпрометований, попередні сесії залишаться захищеними. Оскільки сервера немає — ключі фізично ніде не зберігаються на зовнішньому ресурсі.

Identity без акаунта: публічний ключ як ідентифікатор

При першому запуску Bitchat генерує пару криптографічних ключів. Публічний ключ — це ваш ідентифікатор у мережі: аналог імені користувача, але без реєстрації, номера телефону чи email. Приватний ключ зберігається лише на вашому пристрої.

⚠️ Відома вразливість: impersonation

Дослідник безпеки Алекс Радоця виявив, що в поточній реалізації можливе impersonation — видавати себе за іншого користувача. Проблема пов'язана з відсутністю надійної системи верифікації публічних ключів у децентралізованому середовищі без довіреного реєстру. Джек Дорсі публічно визнав проблему на GitHub. Зовнішній незалежний security audit ще не проводився.

• ✔️ DM: end-to-end шифрування через Noise Protocol
• ✔️ Ephemeral keys: forward secrecy без серверного зберігання
• ✔️ Identity: публічний ключ без реєстрації
• ⚠️ Вразливість impersonation — не виправлена
• ⚠️ Аудит відсутній — не для продакшн-використання

Висновок розділу: Криптографічна база Bitchat солідна, але відсутність аудиту і невирішена вразливість impersonation роблять його непридатним для критично важливих комунікацій.

📌 Обмеження Bluetooth-mesh мереж

Чесний технічний розбір — це не список недоліків, а карта обмежень: знаючи їх, ви знаєте, де інструмент працює, а де — ні.

Latency: затримки при великій кількості хопів

Кожен hop додає затримку: пристрій приймає зашифрований пакет, перевіряє через OptimizedBloomFilter (чи не бачив раніше), зменшує TTL і ретранслює далі. В розріджених мережах повідомлення можуть суттєво затримуватись, особливо коли потрібно пройти кілька вузлів. Для порівняння: у client-server месенджерах затримка визначається лише RTT до сервера — зазвичай <100 мс. У Bitchat затримка при 7-хоповому ланцюжку може досягати кількох секунд.

Throughput: BLE не для великих даних

BLE advertisement обмежений 31 байтом — Bitchat компенсує це LZ4-стисненням і фрагментацією пакетів, але фізичні обмеження протоколу залишаються. Практичний максимум пропускної здатності BLE — кілька сотень кілобіт на секунду. Цього достатньо для текстових повідомлень, але передача фото, відео або голосових повідомлень у поточній реалізації недоступна.

Споживання батареї: три режими роботи

Активна участь у mesh-мережі розряджає батарею приблизно на 40% швидше, ніж звичайний режим використання телефону. Bitchat реалізує адаптивний duty cycle із трьома режимами scan intervals:

Вузли, що потребують низьку затримку, мають тримати активні вікна прослуховування — це додатково збільшує споживання енергії. Через цей дизайн BLE mesh погано підходить для мереж із живленням від батарей. Це стандартна проблема BLE mesh, не специфічна для Bitchat.

Щільність пристроїв: мережа деградує без вузлів

Продуктивність мережі деградує при надто малій кількості учасників. BLE mesh із розподіленим трафіком між багатьма точками уникає єдиних точок відмови — але і функціонує лише коли таких точок достатньо. У малолюдному районі або без критичної маси користувачів мережа може складатись із 2–3 вузлів — і фактично не виконувати функцію mesh.

Це т.зв. cold start problem: застосунок максимально корисний саме тоді, коли його встановила велика кількість людей поруч. До досягнення цієї маси — його ефективність обмежена.

Кешування: 12 годин і диференційована політика

Store-and-forward зберігає повідомлення до 12 годин для звичайних контактів. Виняток — «Favorites»: для них зберігання необмежене до моменту доставки. Якщо отримувач не з'явився в мережі за 12 годин — повідомлення безповоротно видаляється. Це принципово відрізняється від централізованих месенджерів, де повідомлення зберігаються місяцями.

Вектори атак, специфічні для mesh

Децентралізовані мережі мають власні проблеми безпеки: Sybil-атаки — зловмисник створює кілька фіктивних ідентичностей у мережі; Mesh Poisoning — скомпрометовані вузли порушують маршрутизацію. Обидва вектори є реальними для Bitchat і додаються до вже відомої вразливості impersonation.

Panic mode: екстрене знищення даних

Bitchat має вбудований panic mode: потрійний тап на логотип — миттєве стирання всіх локальних даних (повідомлень, ключів, кешу, ідентичності). Призначений для екстремальних сценаріїв: затримання на протесті, примусова перевірка пристрою на кордоні. Дія незворотна і не потребує підтвердження.

MAC-адреса: прихована, але не невидима

Попри те що Bitchat не вимагає особистих даних, пристрої залишаються ідентифікованими за своїми Bluetooth MAC-адресами. iOS і Android рандомізують MAC при скануванні, але не завжди при підключенні. Це означає: локальний спостерігач з BLE-сканером може фіксувати присутність конкретного пристрою в мережі, навіть не читаючи зміст повідомлень.

• ⚠️ Батарея: ~40% швидше при повній активності — три режими для балансу
• ⚠️ Cold start: ефективний лише при достатній щільності користувачів
• ⚠️ MAC-адреса видима для локального BLE-сканера
• ⚠️ Sybil-атаки і Mesh Poisoning — реальні вектори без аудиту
• ✔️ Panic mode: потрійний тап — необоротне знищення всіх даних
• ✔️ Адаптивний duty cycle: 100 / 500 / 2000 мс для балансу батареї і покриття

Висновок: BLE mesh у Bitchat має конкретні, вимірювані обмеження — не абстрактні «мінуси», а технічні межі протоколу. Знаючи їх, можна правильно вибрати сценарій використання.

💼 Де peer-to-peer mesh має перевагу над client-server

Централізований месенджер настільки ж надійний, наскільки надійний його сервер. Mesh-месенджер настільки ж надійний, наскільки надійна людська щільність навколо вас.

Відсутність єдиної точки відмови

У client-server архітектурі сервер — єдина точка відмови: DDoS, технічна аварія, відключення електроенергії в ЦОД — і зв'язок зникає для всіх одночасно. У mesh-мережі такої точки немає: мережа продовжує функціонувати, поки існують хоча б два активних вузли поруч. Під час урагану Melissa на Ямайці у жовтні 2025 інтернет-підключення впало до 30% від норми — Bitchat став другим за популярністю застосунком в App Store країни, продовжуючи працювати саме тоді, коли централізовані сервіси відмовили.

Стійкість до цензури — з реальними цифрами

Заблокувати централізований месенджер просто: достатньо зобов'язати провайдерів заблокувати IP-адреси серверів. Заблокувати Bluetooth-трафік між пристроями в радіусі 100 м — технічно неможливо без глушіння всього радіоспектру.

Реальні кейси підтверджують цю тезу на практиці:

Загальна кількість завантажень Bitchat перевищила 1 мільйон станом на початок 2026 року.

⚠️ Важливе застереження: BLE не означає повна анонімність

Попри децентралізований дизайн, експерти попереджають: BLE-мережі генерують метадані. Навіть якщо вміст повідомлень зашифрований, досвідчені служби спостереження можуть відстежувати, які пристрої комунікують, коли і в яких патернах. Професор Алан Вудворд з Університету Суррея зазначив це у коментарі BBC. Крім того, існує ризик компрометованих форків, фішингу і юридичного тиску як державних контрзаходів.

Ключовий фактор ефективності mesh-мережі — не технічна досконалість, а кількість учасників: «Коли є 50 000 людей у Непалі зі своїми телефонами — це може бути реальна цензуростійка мережа», — коментують аналітики Blockspace. Мережевий ефект тут важливіший за криптографію.

Приватність за замовчуванням — і її межі

Централізовані месенджери збирають метадані навіть при E2EE: з ким, коли, як часто, з яких IP. У Bitchat центрального сховища метаданих не існує фізично — немає сервера, якому їх передавати. Але це не означає повної анонімності: BLE-активність пристрою видима локально для будь-якого обладнання, що сканує ефір.

Offline-first архітектура і «location notes»

Bitchat спроектований за принципом offline-first: базовий функціонал доступний без інтернету, інтернет — лише розширення. Під час урагану Melissa на Ямайці функція «location notes» — прикріплення повідомлень до географічних точок — використовувалась для позначення безпечних зон і центрів евакуації. Це приклад того, як технічна можливість стає критичною інфраструктурою у кризових умовах.

• ✔️ Немає єдиної точки відмови — мережа живе без сервера
• ✔️ Цензуростійкість — BLE-трафік не блокується на рівні DNS або IP
• ✔️ Реальні кейси: Nepal, Madagascar, Jamaica, Iran, Uganda, Indonesia
• ✔️ 1+ млн завантажень; пік — 438 000/тиждень під час блокади в Ірані
• ✔️ Offline-first + location notes для позначення безпечних зон
• ⚠️ BLE генерує метадані — не замінює повну анонімність
• ⚠️ Ефективність залежить від щільності користувачів, а не лише від криптографії

Висновок розділу: P2P mesh вирішує задачі, які централізована архітектура фізично не може вирішити — і шість реальних кейсів за пів року це підтверджують. Але це інструмент з обмеженнями, а не срібна куля.

Хочете побачити, як Bitchat порівнюється з іншими mesh-рішеннями — Briar і Meshtastic? Читайте третю статтю серії: Bitchat, Briar і Meshtastic: три підходи до mesh-комунікацій без інтернету →

❓ Часті питання (FAQ)

Чим BLE mesh відрізняється від звичайного Bluetooth-з'єднання?

Звичайний Bluetooth з'єднує два пристрої напряму (1-to-1). BLE mesh — це мережа, де кожен пристрій ретранслює дані далі (many-to-many), формуючи розподілену топологію без центрального вузла.

Що таке Noise Protocol і чому Bitchat використовує саме його?

Noise Protocol Framework — перевірений криптографічний стандарт для побудови захищених каналів зв'язку, який також використовують Signal і WireGuard. Він підходить для P2P-середовища без центрального сервера автентифікації, що критично для архітектури Bitchat.

Що таке вразливість impersonation у Bitchat?

Impersonation означає, що зловмисник може видавати себе за іншого користувача в мережі. Причина — відсутність надійної децентралізованої верифікації публічних ключів. Проблема визнана Дорсі, виправлення не випущено, аудит не проводився.

Чи шифруються групові чати?

Групові чати (hashtag-кімнати) захищені паролем, але не мають повноцінного E2EE у поточній реалізації. End-to-end шифрування реалізоване лише для direct messages між двома користувачами.

Що таке panic mode і коли його використовувати?

Panic mode — функція екстреного знищення всіх локальних даних: потрійний тап на логотип застосунку миттєво видаляє повідомлення, ключі і кеш. Призначений для ситуацій фізичної загрози: затримання, примусова перевірка пристрою. Дія незворотна.

Чи може Bitchat передавати фото або файли?

У поточній версії — ні. BLE має обмежений throughput (кілька сотень Кбіт/с), що унеможливлює передачу медіафайлів. Bitchat у поточній реалізації підтримує лише текстові повідомлення.

Як Nostr-fallback знає, що переключитись на інтернет?

Застосунок автоматично визначає наявність інтернет-з'єднання. Якщо воно є на будь-якому вузлі мережі — цей вузол може використати Nostr як міст. Переключення прозоре для користувача, BLE залишається пріоритетним транспортом.

✅ Висновки

• 🔹 Архітектура: гібридна P2P — BLE mesh (основний) + Nostr (fallback при наявності інтернету)
• 🔹 Routing: hop-to-hop між вузлами; дальність до ~300 м через ланцюжок пристроїв
• 🔹 Доставка: store-and-forward — кешування до 12 годин на сусідніх вузлах
• 🔹 Шифрування: Noise Protocol Framework, E2EE для DM, ephemeral keys
• 🔹 Identity: публічний ключ замість акаунта — без реєстрації
• 🔹 Вразливість: impersonation — зовнішній аудит не проводився, не для продакшну
• 🔹 Обмеження: лише текст, деградує при низькій щільності вузлів, кеш 12 год
• 🔹 Panic mode: потрійний тап — миттєве знищення всіх даних

Головна думка: Bitchat — технічно цікавий гібридний P2P-месенджер із солідною криптографічною базою, але ранньою стадією зрілості: відсутність аудиту і вразливість impersonation роблять його інструментом для специфічних сценаріїв, а не для щоденного використання.

Перша стаття серії — для тих, хто ще не знайомий із проектом: Bitchat: офлайн-месенджер на Bluetooth без сервера →