В минимально-упрощенном виде все может выглядеть так:

Сохраняемому в системе файлу присваивается некий произвольный 32 битный идентификатор.
Весь файл режется на небольшие, менее 1 кБ фрагменты. Фрагменты компрессируются
чем либо простым и текстово-ориентированным. Возможно шифруются.

Каждому фрагменту считается
16 битная чек-сумма, которая будет являться его идентификатором.
К каждому фрагменту дописывается заголовок в котором присутствует идентификатор файла,
идентификатор этого фрагмента и несколько N (8..32) идентификаторов следующих
(возможно и предыдущих) фрагментов.

Т.е. имея любой фрагмент файла можно составить УНИКАЛЬНЫЙ запрос на следующий фрагмент,
из идентификатора файла и N-1 идентификаторов следующих (предыдущих) фрагментов.
Т.е. идентификатор запроса имеет длинну не менее 128 байт, что с высокой степенью гарантирует
его уникальность.

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

На каждом узле имеется локальная база данных фрагментов.
Размер базы задается пользователем, а содержимое обновляется по востребованности.
Так же имеется динамическая таблица доступных в текущий момент узлов сети.
Тут есть проблема, как инициализировать ПУСТУЮ таблицу.
Т.е. надо знать изначально хоть один адрес или иметь сервера, откуда их получать.

При запросе файла просматриваются на совпадение заголовочные фрагменты в локальной базе,
затем рассылаются запросы на узлы из списка.
При получении ответа от узла в нем содержится рандомайзный набор из видимых от него узлов.
Узел, получивший ответ, обновляет/заменяет содержимое своей таблицы и продолжает поиск.
Таким образом, через некоторое число циклов, будет опрошена большая часть сети.

Получив положительный ответ, т.е. заголовочный фрагмент удовлетворяющий требованиям,
аналогично получаются все фрагменты данного файла.

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

При простое, сервер периодически запрашивает рандомайзные фрагменты и по ответам
обновляет как список видимых узлов, так и базу данных фрагментов.

Есть нюансы - организовывать сие лучше не по TCP а по UDP, что снимает накладные расходы на
установление соединения и позволяет производить анонимизацию отвечающего узла.
Так как каждый цикл запроса-ответа самодостаточен, то IP адрес отвечающего может вообще
отсутствовать в IP пакете.

Замиррорить то оно можно.
Однако вы знаете кто еще кроме Ларина этим пожелает заняться ?
Ведь нельзя же надеяться на одного человека, даже весьма достойного.
Я на всякий случай скачал все что можно, но даже имея все для себя я не могу
этим нормально делиться.

По поводу перекрывания - все зависит от глубины поиска. Если глубина больше 10, то и двухкратного перекрытия хватит. Но это будет благодатной почвой для вредительства.
Если глубина 1, то десятикратное перекрытие точно.

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

Собственно, только моя не информированность, и стала камнем преткновения. :((

Вот это - http://wiki.freenetproject.org/FreenetZeroPointRus - оно самое и есть. Т.е. достаточно поставить на своей машине и можно cпокойно расшаривать любую библиотеку на радость добрым людям.

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

Оно работает несколько медленно, т.е. для массированной скачки плохо. Но зачем качать все сплошняком, если есть гарантия что оно никуда не денется и доступно будет в любой момент.

Т.е. схема такова - обсуждения, аннотации и рейтинги лежат на открытых сайтах, а тексты в FreeNET, в свободном доступе и распределенном хранении.

Альтернативы FreeNet пока не предвидится. Т.е. основное чем должен обладать файлообменник - анонимность и скрытность данных.
Т.е. должно быть невозможно установить, кто что закачал и кто что выкачал. В лучшем случае анонимный ID пользователя.
Скрытность данных означает, что содержимое любой локальной части файлообменника, т.е. файла подкачки на локальном компе, не является чем либо копирайтно-защащищеным, а в идеале вообще идентифицируемым.

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

С центализованно базой данных тоже хня. Опять хостинг за неизвестно чьи деньги, статический известный IP, который завсегда заспуфить можно и кто то добрый, кто базу админит.

База данных, по любому, тоже должна быть децентализованной. Правда она может быть открытой и не иметь анонимного доступа, т.к. ее содержимое никак не является контрафактом.