> С удовольствием послушаю про варианты.

Я уже где-то описывал приблизительную реализацию идеи, имхо. Впрочем идея довольно общеизвестная:
1) Лукапы делать через DHT, например Kademlia - для неубиваемости и полной децентрализации. Достаточно быстрые лукапы, неплохо масштабируется и довольно-таки неубиваемо при правильной реализации (практические реализации DHT для большей устойчивости к атакам и ускорения лукапов могут несколько отличаться от того что в доках описано).

2) DHT само по себе не обеспечивает невозможность подделки результата. Оно лишь маппит ключ в значение. А кто опубликовал ключ и какое значение подсунул, для DHT исходно пофигу. Можно пролечить публичной криптогрфией. Самое очевидное решение: при публикации в DHT пары ключ-значение, ключ может быть не просто рандомным или осмысленным числом, а допустим хэшом публичного ключа. При этом можно будет проверить что вон тот хост предлагает правильный пубкей (по совпадению хеша) и проверить что он - это именно он, а не левый претендент, запросив операцию требующую парного привкея (например, "вот тебе наш рандом, а подпиши ка его своей подписью и верни результат, а мы проверим подпись").

Таким макаром можно замапить например постоянный ID из оверлейной сети в реалный IP, обеспечив "просто распределенный DNS" (без анонимизации и оверлейного роутинга) когда некий постоянный ID хоста (для обладания коим надо обладать парой пубкей + привкей) маппится в любой айпи по желанию владельца а остальные могут найти хост по постоянному ID невзирая на смены IP адресов.

Главный грабль? ID, как вы верно заметили, нечитабельны. Нужен маппинг человекочитаемый текст -> ID. Человекочитаемый текст по определению может написать кто угодно. Вообще, можно в принципе с этим справиться чем-то в духе магнитных ссылок, т.е. в ссылке именно постоянный ID хоста никак не привязанный к IP + "пожелание" что хост называется вон таким именем, примерно как &dn= в магнетах. Кстати юзер вообще сможет переобозвать хост как угодно, и для лично него "DNS" адреса вида "home" и "office" в рамках лично его компов могут ресольвиться в лично его машины, которые лично его home, например. Что в принципе удобно: юзер всегда может назвать "сайты" и "сервера" так как понятно и симпатично именно ему, а для обмена ссылками - можно юзать ссылки типа магнетов, с постоянными ID как основным идентификатором обеспечивающим неподделывабельность хоста другими :)

Основная проблема - из-за отсутствия центральной ауторити все-таки будет некоторый бардак с названиями и в принципе возможен фишинг. Можно частично пролечить фишинг, сделав локальную БД "букмарков" (по типу контактлиста в IM) и чекать по ней резольвимые хосты, предупредив юзера что хост с названием "hostname" уже был добавлен им ранее в список букмарков (список name <-> ID) и его ID тогда был другим, так что скорее всего, имеет место быть фишинг! Собссно, торенты по примерно такому принципу работают и никто не жалуется вроде. Т.е. приучить двуногих к ссылкам с постоянными ID и растределенным схемам построения доверия - в принципе можно. Хоть и будут некие грабли с фишингом, как минимум пока двуногие не привыкнут проверять ID хоста.

> Например в ТОР: нечитабльные id, в freenet тоже.

А ID - это что-то типа IP но в оверлейной сети. Зачем ему быть читабельным? Идентификаторы хостов по определению служебная сущность, зачастую криптографическая (ключ или хэш). Они не должны и не могут быть читабельны в массе своей. Примерно как никто не требует читабельности от IP адресов.

> В i2p это сделано достаточно коряво.

Насколько я помню, там соответствие name (вида something.i2p) -> виртуальный ID в сети грузится с каких-то серверов, или типа того. Проблем я вижу две:

1) полной честной децентрализации этого процесса толком нет.
2) постоянные идентификаторы хостов имеют совершенно адский размер, совершенно непригодный для какого либо употребления двуногими вообще. Т.е. двуногие в принципе не смогут нормально проверить на глаз соответствие ID <-> name подсунутое им, а мне кажется полезным такое свойство. В конце концов, fingerprint-ы ключей юзают же для проверки что правильный ключ подсунули и не то чтобы это лишняя мера.

Вообще, в i2p есть ряд интересных решений, но в целом как-то монструозно и не слишком понятно надизайнено, а практическая реализация - вообще какой-то ужас на яве.

P.S. штуки типа i2p решают целую гамму задач, при том в основном - анонимизация/виртуальный роутинг в оверлейной сети и защита транзитного траффика, а как там этот трафф будет доставлен физически - их вообще не колебет. Лукап имен там не основное, наверное потому и делается через ту еще ж. Только к mesh это относится довольно косвенно. Разве что общей похожестью идеи, но реализация напрочь разная и на разных уровнях протоколов. Mesh сети обычно не ставят себе задачей использование виртуальных идентификаторов, отвязку от физической структуры, полную анонимизацию, защиту транзитного траффа вплоть до сбивания отслеживания маршрута нодами и прочая. Это задачи протоколов более высокого уровня, а меш - лишь более отказоустойчивая "физика" сети. Если вам уронят "физику", как в Египте - все виртуальные оверлеи закладывающиеся на нее - тоже помрут или очень существенно деградируют, уперевшись в тощие граничные каналы(если смогут их нащупать вообще). Mesh созданы для решения подобных проблем - это отказоустойчивая "физика" как раз. Которую не выключишь одним чихом всю и сразу и для которой отказы отдельных нод - не проблема.