Разработка децентрализованного мессенджера
Главный вопрос при проектировании децентрализованного мессенджера — что именно децентрализовано? Хранение сообщений? Маршрутизация? Identity? Шифрование? Мы разрабатываем децентрализованные мессенджеры, в которых каждый слой действительно децентрализован, а не маскируется блокчейн-обёрткой. Честная архитектура требует явного выбора trade-offs на каждом уровне. Наши инженеры с 10-летним опытом в Web3 помогают найти правильный баланс. Более 90% проектов в этой области страдают от неверных предположений — например, используют блокчейн для хранения сообщений, что делает их дорогими и медленными. Мы исправляем это, применяя гибридную схему.
Какие задачи решает децентрализованный мессенджер?
Основная задача — дать пользователям контроль над данными и коммуникациями без посредников. Это критично для конфиденциальных переписок, DAO-сообществ, децентрализованных бирж и игр. Кроме того, децентрализованные мессенджеры устойчивы к цензуре и блокировкам.
Протокольный стек: транспорт, идентификация, шифрование
Transport layer — разработка децентрализованного мессенджера
XMTP (Extensible Message Transport Protocol) — de facto стандарт для Web3 мессенджеров на текущий момент. Поверх Waku (libp2p-based messaging network). Сообщения хранятся на XMTP нодах (федерированная сеть), идентификация — Ethereum адрес, шифрование — Double Ratchet (как в Signal).
import { Client } from '@xmtp/xmtp-js'; import { Wallet } from 'ethers'; // Создание XMTP идентификатора (подпись кошельком) const xmtpClient = await Client.create(signer, { env: 'production' }); // Проверка: зарегистрирован ли адрес в XMTP const isOnNetwork = await Client.canMessage(recipientAddress); // Создание или открытие conversation const conversation = await xmtpClient.conversations.newConversation(recipientAddress); // Отправка сообщения await conversation.send('Hello from Web3'); // Получение истории const messages = await conversation.messages({ limit: 50 }); // Streaming новых сообщений for await (const message of await conversation.streamMessages()) { console.log(`${message.senderAddress}: ${message.content}`); } Преимущество XMTP: готовая E2E шифрование, cross-app (сообщения работают между разными dApp на базе XMTP: Coinbase Wallet, Converse, Lens), не нужно строить p2p инфраструктуру.
Идентификация и управление ключами
XMTP привязывает идентификатор к Ethereum адресу автоматически. При standalone подходе нужна схема key derivation. Определяем ключи через HKDF из подписи детерминированного сообщения:
async function deriveMessagingKeys(signer: ethers.Signer): Promise<{ identityKey: Uint8Array; preKey: Uint8Array; }> { const message = 'MyMessenger Identity Key v1\n\nThis key is used for encrypted messaging.\nSign to generate your keys.'; const signature = await signer.signMessage(message); const keyMaterial = await crypto.subtle.importKey('raw', hexToBytes(signature), 'HKDF', false, ['deriveKey', 'deriveBits']); const identityKeyBits = await crypto.subtle.deriveBits( { name: 'HKDF', hash: 'SHA-256', salt: new Uint8Array(32), info: new TextEncoder().encode('identity-key') }, keyMaterial, 256 ); const preKeyBits = await crypto.subtle.deriveBits( { name: 'HKDF', hash: 'SHA-256', salt: new Uint8Array(32), info: new TextEncoder().encode('pre-key') }, keyMaterial, 256 ); return { identityKey: new Uint8Array(identityKeyBits), preKey: new Uint8Array(preKeyBits) }; } Важно: если пользователь меняет кошелёк — он теряет ключи. Backup механизм критичен.
Шифрование сообщений
Пример ECDH + AES-GCM
async function encryptMessage( plaintext: string, senderPrivateKey: Uint8Array, recipientPublicKey: Uint8Array ): Promise<{ ciphertext: Uint8Array; nonce: Uint8Array }> { const sharedSecret = await performECDH(senderPrivateKey, recipientPublicKey); const encryptionKey = await crypto.subtle.importKey( 'raw', sharedSecret, { name: 'AES-GCM' }, false, ['encrypt'] ); const nonce = crypto.getRandomValues(new Uint8Array(12)); const ciphertext = await crypto.subtle.encrypt( { name: 'AES-GCM', iv: nonce }, encryptionKey, new TextEncoder().encode(plaintext) ); return { ciphertext: new Uint8Array(ciphertext), nonce }; } Для группового чата — симметричный ключ группы, зашифрованный публичными ключами каждого участника (sealed sender модель).
Forward secrecy через Double Ratchet
Статичный ECDH ключ — слабость: компрометация ключа раскрывает всю историю. Double Ratchet решает это: каждое сообщение шифруется новым эфемерным ключом. XMTP реализует его внутренне — это одна из причин выбирать его вместо самостоятельной реализации.
Как выбрать протокол передачи: XMTP или Waku?
| Критерий | XMTP | Waku (standalone) |
|---|---|---|
| E2E шифрование | Встроенное (Double Ratchet) | Требуется реализация |
| Cross-app | Да (общая сеть) | Нет |
| Групповые чаты | MLS v3 (нативные) | Требуется реализация |
| Сложность интеграции | Низкая (SDK) | Высокая (настройка нод) |
| Контроль над инфраструктурой | Федерированная | Полный |
XMTP лучше для быстрой интеграции и совместимости. Waku — для полного контроля и кастомной маршрутизации.
Хранение, уведомления и групповая архитектура
Как хранить сообщения?
Проблема: блокчейн дорог. Варианты:
| Хранилище | Децентрализация | Стоимость | Скорость |
|---|---|---|---|
| XMTP nodes | Федерированная | Бесплатно | ~200ms |
| IPFS + Filecoin | Высокая | ~$0.01/GB/месяц | 1-5 сек |
| Ceramic/ComposeDB | Высокая | Бесплатно (light) | ~500ms |
| Arweave | Максимальная | ~$0.005/MB разово | 2-30 сек |
| Собственный сервер | Нет | Дёшево | <50ms |
Для реального UX — гибридная схема: сообщения в XMTP/Waku (fast, p2p), архивные — в IPFS с Filecoin pinning.
Push уведомления
Waku и XMTP не имеют нативного push. Для мобильных уведомлений нужен PUSH service. XMTP поддерживает Push через @xmtp/react-native-sdk + XMTP push service (можно self-host). Для web: Service Worker + Web Push API.
Групповые чаты
XMTP v3 (MLS — Messaging Layer Security) добавляет нативные группы с E2E шифрованием и forward secrecy для всей группы. Управление membership требует обновления группового ключа при каждом изменении состава.
// XMTP v3 Group API const group = await xmtpClient.conversations.newGroup([member1, member2, member3]); await group.send('Hello group'); await group.addMembers([newMemberAddress]); On-chain компонент: что стоит хранить в блокчейне
Разумно on-chain только:
- Публичные ключи (identity registration) — один раз
- Group registry (если публичные группы)
- Token-gated access — проверка владения NFT/токенами для входа в group chat
ENS интеграция: резолвить name.eth → адрес → XMTP проверка через canMessage.
Структура фронтенда
src/ components/ ConversationList/ MessageThread/ MessageInput/ ContactSearch/ hooks/ useXmtpClient useConversations useMessages stores/ React Query + Zustand для кэширования. Сообщения кэшируются локально (IndexedDB), streaming добавляет новые без перезагрузки.
Ориентиры по срокам разработки
XMTP-based мессенджер (1-на-1 чаты, ENS резолвинг, базовый UI) — 2-3 недели. Групповые чаты (MLS v3), push уведомления, token-gated rooms — ещё 2-3 недели. Полноценный продукт с file sharing, read receipts, mobile-адаптацией — 2-3 месяца.
Что входит в работу
- Анализ архитектуры: выбор протокола (XMTP/Waku), определение уровней децентрализации.
- Реализация бэкенда: настройка XMTP нод или Waku relay, интеграция с IPFS.
- Интеграция с кошельками: MetaMask, WalletConnect, Phantom (Solana).
- Шифрование и управление ключами: Double Ratchet, backup seed.
- Фронтенд: React для web, React Native для mobile, адаптивный UI.
- Развертывание и тестирование: смарт-контракты (если нужно), аудит безопасности (Tenderly, Slither).
- Документация и обучение: передача репозитория, readme, обучение вашей команды.
Почему стоит доверить разработку нам?
- 5 лет на рынке децентрализованных технологий.
- Более 15 Web3-проектов в портфолио, включая DeFi и NFT маркетплейсы.
- Инженеры с сертификатами Matter Labs и Ethereum Foundation.
- Мы гарантируем работу по спецификации и исправляем bugs в течение гарантийного срока.
Свяжитесь с нами для консультации — поможем выбрать архитектуру под ваш бюджет. Закажите разработку MVP за 2-3 недели.