Крупнейшая свободная электронная библиотека выходит в межпланетное пространство

    Library Genesis - настоящий бриллиант Интернета. Онлайн-библиотека, предоставляющая свободный доступ более чем к 2.7 миллионам книг, на этой неделе сделала долгожданный шаг. Одно из веб-зеркал библиотеки теперь дает возможность скачать файлы через IPFS - распределенную файловую систему.

    Итак, коллекция книг Library Genesis загружена в IPFS, запинена и соединена с поиском. А это значит, что теперь лишить людей доступа к нашему общему культурному и научному наследию стало немного тяжелей.

    О LibGen

    В начале нулевых в пока ещё свободном от регулирования интернете лежали дюжины сборников научных книг. Крупнейшие коллекции из тех, что я могу вспомнить - KoLXo3, mehmat и mirknig - содержали к 2007 году десятки тысяч учебников, публикаций и других важных djvuшек и pdfок для студентов.

    Как и любые другие свалки файлов, эти коллекции страдали от общих проблем с навигацией. Библиотека Колхоз, например, жила на 20+ DVD-дисках. Наиболее востребованная часть библиотеки руками старшаков переселялась в файловую шару общежития, а если нужно было что-то редкое, то горе тебе! Как минимум ты попадал на пиво для хозяина дисков.

    Тем не менее, коллекции были все ещё осязаемых размеров. И хотя поиск по названиям самих файлов зачастую разбивался о креативность создателя файла, ручным full-scanом можно было вытащить нужную книгу после упорного проматывания десятка страниц.

    В 2008 году на rutracker.ru (тогда torrents.ru) энтузиастом были опубликованы торренты, скомпоновавшие существовавшие сборники книг в одну большую кучу. В этом же треде нашелся человек, начавший кропотливую работу по систематизации выложенных файлов и созданию веб-интерфейса. Так появился Library Genesis.

    Все это время с 2008 года и до текущего момента LibGen развивался и пополнял собственные книжные полки силами соообщества. Метаданные книг редактировались, а затем сохранялись и распространялись в виде дампов MySQL для всех желающих. Альтруистическое отношение к метаданным привело к появлению большого количества зеркал и повышению выживаемости всего проекта, несмотря на возросшую фрагментацию.

    Важной вехой в жизни библиотеки стало зеркалирование базы данных Sci-Hub, стартовавшее в 2013 году. Благодаря коллаборации двух систем в одном месте оказался сконцентрирован небывалый по качеству набор данных - научные и художественные книги вместе с научными публикациями. У меня есть предположение, что одного дампа совместной базы LibGen и Sci-Hub будет достаточно для восстановления научно-технического прогресса цивилизации в случае его утраты в ходе катастрофы.

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

    LibGen в IPFS

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

    IPFS появился относительно давно. На технологию при её появлении возлагались большие надежды и не все из них оправдались. Тем не менее, развитие сети продолжается, а появление в ней LibGen может усилить приток свежих сил и сыграть на руку самой сети.

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

    Некоторое время назад участники LibGen анонсировали IPFS-хеши и встали на раздачу файлов. На этой неделе ссылки на файлы в IPFS стали появляться в результатах поиска некоторых зеркал LibGen. Кроме того, благодаря действиям активистов команды Internet Archive и освещению происходящего на reddit, сейчас идет наплыв дополнительных сидеров как в IPFS, так и на раздачу оригинальных торрентов.

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

    P.S. Для желающих помочь проекту создан ресурс freeread.org, на нем живут инструкции как настроить IPFS.

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 55

      +4

      Сообществом distributed.ru не раз писали в sci-hub о том, что было бы круто применить ipfs, но порой получали баны (:


      Круто, что технология находит свое применение.

        +10

        Бан в названном месте получить проще простого, ничего удивительного. А scimag рано или поздно окажется в IPFS, я уверен в этом.

          0
          Всегда было интересно, сохраняет ли Sci-Hub запрашиваемые статьи на свои диски?
            +1

            Да, сохраняет.

        +2
        Можно еще несколько шагов сделать, например, перенести хэши в блокчейн. Есть медиаблокчейны, как раз для такого предназначены (всякие Steem, Hive и прости-господи Golos), т.е. в них будут храниться описания и ссылки.
        Кстати кто не в курсе с IPFS уже много кто эксперементирует, например на ней создан децентрализованный youtube — d.tube
          0

          Спасибо за ссылки! Мне только блокчейн кажется оверкилом для хранения хешей файлов, а вот OrbitDB — в самый раз. Насколько мне известно, были эксперименты по засовыванию метаданных библиотеки именно в эту базу.


          Блокчейн с инфраструктурой сертификатов больше подошёл бы для Sci-Hub и открытой системы peer-review.

            +1
            Возможно и оверкил, сложно на пальцах оценить. Из плюсов то, что можно встроиться в уже существующий блокчейн, с существующим комьюнити, которое только приветсвует появление новых приложений на блокчейне. Пользователи смогут входить в блокчейн через любую работающую точку входа (UI), специлизированную или более общую, видеть нормальное текстовое описание книги + картинки (картинки уже не в блокчейне правда), иметь дерево комментариев для книги, ну и собственно ссылку для скачивания.
              +1
              >децентрализованный youtube — d.tube
              как подобные открытые штуки не засыпают тоннами спама/запрещённого прона и тд?
              оно как-то модерируется?
              +3

              А требования у библиотеки под стать ее монументальности :)
              « Recommended at least 16GB RAM and Intel i5 or equivalent processor»


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

                +4

                Стойте, не уходите!1 Требования написаны исходя из оценки в 100 000+ файлов на узел. Меньше файлов на раздаче — меньше памяти. В требованиях Cloudflare сказано про 2GB RAM, а по факту люди сообщают, что IPFS и на Raspberry Pi Zero запускается с 1GB RAM. Правда, надо будет ограничить количество входящих соединений в конфиге IPFS.

                  +3

                  Стою, не ухожу :)
                  Ок, попробую развернуть докер. А то требования по объёму очень щадящие (10+ ГБ), а вот по памяти очень смутило.
                  Готов был выделить около 2Gb RAM под это дело.
                  Спасибо.

                  +1

                  Можно установить только консольную версию IPFS. Web-UI в ней всёравно будет доступен через ваш браузер.


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


                  Если очень хочется посмотреть что там не устанавливая клиент можно воспользоваться публичными шлюзами IPFS.

                    0
                    Только я не понял как пользоваться этой библиотекой.

                    Основной способ использования прямо сейчас — веб-зеркала/Telegram-боты для поиска внутри базы метаданных по автору, названию или описанию. Для найденных файлов зеркала дают прямые URLы через IPFS-gateway. Я специально не оставляю в статье никаких ссылок, так как периодически адреса меняются. Но гуглится всё достаточно просто.


                    Второй вариант — путь воина. Он заключается в развертывании собственного зеркала. Только для возможности сопряжения поднятого зеркала с IPFS нужно дождаться IPFS-хешей в дампах метаданных. Сами дампы регулярно выкладываются в общий доступ.

                  0
                  А чем это принципиально отличается от торрентов, помимо сложности настройки/использования?
                    +2
                    Принципиально ничем, в том смысле, что технология схожа. Но есть отличия, первое, что приходит в голову — это уникальность файлов, т.е. если куча нод хранит один и тот же файл, то всё это будет под одним адресом, в торрентах же, например, один и тот же фильм каждый торрент-трекер «хранит» отдельно от других.
                      0
                      Ну это, есть жеж DHT и прочие наборы буков. Вон и в описании сабжа DHT упоминается. Чем DHT который в торрентах не угодил?
                        +12

                        Дело не в DHT а в том что скрывается под хешем в DHT. BitTorrent в DHT публикует хеш от метаинформации всей раздачи info hash. Таким образом при изменении этой метаинформации меняется хеш и образуется отдельный рой который никак не связан со старым.


                        IPFS публикует в DHT хеш каждого блока. Блоки связаны друг с другом хешами и образуют деревья каталогов и файлов в листьях которых кусочки данных файлов. Это даёт возможность мощьной дедубликации.


                        Один и тот же файл с разными именами будет иметь одинаковый хеш и будет источником для разных деревьев.


                        Более того благодаря чанкеру rabin(он не используется по умолчанию) файл будет разделён на части более умным способом и два разных файла в которых есть одинаковые части могут быть источниками друг для друга.

                          +1

                          Как в таком случае разрешается коллизия блоков с одинаковым хэшем? По метаданным?

                            0
                            Там хэши минимум 128-битные, в основном 160 и 256 используются. Так что, думаю, никак, да и не надо
                        +1
                        это уникальность файлов, т.е. если куча нод хранит один и тот же файл, то всё это будет под одним адресом

                        Встречаем протокол Torrent V2. Там это пофиксили. Но распространение примерно такое же, как и IPFS.
                          0

                          что за такой протокол bittorrent v2?
                          где про это почитать? в уторенте когда будет реализован?

                            0
                            Прочитать можно на Хабре, а за вторым к разработчикам. Думаю, не скоро. Я же не зря сказал, что его распространение пока мало.
                              +1
                              в уторенте когда будет реализован?
                              А я забил обновляться на 3.5.5 когда после начали появляться неотключаемые окна и предложения…
                                0
                                Я кучу лет сидел на 1.8.5 и был жизни рад )) Сейчас на той же самой есть пара проблем, все альтернативные мне не понравились, вот и кушаю кактус.
                          +3

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

                          +2
                          Молодцы, добавили еще один транспортный канал. Это безусловно повысит доступность и защищенность библиотеки от всяческих блокировок.
                            +1
                            А какой сейчас размер всей базы книг и базы метадаты? Во времена колхоза была мечта собрать домашний сервер с книгами, но тогда на это не было денег :)
                              +3

                              Ориентировочные размеры такие:
                              LibGen — 40TB, мета от 500MB до 10GB без индексов. Размер меты зависит от алгоритма сжатия и от того, как считать — в jsonах, инсертах в файле SQL дампа или в бинарном виде без схемы. Необходимые индексы в БД тоже сколько-то места занимают, от 50% до 200% размера БД.


                              Sci-Hub — 70TB, мета от 10 до 50GB. У БД Sci-Hub'a метаданных больше на порядок, так как в ней 87 миллионов записей против 2.7 миллионов LibGen'а.


                              Сами pdfки неплохо жмутся, 15%-20% размера можно срезать, если, например, включить сжатие zlibом на файловой системе.

                                0
                                Да, нехило за это время выросли размеры. Недорого свой сервер не подымешь под такой объем.
                                  0

                                  Так под весь объем и не надо поднимать. В IPFS можно запинить столько файлов, сколько позволит диск и это все равно будет существенным вкладом. Более того, система из 10 человек, раздающих по 1GB, будет в целом устойчивее, чем 1 человек, раздающий все 10GB.

                                    0
                                    Вариант с IPFS интересный, надо будет на досуге посмотреть, как раз есть свободный RPi на 4 GB. Про устройчивость согласен.

                                    Про весь объем — это к студенческой мечте про поднять домашний сервер со всей библиотекой :) Хотя конечно, у меня есть личная библиотека на ~100 ГБ и интересные статьи в Mendeley.
                                  0
                                  ну то есть в ipfs там не сами книги, а хеш который помогает искать их потом по зеркалам?
                                  но ведь если зеркала прикроют — сам хеш этот не особо полезен будет.
                                  или не совсем так?
                                  ps есть что-то толковое почитать по ipfs? много раз натыкался, интересно :)
                                    0

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


                                    Суть в том, что метаданные и хеши занимают маленькие объемы диска и каждый может быстро поднять базу с этой информацией, поэтому на одно прикрытое зеркало появится 10 новых. Без IPFS зеркала вынуждены самостоятельно таскать за собой все 100TB книг и статей вместо их хешей. Мало кто из энтузиастов может себе позволить содержать такие объемы дисков и обеспечивать соответствующий трафик, поэтому и зеркал существует не очень много. IPFS должен помочь изменить эту ситуацию. Кроме того, содержать только метаданные немного безопаснее, чем содержать ещё и файлы.


                                    Почитать можно достаточно хорошую документацию и whitepaper

                                      0
                                      Собственно, вопрос, а не ответ.
                                      Привычным является сервис, когда запросы отрабатываются на сервере,
                                      а доступ к ДОСТУПНЫМ первоисточникам возлагается на пользователя.
                                      — Есть-ли какие-либо соображения и оценки возможности организации на СЕРВЕРАХ
                                      индексов мета-данных уровня ссылки/библиография?
                                      — Возможно-ли исключение дубликатов содержания (например — шкурки DJVU/PDF
                                      к отсканированным оригиналам)?
                                        0
                                        — Есть-ли какие-либо соображения и оценки возможности организации на СЕРВЕРАХ индексов мета-данных уровня ссылки/библиография?

                                        Для книг готового ссылочного графа я не знаю. Для научных статей существует инициатива открытого цитирования в партнерстве с CrossRef. API CrossRef умеет отдавать ссылки статей друг на друга в рамках этой инициативы. Поэтому принципиальная возможность самостоятельно построить индексы по ссылкам есть.


                                        — Возможно-ли исключение дубликатов содержания (например — шкурки DJVU/PDF к отсканированным оригиналам)?

                                        Возможно всё, вопрос усилий. Дубликаты хорошо отсеиваются и по метаданным, по-крайней мере в случае LibGen.


                                        Для исключения дубликатов по содержанию нужно уметь извлекать текстовый слой из файла. Для PDF с распознаными символами есть утилиты типа PDFBox/grobid. Для нераспознанных сканов необходимо сначала запускать OCR. Что есть для djvu — не знаю, но точно что-то есть.


                                        Мне известны библиотеки, которые проделывали такую работу и заодно выделяли ключевую лексику из текстов, а потом успешно искали дубликаты по пересечению ключевиков. Есть ещё алгоритм шинглов, описанный iseg для Яндекса — это если предположить, что качество текстового слоя хромает и четкого дубликата не будет из-за ошибок распознавания.

                                          0
                                          — К Вашему 1-му ответу.
                                          Распросы работающих людей заканчиваются на
                                          … у СЕБЯ мне Bib-TeX достаточно.
                                          Как только речь идет об уровне обзоров и/или монографий, то в деревья/цепочки ссылок (опять-таки) вдаваться не хотят.
                                          Размер, увеличивающяяся доля шума или мусорных/ритуальных ссылок,
                                          сложность управления деревом ссылок, подстройка остова и т.д.
                                          Надежда на то, что где-то (может быть в LibGen)
                                          хоть как-то будет организовано. Как пример локального (даже с MS SQL)
                                          www.citavi.com/en/products
                                          — к Вашему 2-му ответу.
                                          Мне казалось, что первичен скан. Доступные случаи, когда multi-page TIFF
                                          уходил к разным командам на пост-процессинг, и на выходе (логи WinDiff etc.)
                                          после РАЗНЫХ OCR, разного тщания suspected OCR covering, мета-данных
                                          (а-ля TOC) получались СУЩЕСТВЕННО различные файлы PD.
                                          Из Российских решений вспоминается проект сопровождения fb2 файлов
                                          fbd дескриптором (библиография, внутренние мета-данные и т.д.).
                                            0
                                            Надежда на то, что где-то (может быть в LibGen) хоть как-то будет организовано.

                                            Попробуйте Google Scholar. Находите что-нибудь, а потом на странице поисковой выдачи под строкой с найденным жмете Cited by X…
                                            Так же работает ResearchGate.


                                            Мне казалось, что первичен скан. <...>

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

                                              0
                                              За рекомендации — благодарен.

                                              Движков OCR, подсоединяемых к ним шаблонов/словарей,
                                              (по моему) без счета. Глубина пост-обработки тоже изменчива.
                                              И только исходный слой — скан страницы в растровой графике
                                              ОБЯЗАН остаться неизменным. Это обо всех первоисточниках
                                              до цифровой эры.
                                                0

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

                                                  0
                                                  Мотивы моей настырности.
                                                  ВСЯ литература и статьи советского периода
                                                  представлены ТОЛЬКО сканами, и вручную
                                                  подготовленными и введёнными мета-данными.
                                +3
                                Еще учась в институте и познакомившись с админом тамошнего студенческого форума, где у нас в том числе был свой файловый архив с отсканенными учебниками, билетами и т.д. я прям загорелся идеей свободной литературы. У технической и научной литературы, особенно отечественной, совсем другая специфика — это важные фундаментальные, справочные и методические труды, опыт кафедр, производств и НИИ, он вообще-то создавался для просвещения, обучения и повсеместного использования. И когда дело касается не пиратских фильмов и попсового худлита, а именно образовательной и научно-технической продукции, я всегда хотел и «скачать интернет», и сам стать файловым пушером, распространяющим библиотеку знаний. Спасибо за статью и инициативу.
                                  +3
                                  Еще учась в институте и познакомившись с админом тамошнего студенческого форума, где у нас в том числе был свой файловый архив с отсканенными учебниками, билетами и т.д. я прям загорелся идеей свободной литературы.

                                  Тем интереснее вам будет наблюдать за звеньями одной цепи. Из этих файловых архивов российских университетов появились свободные библиотеки, которые, спустя десятилетия тихой работы множества людей, начали менять научный ландшафт в мире. Европа уже планирует перекрыть кислород безумию платного доступа. И у истоков инициативы европейских академий стоят те люди, которые во времена своей учебы узнали о Sci-Hub и LibGen, и совершенно точно пользовались ими. Вот так идея оказалась сильнее плохих традиций и перешагнула границы и время.

                                  +1
                                  Спасибо за материал!)
                                    0
                                    это все конечно хорошо, но для рускоязычного сообщества нужна быстрая и простая инструкция как подключиться к ipfs, искать и скачивать\раздавать. в статье есть ссылка, но там англисйкий язык. нужна инструкция из разряда «вот этих 5 простых шага» позволят искать файлы ипапки(многофайловые раздачи), скачивать, раздавать. было бы очень хорошо написать статью на эту тему.
                                    ipfs мне представляется как р2р файлообменная сеть типа edonkey, gnutella, bittorrent вместе взятые без недостатков каждой отдельной файлообменной сети с наличием глобального поиска файлов и многофайловых раздач.
                                      +1
                                      ipfs мне представляется как р2р файлообменная сеть типа edonkey, gnutella, bittorrent вместе взятые без недостатков каждой отдельной файлообменной сети с наличием глобального поиска файлов и многофайловых раздач.

                                      Увы, слишком идеалистичное представление.
                                      IPFS — это только хранение файлов, поиск к IPFS не относится. Конкретно в случае LibGen метаданные для поиска живут в отдельно распространяемой БД, которая не связана с IPFS никак. Были попытки засунуть эту БД в OrbitDB, СУБД на основе IPFS. Чем всё закончилось я не знаю. Соответственно и поиск по этим метаданным — ответственность зеркал или тех, кто разворачивает дампы меты у себя. Импорт дампов и разворачивание зеркал пока является работой с открытой концовкой, никаких quickstart здесь нет. Разве что могу подсказать, что сами ссылки на дампы есть на archiveteam.


                                      Про русский язык замечание принимаю, правда обещать пока ничего не буду. Я сейчас попробовал зайти на https://freeread.org/ipfs/ в Chrome, щелкнуть правой кнопкой на тексте и перевести всю страницу на русский язык. Получилось сносно, хотя достоверно оценить не могу, глаза у меня уже замылены наглухо всеми этими инструкциями.

                                        0
                                        без недостатков каждой отдельной файлообменной сети

                                        Зато со своими недостатками. Разбросать файлы в произвольные каталоги нельзя, сеть, как я понял, делает свой виртуальный каталог, а физически хранит абы как внутри себя.
                                        0
                                        я конечно сейчас пойду на википедию почитаю, да и на хабре я видел несколько статей на тему ipfs, но статья на хабре типа quick guide очень нужна.
                                          0
                                          прочитал статьи на хабре про ipfs. это оказалось только хранение отдельных файлов.штука конечно хорошая, но не решает проблемы «скачать любую многофайловую раздачу всегда и быстро».
                                          +1
                                          как я понял, протокол bittorrent v2 существует уже 12 лет, и только вот сейчас он был внедрен только в 1 торрент клиенте и то, это форк vuze (azureus)? который на яве, и распространен почти никак. а тем временем в уторенте уже 15 лет не могут исправить баг с dht, когда не более примерно 200 раздач могут быть анонсированы, а все остальные навечно висят со статусом «ожидание анонса». открывать исходные коды уторента разрабы в свое время пожадничали, а потом их купила корпорация которая владеет одной из криптовалют и пообещала сразу же встроить криптокошелек в уторент, заодно использовать уторент для нужд криптовалютной сети. существует р2р клиент shareaza, и улучшеный форк ishareaza, который разрабатывал хабровчанин ivan386. этот р2р клиент поддерживает edonkey2000, gnutella1 и gnutella2, bittorrnt с dht, но не поддерживает kad сеть (аналог dht в торентах, но для ed2k сети). к сожалению, ivan386 написал что ему «не интересно» внедрение kad в ishareaza, что очень жаль.там всего лиш нужно взять kad из исходников emule и адаптировать для ishareaza. я написал все это к тому что можно было бы внедрить поддержку ipfs в ishareaza как webseed, чтобы лучше скачивалось. в этом р2р клиенте есть глобальный поиск. тем временем в уторенте у меня висит 600 недокачаных полумертвых раздач. 1 раздачу я уже качаю 3 года и она скачана на 97.4% и не двигается дальше. там всеголишь 1 файл из 25 не докачан полностью. если бы разработчики уторента, в 2008 году сделали подержку протокола bittorrent v2, то с большей вероятностью, я бы уже скачал бы эту раздачу и все остальные.
                                            +1
                                            баг с dht, когда не более примерно 200 раздач могут быть анонсированы

                                            Вот не нужно тут, сейчас уже около 400. А так согласен, проблема. И хеширует по очереди, даже если раздачи лежат на разных дисках. Много недоработок. С другой стороны, не уверен, что open source клиенты вообще хорошо справляются с десятками тысяч раздач, что раздают некоторые хранители на Рутрекере, которые, ЕМНИП, все поголовно на uTorrent.
                                              +1
                                              кто-то делал расчеты, что уторент может анонсировать не более 320 раздач в dht. там самый главный параметр — время, которое уторент затрачивает на анонсирование 1 раздачи и через сколько минут уторент начнет анонсировать с начала списка раздач. достаточно было бы сделать 1 параметр в дополнительных настройках «через сколько минут начать анонсирование с начала очереди для анонсирования по dht». это бы частично решило бы проблему. open source помогбы уторенту решить баги, достаточно взять уже исправленый исходный код из форка. по моему мнению, наибольшая проблема альтернативных торрент клиентов в их gui графическом пользовательском интерфейсе. у меня проблемы со зрением и уторент это единственный торрент клиент которым я могу пользоваться. еще ishareaza может качать торенты, но не более нескольких раздач одновременно, ищет источники весьма плохо, качает медленно и не лучше уторента. qbittorrent для меня недоступен — у него большие проблемы с экранной доступностью. кое-как, через командную строку я смог добавить торрент-файлы в очередь для загрузки и qbittorrnt одновременно запущеный с уторентом как-то качает полумертвые раздачи. веб-интерфейс в qbittorrent я так и не смог включить. gui для меня почти недоступен, через .ini файл так и не смог установить пароль. все остальные торрент-клиенты для меня недоступны. перепроверил уже много. как-то все очень печально все в мире…
                                                0
                                                кто-то делал расчеты, что уторент может анонсировать не более 320 раздач в dht.

                                                В 3.5 в какой-то версии что-то подкрутили, стало чуть быстрее. Лично я просто отрубаю DHT на популярных раздачах, там и так пиры через обмен найдутся.
                                                достаточно было бы сделать 1 параметр в дополнительных настройках «через сколько минут начать анонсирование с начала очереди для анонсирования по dht».

                                                Достаточно было бы сделать тупо очередь, и тогда они бы все обновлялись, просто с большей задержкой. И новые нужно ставить в начало очереди, чтобы он обновлялся первым, а не никогда, как сейчас. Я уж молчу про многопоточный DHT.
                                              0
                                              я написал все это к тому что можно было бы внедрить поддержку ipfs в ishareaza как webseed, чтобы лучше скачивалось

                                              И обычная Shareaza сейчас может пользоваться локальным IPFS шлюзом поскольку она умеет качать по HTTP протоколу изначально. Нужно только разрешить ей соединятся с локальными адресами и чтобы в магните была ссылка на него.


                                              Например:
                                              magnet:?xt=urn:bitprint:EITWOGBMBSED6Y7GOO3HOQS6EJ44OBG5.KSBWSY7XXXHOAQGAT5PH7SCNDPGVM4PD6KXA42Q&xt=urn:ed2khash:bcdfef48f42711399f147a99320b7a73&dn=Shareaza_2.7.10.2_Win32.exe&xl=6851032&xs=http://127.0.0.1:8080/ipfs/QmZ4MnjXFf1ow3hif3TyVMNayRNu7skgwQ1Zso5T2VNXY7


                                              Другое дело что Shareaza не знает что такое CID или Multihash не считает их и не передаёт в сеть G2.

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

                                            Самое читаемое