> и что?

То что это вообще не чат. Для чата надо писать еще отдельную программу. Которая ничем таким принципиально не будет отличаться от программы работающей через обычный интернет. Ну может быть в лучшем случае отпадет часть проблем с шифрованием. Тем не менее, оно делалось не для этого. А уж как через это пролезет аудио и видео - отдельный брейнфак. Оно делалось вообще с другими целями.

> ну да, хорошую оверлейную p2p-сеть с чесночным роутингом в тридцать строк не уложишь.

Тут ты прав, однако мне выкачивать яву ради всего этого и потом содержать жирные и тормозные процессы на ней дико обломно.

>> да еще с референсной реализацией на яве.
> и что? товарищи даже на N900 умудрялись i2p router запускать.

Ну да, если им пользоваться только как i2p роутером после этого - может даже и будет ползать как-то. А мне смарт нужен для более полезных применений, уж извини. Так что пусть товарищи и запускают.

> зато жабка

Вот ты этим и пользуйся, имхо. А я пешком постою, thank you very much. А я не собираюсь бубухать кучу системных ресурсов в "привилегию" проксировать чужой траффик, извини. Может мне еще этим парням биткоины помайнить на их счет до кучи, не? :)

> в этом случае таки даёт мультиплатформенность без особо сильного геморроя.

Я рад за них. Ну вот ты и пользуйся этим мультиплатформенно. У меня нет в системе явы. Грузить ее для получения права проксировать чужой трафф мне как-то не комильфо, извини.

> по пунктам распиши, пожалуйста, почему ты так считаешь. с ссылками на
> документацию. с пояснениями, почему SAMv3 и BOB — это ракетная наука.

Потому что не вижу чем чатик поверх этого будет принципиально отличаться от чатика поверх IP в общем случае. Ну заменится IP адрес на виртуальный ID в оверлейной сети, окей. Не вижу чем это принципиально меняет дело с точки зрения написания "чатика". А ракетная наука - это в целом понимание их протокола и как оно будет работать в различных ситуациях. Например, мне не очень понятно как через это можно гнать аудио или видео сколь-нибудь близко к реалтайму. Или, допустим, заворот звонка на PSTN гейтвей, например. Сам по себе i2p в этом плане ничего кроме головняка не принесет, похоже. С другой стороны я могу придумать как все это сделать в проблемо-ориентированном протоколе. Просто и без головняка (местами возможно с ущербом для приватности, но если кто звонит на PSTN, он априори на это уже положил). Кстати, универсально и без вендорлоков можно.

>> насколько я знаю, данная сеть довольно тормознута.
> это да, full hd video гонять упаришься. да и не full hd тоже как-то неспешно ползает.

И задержки поди ломовые, да? Ну то-есть звонкам - рослый полярный лис.

>> DHT или что там еще поверх нее будет вероятно работать не особо резво.
> и вот это с подробностями, пожалуйста. особенно интересует, зачем для DHT мегаскорости
> и мегабольшие пропускные каналы.

Затем что лукап в DHT - итеративная процедура, много бандвиза оно не жрет, но чувствительно к RTT. А ждать полчаса его завершения - юзеры взвоют. Тем более смотря что лукапать. Если например непосредственно контакты - юзеры с большим контактлистом вообще нафиг повесятся. Можно наверное костыль типа кеширования сделать, частично ослабит проблему, но это лишняя возня.

> пока что там унылая фигня, которая даже с IPv6 не дружит (привет, mesh-сети на IPv6! мы вас не умеем!).

Кроме того они не подозревают что UDP в корпорахах зачастую наглухо удавлен. И, кстати, в этом плане большой вопрос насколько i2p друг и товарищ, опять же. Как я понимаю, в нем никакого особого хардкора по автоматическому обходу натов и фаеров, работы через черти-какие прокси и прочая - не предусмотрено толком. Не говоря уж о закосе протокола под что-то еще (чтобы DPI радовались до кучи).