dchain/CONTEXT.md

Decentralized Messenger — Project Context for Claude Code

Этот файл содержит полный контекст проекта из чата. Передай его в Claude Code командой: claude --context CONTEXT.md или просто открой в проекте и Claude Code подхватит его автоматически через CLAUDE.md

---

Суть проекта

Полностью децентрализованный мессенджер с функциональностью уровня Telegram/ВКонтакте.

• Никакого центрального сервера
• Блокчейн как регулятор сети (не транспорт)
• Кастомный протокол с маскировкой трафика
• E2E шифрование верифицированное через блокчейн

---

Архитектура: четыре слоя

Слой 1 — Идентичность (L1 блокчейн)

Хранит только редкие важные события:

• Регистрация keypair (Ed25519) — раз в жизни
• Создание канала/чата — владелец и метаданные
• Изменение прав участников
• Открытие/закрытие платёжных state channels

Тела сообщений НИКОГДА не попадают в блокчейн.

Слой 2 — Транспорт (relay-ноды)

• DHT маршрутизация (как BitTorrent) — нет центрального роутера
• Onion routing — каждый узел видит только следующий хоп
• Маскировка трафика — имитация HTTPS/QUIC или BitTorrent uTP
• Офлайн-буфер — зашифрованные конверты TTL 30 дней
• Proof of Relay — криптодоказательство честной доставки

Слой 3 — Хранение

• IPFS / Arweave — медиафайлы (content-addressed)
• Relay-кэш — горячая история, последние N сообщений
• Локальная зашифрованная БД (SQLite + NaCl) на устройстве
• Блокчейн — только хэши событий

Слой 4 — Приложение

Личные сообщения, группы, каналы, звонки (WebRTC P2P), сторис, посты, боты

---

Блокчейн: детали

Консенсус — PBFT (Tendermint-style)

• Финальность: 1–3 секунды
• Три фазы: Pre-prepare → Prepare → Commit
• Кворум: 2/3 валидаторов
• Валидаторы = операторы крупных relay-нод

Структура блока (Go)

type Block struct {
    Index        uint64
    Timestamp    time.Time
    Transactions []*Transaction
    PrevHash     []byte
    Hash         []byte  // SHA-256
    ValidatorSig []byte  // Ed25519
    Validator    string  // pub_key валидатора
}

type Transaction struct {
    ID        string
    Type      EventType  // REGISTER_KEY | CREATE_CHANNEL | ADD_MEMBER | OPEN_PAY_CHAN ...
    From      string     // pub_key отправителя
    To        string     // pub_key получателя (если есть)
    Payload   []byte     // json с данными события
    Signature []byte     // Ed25519 подпись From
    Timestamp time.Time
}

Хранение блоков

• Light nodes для мобильных клиентов (только заголовки)
• Sharding для валидаторов (каждый хранит свой шард)

---

Формат сообщений и постов

Личное сообщение — конверт

type Envelope struct {
    To         []byte // pub_key получателя (для маршрутизации relay)
    Nonce      []byte // 24 случайных байта (anti-replay)
    Ciphertext []byte // NaCl box: зашифровано pub_bob + priv_alice
    SentAt     int64  // unix timestamp (внутри шифра, снаружи не видно)
}

Relay видит только To. Всё остальное — непрозрачный blob.

Поток доставки:

1. Alice шифрует конверт pub_key Боба
2. Отправляет на свою relay-ноду (P2P)
3. Relay ищет Bob по DHT и доставляет (<50мс если онлайн)
4. Если офлайн — хранит конверт TTL 30 дней
5. Bob расшифровывает своим priv_key

Пост в канале

type Post struct {
    ChannelID   string
    SeqNum      uint64 // монотонно растёт — клиент знает что пропустил
    ContentHash []byte // sha256 тела = IPFS CID
    AuthorSig   []byte // подпись канала
    Timestamp   int64
    // Тело поста хранится в IPFS по ContentHash, не здесь
}

Поток публикации:

