Kontinuum Node — Architecture
Версия спецификации: v0.6 · Статус: скелет / pre-implementation · Последнее обновление: 2026-05-18
Audience: все — start here. Overview-level документ: концепции, tier model, capability matrix, network topology, workspace layout, scalability strategy, open questions, roadmap.
Связанные документы:
protocols.md— DHT model, inter-node wire protocol, mailbox protocol (для node devs)app-integration.md— client-side flows: identity, pairing, recovery, PRO model (для app devs)operations.md— storage layer, replication, cert lifecycle, admin surfaces, threat model, DR planpricing.md— tariff modelimplementation-notes.md— known edge-cases для implementation phase
Section codes (§1, §3, …) сохранены от единой v0.6 спеки — cross-references между документами идут по этим кодам.
1. Назначение
Kontinuum Node — серверный узел распределённой P2P-сети, на которой держится:
- Discovery — глобальный directory identity-записей пользователей
kontinuum-app. - Storage — хостинг пользовательского контента (E2E-зашифрованного), который не помещается на личных устройствах или должен быть доступен оффлайн-получателю.
- Routing — NAT-traversal через circuit-relay-v2 для большинства мобильных и домашних пиров.
- Mailbox — store-and-forward для
SharingMessage, доставляемых оффлайн-получателям. - Rendezvous — opt-in cross-network device-discovery без долгоживущей публикации в DHT.
- Federation — узлы образуют единую сеть, удерживающую DHT и опубликованный контент.
Нода никогда не видит plaintext пользовательских данных — оперирует только зашифрованными blob'ами и подписанными метаданными.
2. Глоссарий
| Термин | Определение |
|---|---|
| Node | Серверный процесс kontinuum-node, имеющий persistent Ed25519 identity и подключённый к сети. |
| Tier | Уровень доверия (0–2). Не путать с Capability. |
| Capability | Конкретная функция, которую нода предоставляет: dht_routing, relay, storage, mailbox, s3_gateway, anti_entropy, rendezvous. Ортогонально tier'у. |
| Tenancy | Кому принадлежат ресурсы ноды: multi (хостер делит между N клиентами / family-team) или single (одной identity). |
| Operator | Кто физически держит инфру: org, byo:vps, byo:home. |
| Identity | Ed25519 keypair конечного пользователя; identity_id = blake3(pubkey). |
| Space | Унифицированный namespace для контента и DHT. Personal Space, Shared Space, Direct Space — варианты одного примитива. |
| Personal Space | Auto-created space с membership = только устройства owner'а. Контейнер metadata identity + multi-device sync. |
| Shared Space | User-created space с membership = owner + invited identities. |
| Direct Space | Shared Space с двумя членами (1:1 чат). |
| Space DHT | Kademlia-namespace конкретного Space с курируемой membership и шифрованием по space-key. |
| Global DHT | Единственный публичный Kademlia-overlay; узнают друг о друге все участники сети. |
| Mailbox | Append-only log сообщений SharingMessage для конкретного identity_id. |
| Cert | Подписанный Tier 0 документ, удостоверяющий tier/tenancy/capacity ноды. |
| CRL | Certificate Revocation List — подписанный Tier 0 список node_id с отозванными cert'ами. |
| Rendezvous endpoint | In-memory map с TTL для transient device-presence; opt-in cross-network discovery. |
| Vault backup | Encrypted-vault snapshot, реплицируемый на оплаченную инфраструктуру владельца. |
| Virtual S3 Pool | Логическое объединение всех S3-источников владельца (relay-free + paid + external) в один pool для placement. |
| Pin | User-flag на конкретный blob/space — гарантирует копию в собственном storage владельца. |
| byo | Bring Your Own (infrastructure) — оператор-сценарий, в котором PRO-пользователь привёл свою инфру. Подвиды: byo:vps, byo:home. |
3. Tier'ы доверия и capabilities
3.1 Tier'ы
| Tier | Назначение | Operator | Sybil-cost |
|---|---|---|---|
| 0 Anchor | Cert issuance, CRL, identity-arbiter, bootstrap | только org | ручной onboarding |
| 1 Billed | Координация, mailbox, кэш, S3-gateway, опциональный storage | org | fiat-платёж → cert |
| 2 Community | PRO-attached (VPS или home server) | byo:vps / byo:home | PRO app-subscription |
3.2 Capabilities (ортогонально)
Каждая нода декларирует свой capability-set в node:{node_id} записи. Включаются/выключаются владельцем (с ограничениями):
| Capability | Что делает | Обязательно для |
|---|---|---|
dht_routing | Участие в global DHT routing | Все Tier 0/1/2 (неотключаемо) |
relay | Circuit-relay-v2 для NAT-traversal | — (opt-in) |
storage | Хостинг blob'ов | — (Tier 1 default ON; Tier 2 default ON) |
mailbox | Store-and-forward mailbox | — (Tier 1/2 default ON, scope зависит от tenancy) |
s3_gateway | rustfs S3-compatible endpoint | — (Tier 1/2 default ON для own + shared tenants) |
anti_entropy | Merkle-tree gossip reconciliation | Tier 1 default ON |
rendezvous | Transient presence endpoint | Tier 0 default ON; Tier 1 default ON; Tier 2 default OFF |
3.3 Sub-flavors
Tier × (operator, tenancy):
| Tier | operator × tenancy | Кейс |
|---|---|---|
| 1 | org × multi | Базовый cloud-tier — org держит инфру, делит между N клиентов |
| 1 | org × single | Premium «выделенная нода у нас» — ресурс резервирован под одну identity |
| 2 | byo:vps × single | PRO купил VPS у внешнего хостера (Hetzner / DO / Linode) |
| 2 | byo:vps × multi | PRO купил VPS + расшарил family/team (whitelisted identities) |
| 2 | byo:home × single | PRO держит на домашнем NAS / mini-PC |
| 2 | byo:home × multi | PRO домашний сервер + family-режим |
Tier 4 «personal cluster» из v0.1 — это byo:home × single с флагом community_disabled = true, не отдельный tier.
3.4 Карта user-experience
| Состояние пользователя | Что в сети получает |
|---|---|
| Free app, без покупок | mDNS LAN-sync + opt-in rendezvous (только discovery, без offline) |
| Free app + куплен relay-node (Standard) | + Tier 1 functionality: cross-network sync, mailbox, Personal Space DHT, free S3 в пределах свободного места ноды |
| Free app + куплен S3-bucket у org | + дополнительный S3 в Virtual Pool (отдельный SKU, GB-month + egress) |
| PRO app + attached VPS / home server | Tier 2 self-hosted; собственная инфра, своя Personal Space |
| PRO app + attached external S3 (Backblaze / R2 / AWS) | + external S3 в Virtual Pool, прямой billing провайдеру |
| PRO app + family-mode | + share своей VPS/home-node с whitelisted identities; tenants ничего не платят |
| Free / Standard user, invited в family-mode чужого PRO | Получает Standard-уровень функциональности (mailbox, cross-network sync, Personal Space DHT) на host-ноде PRO-владельца в пределах квоты, выданной owner'ом. Биллинговых отношений с org нет. |
4. Топология сети
┌──────────────┐
│ Tier 0 ×N │ hardcoded pubkeys в коде клиентов и нод
│ Anchor │
└──────┬───────┘
│ cert issuance, CRL
┌──────────────┼──────────────────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Tier 1 │ │ Tier 1 │ ... │ Tier 1 │
│ org × multi │ │ org × single │ │ org × ... │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
└────────────────┼────────────────────────┘
│ global Kademlia DHT
│
┌─────┴─────┐
▼ ▼
┌──────────┐ ┌──────────┐
│ Tier 2 │ │ Tier 2 │ byo:vps / byo:home
│ PRO │ │ PRO │ single или multi (family)
└──────────┘ └──────────┘
│
┌───────┴───────┐
│ kontinuum-app │ (мобильные/десктопные клиенты)
└───────────────┘Каждый Tier 1/2 узел дополнительно держит Space DHT shards для тех Spaces, где owner физически хостит шард на этой ноде, и shared-space replicas для Spaces, в которых владелец active member.
17. Раскладка workspace
kontinuum-node/
├── Cargo.toml # workspace: server, admin
├── README.md # ← этот файл
├── server/ # main node daemon
│ ├── Cargo.toml
│ ├── project.json # Nx config
│ └── src/
│ ├── main.rs
│ ├── lib.rs
│ ├── config.rs
│ ├── state.rs
│ ├── dht/ # управление global + space DHT
│ ├── storage/ # rustfs embed + auth shim + virtual pool
│ ├── mailbox/ # mailbox + cursors + GC
│ ├── replication/ # размещение реплик + repair + pins
│ ├── anti_entropy/ # Merkle gossip
│ ├── challenge/ # PoS challenges (верификация Tier 2)
│ ├── cert/ # жизненный цикл cert'a
│ ├── rendezvous/ # rendezvous endpoint
│ └── observability/ # prometheus metrics export
├── admin/ # control-plane (Tier 0 helper)
│ ├── Cargo.toml
│ ├── project.json
│ └── src/
│ ├── main.rs
│ ├── rest_api.rs
│ ├── operator_bot.rs # platform-agnostic operator chat bot interface
│ └── billing_integration.rs
├── deploy/
│ ├── grafana/ # dashboards JSON
│ ├── directus/ # config + collections
│ ├── prometheus/ # scrape config
│ └── docker-compose.yml # local dev stack (TBD)
└── scripts/
kontinuum-core/src/node/ # общий inter-node protocol
├── mod.rs
├── wire.rs # типы inter-node Frame (§11)
├── cert.rs # формат Tier 0 cert + валидация
├── dht_id.rs # DhtId / namespace типы
├── merkle.rs # примитивы anti-entropy
├── challenge.rs # PoS примитивы
└── identity.rs # node identity + signingCustom Vue3 frontend убран (см. §15.1 — заменён Grafana + Directus + operator chat bot).
Stack: Rust + TypeScript (TypeScript только для Directus extensions / dashboards JSON) — последовательно со stack-rule проекта.
18. Масштабируемость
18.1 Сравнение с centralized chat-системами
| Аспект | Telegram | Kontinuum | |
|---|---|---|---|
| MAU (2025) | ~900M | ~2.5B | TBD |
| Архитектура | Centralized (MTProto, DCs) | Centralized (Erlang, RabbitMQ) | Decentralized P2P |
| Throughput core | ~1M msg/sec global (DC-based) | ~100M msg/day routed | Per-Tier-1 ~1K ops/sec; ×N нод в сети |
| Outage risk | Полный outage при падении DC | Полный outage | Гранулярная — outage только тех Spaces, чьи владельцы на упавших нодах |
| Discovery scale | Server-side index | Phone-number index | Kademlia DHT (BitTorrent proven до ~150M concurrent peers) |
| Censorship resistance | Блокируется gov-level | Блокируется | E2E + cross-provider / cross-region → значительно устойчивее |
| Cost scaling | Capital-intensive (DCs) | Capital-intensive | Operational cost растёт с users (каждый PRO/Standard приносит свою инфру) |
18.2 Архитектурные узкие места Kontinuum
Tier 0 throughput. Cert issuance ограничен ~5–10 anchor нодами. При 100K новых пользователей/день и cert valid 30 дней — устойчивый rate ~3K issue/sec. Решение: batch-cert (1 cert на N nodes) или horizontal scale Tier 0 до 100 anchor нод.
Global DHT pollution. При 1B opted-in identities в одном keyspace — re-publish overhead ~12K writes/sec только под identity refresh. Решение: sharding по identity_id prefix (см. §18.3).
Tier 0 governance. Multi-sig для critical operations может стать bottleneck'ом при росте. Возможно потребуется federated multi-sig с regional sub-anchors.
18.3 Future scaling: sharded DHT (v2.0 milestone)
При 100M+ пользователей global DHT может быть зашардён.
Trigger conditions (мониторим в production):
records_in_global_dht > 10M(объективный, измеримый), ANDlookup_p99_latency > 2 secстабильно 7 consecutive days
Combined trigger обеспечивает что переход начинается реактивно при реальной деградации, а не превентивно «на будущее».
Approach: prefix-based, m = 8 (256 sub-overlays).
- Keyspace делится по первым
m = 8битамidentity_id→ 2^8 = 256 sub-DHTs. - Каждый sub-overlay отвечает за
1/256keyspace. - Нода участвует только в назначенных sub-overlays (на основе capacity / geo / random assignment Tier 0).
- Lookup: client определяет sub-overlay по prefix → ищет в нём.
- Эффекты: меньший keyspace per overlay → шустрее lookup, меньше memory, ниже write traffic.
- Tier 0 ноды остаются inter-shard bridges.
Migration strategy (4 phases, ~6 месяцев total):
| Phase | Длительность | Что происходит |
|---|---|---|
| 0 | T+0 | Trigger conditions met → governance announces sharding |
| 1 | 1 месяц | Tier 0 ноды starts publishing sub-overlay routing hints в global DHT |
| 2 | 2 месяца | Новые publishes идут в правильный sub-overlay; existing — dual-write (single + shard) |
| 3 | 2 месяца | Existing records gradually мигрируют через anti-entropy в sub-overlays |
| 4 | 1 месяц | Drop single-overlay reads; sub-overlays — primary |
До completion (~6 месяцев) — оба режима работают (dual-write, eventual single-read).
Альтернатива (геошардинг) рассмотрена но отложена: identity-stub публикуется в local geo-zone overlay, cross-region lookup через Tier 0 bridges. Проще imp, но усложняет cross-region pairing/recovery flows. Prefix-based — primary plan, геошардинг — фолбэк если prefix не масштабируется.
Это v2.0 milestone — не для v1.0 launch. Текущая v1.0 архитектура рассчитана на ≤ 10M идентичностей в одном overlay.
18.4 Realistic numbers
- 10K пользователей — current architecture handles easily, ~50 Tier 1 нод, ~1K Tier 2.
- 1M пользователей — handled by 5K Tier 1 + 50K Tier 2 (typical 1:10 ratio). Tier 0 нужно scaling до 20+ anchor нод.
- 100M пользователей — требует sharded DHT (§18.3) и federated Tier 0.
- 1B пользователей — теоретически возможно, но требует engineering работы. На уровне современных centralized chat'ов по абсолютным числам, при сохранении децентрализованного характера.
19. Открытые вопросы
Большинство вопросов из v0.5 разрешено в v0.6 — см. соответствующие секции (см. roadmap снизу). Остающиеся:
Архитектурные — v2.0 milestones
- Sharded DHT implementation — design зафиксирован в §18.3 (prefix-based m=8 + 6-month migration). Trigger conditions заданы (
records > 10MANDlookup_p99 > 2sfor 7d). Implementation отложена до hit trigger'а в production.
Биллинговые — ongoing
- Pricing reassessment trigger — каждые 6 месяцев на основе actual cost-per-request data из production. Финализация preliminary numbers (§8.3) до v1.0 launch.
Имплементационные — на этапе прототипа
- DHT namespace efficiency review — текущий план: A → hybrid (partial B) при profiling показывает > 100MB routing tables. Trigger пересмотра — после первых ~1000 active PRO users с many shared spaces.
Статус и roadmap
- v0.2 (2026-05-13) — initial unified spec: trust tiers, dual-DHT, sharing-space DHT, rustfs, mailbox model, non-payment timeline.
- v0.3 (2026-05-17) — rendezvous service restored with toggles; PRO model fully specified; PRO codebase scenario fixed; identity recovery согласован с kontinuum-app vault.
- v0.4 (2026-05-18) —
dht_routingmandatory для всех тиров; partner переосмыслен какbyo:vps/byo:home; mediator-initiated pairing; Virtual S3 Pool + free relay S3; family/team multi-tenancy; CDN-fronted buckets as attribute; user pins; billing упрощён до fixed + S3 pay-as-you-go; org-side admin = Grafana + Directus + Telegram bot; добавлена секция scalability vs centralized; первый раунд разрешения внутренних противоречий (timelines unified, scopes specified, missing решения для recovery / re-encryption / redirect). - v0.5 (2026-05-18) — второй раунд разрешения противоречий:
transaction_idдля atomic-pair Revoke+KeyRotation; adaptive quorum + degraded mode для малых Spaces; multi-layer metadata защита для redirect mode (presigned by default, obscure naming, disable LIST); UX warnings для family-mode tenant (data-loss risk + privacy implications); tenant exit flow с 14-day migration window; pin disabled для free-tier; housekeeping API calls разрешены кроме hard delete; различение «owner ноды» vs «owner Space» в auth-shim semantics. - v0.6 (2026-05-18) — разрешение open questions из §19: Tier 0 multi-sig governance (v0.1 1-of-1 + offline backup, v1.0 3-of-5 cert/CRL); geo-zone разделение
host_geo_zonevsstorage_geo_zoneдля multi-region providers; DR / chaos planning (§16.1) с quarterly game days; identity recovery UX warnings в 3 точках (onboarding / disable / free-tier); sharded DHT design зафиксирован с trigger conditions (v2.0 milestone); pricing draft с cost-plus margin 40% (§8.3); design brief для external S3 attachments сохранён вdocs/node/design-prompts/; transport стек зафиксирован — Noise + CBOR; DHT efficiency — A для v1.0, hybrid (partial B) при > 100MB routing tables. - v0.7+ — TBD: третий раунд противоречий перенесён в implementation phase. Spec в этой точке достаточна для start coding.
- v1.0 — pre-implementation freeze после полного prototyping cycle.