retroshare://chat_room?name=%23Decentralize%21&id=L07B35B141883342C
Текст в целом **очень сильный** — структурированный, инженерный, без воды, с чёткой позицией и акцентом на наблюдаемые факты. Это один из лучших текстов на тему «Yggdrasil как практический транспортный фикс для NAT-страдающих P2P», которые я видел за последнее время.
Ошибки / неточности / места, где можно усилить строгость или уточнить (по состоянию на 2026 год):
### 1. Метрики (самое слабое место с точки зрения воспроизводимости)
- ~146 в RetroShare и ~73 в IPFS — это выглядит правдоподобно, но без контекста остаётся анекдотом.
- Сколько друзей/нод в RetroShare было добавлено вручную vs. найдено через DHT?
- В IPFS: сколько из 73 — прямые QUIC/TCP-соединения, а сколько всё ещё через relay (circuitv2)?
- В какое время суток, на каком клиенте (версия RS 0.6.x? go-ipfs/kubo 0.20+ или 0.30+?), какой размер DHT-кэша, включён ли AutoRelay/AutoNAT и т.д.
- Без этих уточнений любой может сказать: «у меня и без Yggdrasil 200+ пиров в RS, а в IPFS 150+».
**Рекомендация**: добавить 1–2 предложения с конкретикой, например:
> RetroShare v0.6.6, ~180 добавленных друзей, DHT включён, без UPnP/PCP, измерение через 72 часа после старта.
Или хотя бы указать, что это типичный диапазон для вашей гео/конфигурации.
### 2. «Стабильно» vs. «нестабильно»
- «~146 (стабильно)» против «~70–90 (нестабильно)» — хорошо, но лучше формализовать, что подразумевается под стабильностью.
- Среднее время жизни пира (peer lifetime)?
- Процент пиров, у которых удалось передать >10 МБ за сессию?
- Churn rate (изменение количества пиров за час)?
Сейчас это субъективно. Если есть логи/скрипт мониторинга — упомянуть хотя бы формулу.
### 3. Overhead и latency
- Утверждение «выигрыш в reachability перекрывает потери» — верно для большинства сценариев, но не универсально.
- В 2025–2026 Yggdrasil v0.5+ серьёзно улучшил выбор пути (link cost по latency), но multi-hop всё равно даёт +30–150 мс в среднем (в зависимости от гео и числа хопов).
- Для IPFS это терпимо (fetch delay), для RetroShare chat/voip — уже заметно.
- Crypto overhead (Noise_XK или что там сейчас) на современных CPU почти незаметен, но на слабых ARM (Raspberry Pi, старые телефоны) может быть ощутимо.
**Уточнение**: добавить строчку вида
> Типичный прирост RTT в моей среде: +40–90 мс на end-to-end соединение при 2–4 хопах.
### 4. Сравнение с альтернативами
- Tor / I2P — да, выше latency и хуже для bulk data.
- Но есть ещё **Tailscale / Headscale / Netbird** (WireGuard-based mesh), которые в 2026 очень популярны именно для обхода CGNAT с гораздо меньшим latency, чем Yggdrasil.
- Минус: централизованный control plane (хоть и self-hosted в Headscale).
- Также **libp2p** с circuitv2 + AutoRelay + AutoNAT в последних kubo уже сильно улучшил ситуацию за NAT без внешнего overlay.
Можно добавить в контраст:
> Tailscale / Netbird — ниже latency, но требуют аккаунта/координатора. Yggdrasil выигрывает в полной децентрализации и отсутствии единой точки доверия.
### 5. Мелкие стилистические / терминологические придирки
- «логически есть, физически нет» → отлично, оставляем.
- «relay-heavy» → правильно, но сейчас в IPFS чаще говорят «circuit-heavy» или «relay-dependent».
- «всегда routable IPv6-адреса» → технически да, но адреса в диапазоне 0200::/7, который официально deprecated (хотя никто не фильтрует).
- «без port forwarding, UPnP и прочих нестабильных механизмов» → UPnP действительно нестабилен и опасен, но PCP (RFC 6887) и NAT-PMP в 2026 уже довольно надёжны у многих провайдеров — стоит упомянуть как «PCP/NAT-PMP тоже помогают, но далеко не везде работают».
- «в 2026 году главная проблема p2p — reachability» → полностью согласен, это до сих пор правда.
### Итоговая оценка
- **Техническая строгость**: 8.5/10 (метрики требуют конкретики, остальное на уровне).
- **Инженерная честность**: 9.5/10 (очень корректно расставлены акценты: не замена, а транспортный усилитель; overhead признан).
- **Читабельность и убедительность**: 9/10.
Если чуть доработать метрики + добавить пару уточнений по overhead и конкурентам — будет практически эталонный пост для 2026 года.
Если хочешь, могу предложить конкретный отредактированный фрагмент по метрикам или заключению.
