> Главный грабль? ID, как вы верно заметили, нечитабельны. Нужен маппинг человекочитаемый
> текст -> ID. Человекочитаемый текст по определению может написать кто угодно.
>...
> Основная проблема - из-за отсутствия центральной ауторити все-таки будет некоторый бардак
> с названиями и в принципе возможен фишинг. Можно частично пролечить фишинг,
> сделав локальную БД "букмарков" (по типу контактлиста в IM) и чекать
> по ней резольвимые хосты, предупредив юзера что хост с названием "hostname"
> уже был добавлен им ранее в список букмарков (список name <->
> ID) и его ID тогда был другим, так что скорее всего,
> имеет место быть фишинг!Я слабо знаком с I2P, но мне кажется что описанное вами частично есть там, а остальное можно реализовать.
>> В i2p это сделано достаточно коряво.
> Насколько я помню, там соответствие name (вида something.i2p) -> виртуальный ID в
> сети грузится с каких-то серверов, или типа того.
Насколько я понял, есть некий "хороший" сервер с адресной книгой, в котрой могут регистрироваться все желающие. Ссылка (подписка) на этот сервер уже есть в умолчальной конфигурации ПО.
Однако никто не мешает убрать "дефолтный DNS"(подписку) и добавить другой или вообще добавлять всё ручками в локальную адресную книгу (аналог /etc/hosts :)).
Хотя я вот сейчас написал это и мне это напомнило старую добрую DNS, только конечно примитивнее.
В DNS тоже никто не мешает выкинуть корневые сервера и использовать свои/альтернативные/"/etc/hosts". (ну правда с виртуальными хостами конечно проблемы будут)
> 1) полной честной децентрализации этого процесса толком нет.
Если выкинуть умолчальную подписку, то есть, но соответствие id <-> name у разных узлов может быть разное.
> 2) постоянные идентификаторы хостов имеют совершенно адский размер
Есть возможность использовать более короткие 52-ух символьные идентификаторы.
> практическая реализация - вообще какой-то ужас на яве.
безгеморройная кроссплатформенность требует жертв =)