1. Автор создаёт Post, подписывает, загружает тело в IPFS
2. Relay-нода анонсирует через gossip-протокол: "в канале X пост #N"
3. Волна расходится по DHT к подписчикам
4. Клиент проверяет: sig автора → pub_key из блокчейна → sha256(тело) == ContentHash
5. Тело подгружается из IPFS лениво (lazy loading)

Офлайн-синхронизация через seq_num: клиент хранит последний прочитанный номер, при подключении запрашивает пропущенные у relay.

---

Экономика

Три механизма

1. State Channels — микроплатежи без газа на каждое действие (как Lightning Network)
2. Proof of Relay — нода зарабатывает токены за доказанную доставку сообщений
3. Delegated Staking — делегировать токены ноде оператора без своего сервера

Источники токенов

• Стартовый грант при регистрации
• PoW при создании keypair (CPU-барьер против Sybil)
• Лёгкая нода на телефоне (relay для соседей пока на зарядке)

---

Безопасность

E2E шифрование

• Signal Protocol (Double Ratchet) или Noise Protocol
• Sender Keys для групп — один симметричный ключ на группу
• Блокчейн решает проблему TOFU (верификация pub_key)

Защита метаданных

• Onion routing — relay не знает реального отправителя
• Sealed sender — сервер видит только получателя
• Маскировка трафика — QUIC / obfs4 / domain fronting

Sybil-защита

• PoW при регистрации
• Социальный граф — новый аккаунт без контактов имеет ограниченные права

---

Технический стек

Компонент	Библиотека	Причина
Блокчейн	Cosmos SDK / Tendermint	Лучший PBFT на Go
P2P сеть	go-libp2p	Используется IPFS и Ethereum
БД блоков	BadgerDB	Go-native key-value
Криптография	crypto/ed25519 (stdlib)	В стандартной библиотеке
E2E шифрование	golang.org/x/crypto/nacl	NaCl/box
gRPC API	google.golang.org/grpc	Стандарт для Go
Relay протокол	кастомный поверх QUIC	Контроль маскировки

---

Структура репозитория (планируемая)

/
├── blockchain/
│   ├── block.go        # структура блока, хэширование, валидация
│   ├── chain.go        # хранилище, state machine
│   └── types.go        # Transaction, EventType и т.д.
├── consensus/
│   └── pbft.go         # PBFT: Pre-prepare → Prepare → Commit
├── identity/
│   └── identity.go     # keypair Ed25519, подпись, верификация
├── relay/
│   ├── node.go         # relay-нода: маршрутизация конвертов
│   ├── dht.go          # DHT для discovery нод
│   └── buffer.go       # офлайн-буфер с TTL
├── messaging/
│   ├── envelope.go     # личные сообщения (NaCl box)
│   └── channel.go      # посты в каналах (IPFS + gossip)
├── crypto/
│   ├── nacl.go         # обёртки над NaCl box/secretbox
│   └── shamir.go       # Shamir's Secret Sharing для recovery ключей
└── cmd/
    ├── node/           # relay-нода (сервер)
    └── client/         # CLI клиент для тестирования

---

Уже написанный код (в outputs/)

• blockchain/block.go — Block, Transaction, GenesisBlock, ComputeHash, Validate
• blockchain/chain.go — Chain, AddBlock, applyTx, state (identities, channels)
• consensus/consensus.go — Node, HandleMessage, PBFT фазы, broadcast
• identity/identity.go — Generate, RegisterTx, SignMessage, VerifyMessage
• main.go — пример запуска, simulateBlockProduction, simulateMessageFlow

---

Следующие приоритеты для разработки

1. Заменить in-memory map в chain.go на BadgerDB
2. Добавить go-libp2p для P2P между нодами
3. Реализовать DHT для discovery и маршрутизации
4. Написать relay/node.go с буфером конвертов
5. Написать messaging/envelope.go с NaCl шифрованием
6. View-change протокол в PBFT (смена лидера при падении)

---

Аналоги для изучения

• Nostr — минималистичный протокол, Lightning для relay
• Tendermint — лучший PBFT на Go, изучить view-change
• go-libp2p — P2P стек
• Status.im — мессенджер на Ethereum, токен SNT
• lnd — Lightning Network на Go (state channels)