Pull to refresh

Comments 57

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


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

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

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

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


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

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

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


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

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

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

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


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


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

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

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


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

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

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


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


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


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

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

Там хэши минимум 128-битные, в основном 160 и 256 используются. Так что, думаю, никак, да и не надо
UFO just landed and posted this here

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

UFO just landed and posted this here
в уторенте когда будет реализован?
А я забил обновляться на 3.5.5 когда после начали появляться неотключаемые окна и предложения…
UFO just landed and posted this here

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

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

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


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


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

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

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

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

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

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


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


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

UFO just landed and posted this here
— Есть-ли какие-либо соображения и оценки возможности организации на СЕРВЕРАХ индексов мета-данных уровня ссылки/библиография?

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


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

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


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


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

UFO just landed and posted this here
Надежда на то, что где-то (может быть в LibGen) хоть как-то будет организовано.

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


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

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

UFO just landed and posted this here

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

UFO just landed and posted this here
Еще учась в институте и познакомившись с админом тамошнего студенческого форума, где у нас в том числе был свой файловый архив с отсканенными учебниками, билетами и т.д. я прям загорелся идеей свободной литературы. У технической и научной литературы, особенно отечественной, совсем другая специфика — это важные фундаментальные, справочные и методические труды, опыт кафедр, производств и НИИ, он вообще-то создавался для просвещения, обучения и повсеместного использования. И когда дело касается не пиратских фильмов и попсового худлита, а именно образовательной и научно-технической продукции, я всегда хотел и «скачать интернет», и сам стать файловым пушером, распространяющим библиотеку знаний. Спасибо за статью и инициативу.
Еще учась в институте и познакомившись с админом тамошнего студенческого форума, где у нас в том числе был свой файловый архив с отсканенными учебниками, билетами и т.д. я прям загорелся идеей свободной литературы.

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

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

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


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

UFO just landed and posted this here
я конечно сейчас пойду на википедию почитаю, да и на хабре я видел несколько статей на тему ipfs, но статья на хабре типа quick guide очень нужна.
прочитал статьи на хабре про ipfs. это оказалось только хранение отдельных файлов.штука конечно хорошая, но не решает проблемы «скачать любую многофайловую раздачу всегда и быстро».
как я понял, протокол 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, то с большей вероятностью, я бы уже скачал бы эту раздачу и все остальные.
UFO just landed and posted this here
кто-то делал расчеты, что уторент может анонсировать не более 320 раздач в dht. там самый главный параметр — время, которое уторент затрачивает на анонсирование 1 раздачи и через сколько минут уторент начнет анонсировать с начала списка раздач. достаточно было бы сделать 1 параметр в дополнительных настройках «через сколько минут начать анонсирование с начала очереди для анонсирования по dht». это бы частично решило бы проблему. open source помогбы уторенту решить баги, достаточно взять уже исправленый исходный код из форка. по моему мнению, наибольшая проблема альтернативных торрент клиентов в их gui графическом пользовательском интерфейсе. у меня проблемы со зрением и уторент это единственный торрент клиент которым я могу пользоваться. еще ishareaza может качать торенты, но не более нескольких раздач одновременно, ищет источники весьма плохо, качает медленно и не лучше уторента. qbittorrent для меня недоступен — у него большие проблемы с экранной доступностью. кое-как, через командную строку я смог добавить торрент-файлы в очередь для загрузки и qbittorrnt одновременно запущеный с уторентом как-то качает полумертвые раздачи. веб-интерфейс в qbittorrent я так и не смог включить. gui для меня почти недоступен, через .ini файл так и не смог установить пароль. все остальные торрент-клиенты для меня недоступны. перепроверил уже много. как-то все очень печально все в мире…
UFO just landed and posted this here
я написал все это к тому что можно было бы внедрить поддержку 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.

Скажите пожалуйста, а как этой библиотекой пользоваться?
Вот поставил я себе:
1. расширение в браузере для ipfs
2. поднял локально ноду.

А как книжки то почитать? Вот прям на пальцах объясните плиз!

Я боюсь, что тут нельзя на пальцах объяснять как пользоваться :) Но если вы уже все установили, то вам остается маленький шаг сделать: попробуйте погуглить фразу "libgen crypt dweb link"

Sign up to leave a comment.

Articles