Вот я совсем не разделяю вашу веру в i2p. Во-первых, если будет белый список протоколов, то i2p его не переживет. Во-вторых, i2p - сама по себе палево, причем даже без dpi, просто по открытым портам. В i2p был бы смысл, если бы она могла работать не поверх провайдерского IP, а мимо него. Где-нибудь на Мальте, где все друг у друга на головах сидят, это, наверное, вариант, но в РФ - вряд ли. И да, я тоже думаю, что большинству просто будет лень, проще пойти в ВК.
I2P - это сеть, пересылающая пакеты между destinations, внутри тоннелей. Тоннели проходят через участников (один за другим: A->B->C). Участники могут соединяться друг с другом через NTCP2 (обёртка вокруг реального TCP) или SSU2 (обёртка вокруг реального UDP). Как можно заметить, в I2P destinations - аналог реальных IP-адресов.
Пакеты - это по сути низкоуровневые датаграммы (аналогия: сырые IP-пакеты), поверх которых реализуется datagram или streaming (внутрисетевые аналоги UDP и TCP).
I2P (или по крайней мере i2pd) может также работать в меш-сети Yggdrasil, которую можно построить поверх реального интернета (в т.ч. tls и quic соединения; такие узлы действительно есть, даже публичные), или даже вне интернета посредством ethernet или wifi соединений.
В этом не будет особого смысла. После белых списков РКН перейдет к модерации самих российских платформ. Возможно добавят мониторинг “запрещенного контента” с помощью ИИ. Все таки я буду считать, что P2P связь и общая децентрализация должны стать трендами в это десятилетие, хотя возможно можно делать как те же туркмены и иранцы - максимально пытаться скрыть свою ВПСку, но и это тоже возможно не поможет если мы будем иметь сценарий ковровых бомбардировок иностранных хостеров
Если приплетается yggdrasil, то зачем в этой схеме i2p?
На тру обсуждалось уже - нужно включать интерфейс на трекерах чтоб раздавать адреса и все дела.
ygg интересная штука, но это тот же tls - а его заблочить не проблема если станет популярным
как раз когда блокировали dht была идея написать что-то вроде прокси, который представлял бы собой dht клиент и ноду на vps, но запросы бы слушал и как трекер. Итого, если скачивающий может узнать у такого трекера несколько пиров, которых тот спросит из dht - дальше сможет участвовать через peer exchange в trackerless раздаче. Это всё теория, да и хотел больше с образовательной целью, потыкать протокол, потому что звучит как что-то эгоистично вредное для сети в целом. Да и не лучше, чем публичный трекер через прокси, если раздача не начисто trackerless. Но руки пока так и не дошли, разрешаю украсть идею вдруг кому то покажется полезной
в идеале нужно писать новый торрент клиент который принимал бы фейковые пакеты, тогда Запрет точно справится. русские ip ркн вряд ли будет блочить, в этом вся суть чебурнета как бы, а сигнатуры может
Как минимум для повышения анонимности/конфиденциальности. Yggdrasil не ставит перед собой такой цели.
При коммуникации двух узлов в Yggdrasil между собой, некоторое количество посторонних узлов может узнать факт их коммуникации.
Более того, если была бы построена Yggdrasil-меш-сеть не через Интернет, думаю, можно было бы определить примерное местоположение узла, исходя из карты сети и знания местоположения других узлов - ведь существует карта, где показаны некоторые соединения между узлами сети.
(Но это не точно.)
Думаю, если надо, можно завернуть соединение в прокси, использующий любой известный способ обхода.
Можно написать плагин для BiglyBT. Там уже есть своя сеть дистрибуции Azure. (Но жаба-код ужаснейший).
Если будет белый список протоколов, то его не переживет не только i2p.
i2p не более палево, чем тот же торрент или shadowsocks.
если бы она могла работать не поверх провайдерского IP, а мимо него
Как вы хотите попасть в интернет мимо провайдера? Почтовые голуби?
Задача i2p:
- скрыть кто с кем взаимодействует
- скрыть реальное размещение сервиса (и его клиента тоже)
И поэтому (а также по иным причинам) лучше не качать торренты напрямую с российского ip и не использовать протоколы, которые выглядят как непонятное нечто. Ну и я все же считаю, что торренты с точки зрения РКН могут быть меньшим палевом, чем i2p.
Интернета не будет - будет чебурнет, и я туда вообще не хочу. Один из основных тезисов выше в том, что у юзеров есть контент. И вот если была бы какая-то связность… В 90-е, когда был dialup, “локалки на районе” существовали.
Вопрос в том, для кого не будет смысла 
Для вас и для меня, возможно. Но чтобы p2p работало, нужно некое не слишком маленькое множество юзеров, а вот в него я не верю.
Интернета не будет - будет чебурнет
А зачем, если патриотизм в стране зашкаливает? Куда ни зайди везде говорят какие хохлы плохие и ничего против войны. В Беларуси это ещё имеет смысл, там батьку многие не любят.
A что если i2p маскировать чем-то типа xtls-reality под трафик до vk например
i2p слоу. Лично я ко всем скачанным торрентам скриптом добавляю список публичных ретрекеров, а также ретрекеры в иггдрасиле.
скрипт для трансмиссии:
#!/bin/bash
test_tracker='retracker.local'
trackers=( `cat /var/lib/transmission-daemon/info/additional_trackers.lst` )
ids=(`transmission-remote --list | head -n -1 | tail -n +2 | grep '^ ' | awk '{ print $1 }' | tr -d '*'`)
for id in ${ids[@]} ; do
if [ ! "`transmission-remote -t $id -it | grep $test_tracker`" ]; then
echo "adding trackers for torrent with ID $id"
for tracker in ${trackers[@]}; do
transmission-remote --torrent "$id" -td "$tracker"
done
fi
transmission-remote --torrent "$id" --start
done
additional_trackers.lst:
http://retracker.local/announce
udp://tracker.openbittorrent.com:6969
udp://tracker.opentrackr.org:1337/announce
http://re-tracker.ru:80/announce.php
http://retracker.ygg/announce
http://[21e:6565:9c87:a49d:dafa:92c1:b33f:f21]:1337/announce
http://[200:1e2f:e608:eb3a:2bf:1e62:87ba:e2f7]/announce
http://[316:c51a:62a3:8b9::5]/announce
http://[300:7232:2b0e:d6e9:216:3eff:fe34:ec44]:6969/announce
В яге даже бывает немножко траффика. Иногда.
Впрочем, если известен нормальный i2p ретрекер - могу добавить и его в список. В рамках эксперимента
Насколько мне известно, I2P не поддерживается в Transmission. Был какой-то форк, но он заброшен.
Некоторые торрент-клиенты для I2P:
- I2PSnark (bundled with Java I2P or standalone)
- qBittorent >=4.6 (или другой клиент, основанный на libtorrent-rasterbar) - необходима версия libtorrent >= 2, желательно >=2.0.10
- BiglyBT
Актуальный список открытых трекеров для I2P можно найти здесь (внутри сети):
http://wiki.i2p-projekt.i2p/wiki/index.php/Eepsite/Services#BitTorrent_open_trackers
Приведу также список здесь:
http://opentracker.dg2.i2p/a
http://opentracker.r4sas.i2p/a
http://opentracker.skank.i2p/a
http://opentracker.simp.i2p/a
http://tracker.eeptorrent.i2p/a
А трансмиссии не пофиг если i2p роутер работает в режиме транспрокси?
Чекнул, делает вид что работает. Как минимум один из 4 трекеров рапортовал что работает. Остальные правда сфейлились с ошибкой no ip (dest). Подозреваю, потому что при прозрачном проксировании ip2 хосту выдаётся один реальный ip адрес на все хосты. Но посмотрим
Как бы их не приложить с овер четырьмястами торрентами на раздаче
Если для этого используется SOCKS или HTTP прокси, то вряд ли пиры смогут инициировать соединения (будет примерно так же, как если вы за NAT в обычном интернете) - ведь через прокси можно только connnect, а не listen.
Тем более, если выдается 1 ip адрес на все хосты, то их различение, возможно, происходит с помощью HTTP-заголовка Host, которого не будет при соединении с пирами, поскольку Bittorrent не HTTP.
Так пиры и не должны качать через i2p ИМХО.
Пиры должны зайти по i2p на ретрекер и получить список клирнет пиров(что в теории сейчас и происходит. Трансмиссия не знает ничего про мой псевдохост в i2p сети при транспрокси схеме)
Если битторент траффик пойдёт через i2p сеть - она к чёрту ляжет
З.Ы. Вообще на самом деле супер любопытный вопрос конечно, что именно сейчас летит в качестве ip адреса пира и поддерживают ли i2p ретрекеры обычный ipv4 адрес в качестве адреса хоста вместо b64 псевдоадреса. И готовы ли торрент клиенты к получению ipv4 пира от i2p трекера. Возможно, ошибка no ip (dest) как раз и говорит об этом.
Нет, пиры должны соединяться через I2P, именно так и задумано:
Cross-Network Prevention
To preserve anonymity, I2P bittorrent clients generally do not support non-I2P announces or peer connections. I2P HTTP outproxies often block announces. There are no known SOCKS outproxies supporting bittorrent traffic.
To prevent usage by non-I2P clients via an HTTP inproxy, I2P trackers often block accesses or announces that contain an X-Forwarded-For HTTP header. Trackers should reject standard network announces with IPv4 or IPv6 IPs, and not deliver them in responses.
(source: http://i2p-projekt.i2p/en/docs/applications/bittorrent / Bittorrent over I2P - I2P)
Хотя, насколько often I2P HTTP outproxies block announces, неизвестно. Может, какие-то и не блокируют. (Но тут другой вопрос - примет ли трекер с IP-адреса 1.2.3.4 (outproxy) анонс о том, что раздача идет с IP 5.6.7.8, или не поверит и отбросит).
Ну и в теории можно какой-то свой сервер создать, который по I2P будет принимать анонсы клирнет-пиров. Скорее всего, даже никакой кастомный софт писать не надо будет, просто завернуть известный трекер в server-туннель. Тогда даже никакая поддержка от торрент-клиента не нужна (разве что только SOCKS или HTTP прокси, но и без этого можно обойтись).