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)
```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 для валидаторов (каждый хранит свой шард)

---

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

### Личное сообщение — конверт
```go
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

### Пост в канале
```go
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)