Pull to refresh

Comments 44

В IPFS же вы говорите: «У меня есть хеш этой книги, кто-нибудь знает, где она?» — и любой, у кого она есть, может помочь.

Звучит, как альтернатива торренту, а не хттп.

Это не альтернатива торренту, это и есть очень близкая к торренту технология. Только если торренты - это в первую очередь P2P замена файлопомоек, то здесь предлагается расширить подход на все сценарии, в которых работает HTTP.

Плохо понимаю как это будет работать для веб страниц с динамическим содержимым. Основную страницу я открыл у Пети, у Васи открыл половину фреймов, а вторую половину - не нашёл.

Абсолютно согласен. Не сработает это в плане сайтов...

КМК откроются просто феерические возможности для слежки за тем кто какой контент потребляет. Как сейчас с торрентами. =)

И подмены контента.

И ддоса всего интернета хД

А как это? Есть какой-то простой способ выдать другой контент по хешу, да еще и так, чтобы функция хеширования выдала ровно вот этот хеш?

Чтобы узнать что это не тот контент его придется скачать. Можно просто перегружатб сеть мусором, а для борьбы с этим всеравно будут нужны центральные узлы.

А что вас в этом смущает? Хеш намного короче самого файла, поэтому всегда можно его подобрать добавкой небольшого количества соли. Насколько эффективен будет такой подбор - зависит от возможности обратить хеш-функцию, и думаю, что такая возможность есть, потому что никто специально не подбирает её по криптостойкости.

Погодите, соль никак не уменьшает стойкость хеш функции. Соль придумали для того, чтобы нейтрализовать использование радужных таблиц (когда одинаковые данные на входе выдают одинаковый хеш. Вот с солью - это не так. Используется чаще всего с паролями), и просто сравнение паролей по хешам (когда с соседнего компа хеш совпадает, значит и пароли совпадают).
И хеш-функции, насколько я помню - все необратимые. Т.е. можно только перебирать все комбинации входных данных, проверяя результат. Но!
Вот тут можно посмотреть данные для SHA-256 (столбец Security against collision attacks
(bits)): https://en.wikipedia.org/wiki/Secure_Hash_Algorithms. 2^128 - это число с 38 нулями. Дальше берем суперкомпьютер (https://habr.com/ru/companies/first/articles/714622/) - у него 18 нулей в производительности. Остальные 20 нулей - это время до нахождения коллизии, 9 нулей отсюда - займут 100 лет. Остается еще 11 нулей - скажем, это надо 100 миллиардов таких суперкомпьютеров в кластер поставить и тогда за 100 лет найдем. И это ведь мы решали куда более простую задачу - лишь нахождения коллизии, а надо куда сложнее - надо вредоносный контент таким образом переупорядочить, не потеряв его смысл, чтобы случилась коллизия хешей с искомым.

В первом приближении да, а на практике всегда возможны неожиданные оптимизации. Я бы лично не стал ставить свои деньги на невозможность подбора коллизии.

2 разных хеш-функции + размер файла в байтах и удачи подобрать точно такую же комбинацию.
ЕМНИП MLDonkey использовал хеш+размер файла для идентификации файла, таким образом один и тот же файл у разных пользователей с разным названием использовался для загрузки пиром.

Это как бы замена ослика и торрента, но не интернета

У меня есть хеш этой книги, кто-нибудь знает, где она?

У меня она есть, но отдам я ее после дождичка в четверг. Я так 15 лет назад использовал MLDonkey для выуживания контента из Kad-сетей. Один редкий фильм на 700 мб выуживался 2 месяца.

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

Поэтому меня всегда смешат заменяльщики чего-то на подобные сети. У этих заменяльщиков опыта с гулькин хвост.

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

ещё не дочитал, но после слов " уязвимости к цензуре", мне уже многое ясно, а "идея IPFS" настолько известна и популярна, что даже я о ней никогда не слышал. впрочем, ладно, пойду дочитывать материал. =)

нфт, блокчейн...

о! - облако!

-- облачный ипфс, без регистрации и смс...

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

То есть, каждый файл получает уникальный хеш, своего рода цифровой отпечаток. Чтобы получить файл, вы просто указываете его хеш, и система ищет его у ближайших пиров, а не на удалённом сервере.

А как это будет работать на триллионах файлов?
Сейчас адресация многоуровневая сервер - путь на сервере - сам файл.
Если мы убираем это все и оставляем только хеш файла, то количество самих разных файлов в интернете колоссально - как проводить поиск расположения файла с конкретным хешем в распределенной сети? Если будет некая база данных, то какого она должна быть размера и где храниться? Если ее не будет, то сколько времени будет занимать такой поиск обходом соседних узлов?

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

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

http тоже преподносился как «свободный от централизации» и прочие красивые слова. И пиринговые сети давно существуют. И всё равно всё вернулось (и вернётся) к клиент-серверной модели. Потому что

1) 70-80% человечества - идиоты в медицинском смысле слова. Системы, смотрящие IP-интерфейсом в глобальную сеть - это надо настраивать, что-то там изучать, это тру-уууууудно. Гораздо проще, чтобы дядя где-то там настроил, а мы нажали клавишу anykey и увидели своих котиков.

2) «Колбасы на всех не хватит». IPv6, который позволит к каждому котику глобальный IP прикрутить, внедряется с огромным скрипом. А IPv4 уже практически исчерпан.

В общем, будет всё как всегда: пиринговые сети останутся уделом немногих, понимающих что это и зачем.

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

Где-то уже используется IPFS?
Несмотря на то, что IPFS пока не стал массовым стандартом, он уже кое-где, конечно, применяется. В частности, в NFT

Вспомнилась эта история с покупателем редких NFT картинок

NFT fail
NFT fail

Честно, IPFS крутая идея, но пока слишком сырая, чтобы менять HTTP.

Главная проблема это доступность. Если никто не хранит твой файл, он просто исчезнет. В HTTP сервер либо есть, либо нет - проще. А тут всё завязано на пиринговой сети, которая нестабильна и медленна.

Экономическая модель вообще не проработана - Filecoin пытается это решить, но пока больше похоже на хайп, чем на стабильный сервис. Кто будет платить и зачем хранить чужие данные?

Юзабилити тоже отстает. Пока не появится простой и удобный способ работать с IPFS - это будет нишевое решение для энтузиастов.

Но самое главное: IPFS не убьёт HTTP, а скорее станет его дополнять там, где нужна децентрализация и устойчивость к цензуре. Не надо ждать революции завтра это долгий путь.

Мой опыт работы с IPFS показывает, что система не готова для широкого круга пользователей. Ее непросто установить и настроить, и она медленная. Кроме того, она обслуживает файлы, а большинство современных систем используют клиент-серверный подход. Я вижу ее скорее как децентрализованный аналог S3.

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

И далее, еще одна важная вещь - бесшовная интеграция с существующим интернетом. Хотя-бы со всеми соцсетями, мессенжерами...

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

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

Это единственный разумный способ наполнить новую сеть контентом. Переносить туда что-то специально - неудобно, а то что удобно (большие монолитные объекты) - эта ниша занята торрентами.

В этом принципиальное идеологическое отличие от современного интернета, где информация "принадлежит" какому-то одному владельцу, а остальные только смотрят. В новой сети информация должна принадлежать всем; один раз попав в сеть, она остается там навсегда - по крайней мере до тех пор, пока есть хоть один человек которому она интересна.

Я к тому что сам по себе IPFS не готовый коробочный продукт. Это всего лишь протокол, но это не замена вконтакте, телеграма и даже хабра. А Brave у меня есть вместе с десятком других браузеров. Только вот как таковым IPFS я не пользуюсь (единственное где я с ним сталкивался - скачивание книг с либгера, и то там скачивание происходит через https).

Сейчас 2 прыжка: клиент - DNS определим IP - теоретически в один прыжок до сервера. Даже если больше, весь маршрут определяется сетевым оборудованием провайдера, а не клиентами. А тут построение маршрута на железки не переложить

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

А мне идея IPFS понравилась.

Я так понял, что я могу настроить приватный IPFS. То есть у себя дома поставить узел, на телефоны своей семьи обеспечил доступ, или может на даже узлы на телефонах. Что лучше. Наверное на IPFS есть контроль доступа. А может и шифрование какое нибудь. То тогда вообще - шикарная вещь. А с IPV6 вообще супер! То есть IPFS для IPV6 просто killer feature! Никакого телеграмма не нужно!!!

Не подскажите, где можно почитать побольше про IPFS? Может книжка какая есть? Пойду поищу.

Для построения такой приватной сети лучше взять syncthing, можно поднять свой discovery и relay и полностью изолироваться от остальных.

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

из обсуждения раздачи архива Флибусты на Рутрекере:

Фантазия на тему зеркал. Библиотека с распределённым хранением данных. Книги хранятся в архивах по 100МБ или около того. Архивы раздаются по bittorrent всеми желающими. Движок сайта получив запрос на книгу обращается сначала к локальному кэшу, если не находит книгу в нём — запрашивает torrent-клиент, который скачивает архив с книгой в локальный кэш и держит в нём, пока тот остаётся востребованным какое-то определённое время. Про IPFS и zeronet знаю, они не взлетели, в отличие от bittorrent, который продолжает использоваться, хоть бум файлообмена и прошёл.

а чего не взлетели и

А почему IPFS ещё не заменил HTTP?

Потому что IPFS выглядит хорошим решением пока не пытаешься им пользоваться. Публикация 50ГБ данных в IPFS уменьшает свободное место на диске на 50ГБ. Нельзя даже шару на симлинках сделать, какая там замена HTTP.

Потому что IPFS выглядит хорошим решением пока не пытаешься им пользоваться. Публикация 50ГБ данных в IPFS уменьшает свободное место на диске на 50ГБ. Нельзя даже шару на симлинках сделать, какая там замена HTTP.

Вообще-то можно хранить только свои файлы. Типа расписание уроков на неделю. Этот файл неинтересен практически никому, кроме горстки учеников 1А класса. А эти ученики сделают этому файлу пин и он будет храниться у них. И никакое облако им не нужно! Где-то так.

Идея хороша но не для сайтов. ....

Те я зашёл на майкрософ и закешировал его весь или не весь..

Допустим не весь. Это похоже на Автономная работа IE в Windows 98.

Допустим вот закешировал.

Теперь Вася хочет открыть сайт Микрософ. За 0.3 секунды..... Но умный алгоритм говорит зачем..... Я сейчас опрошу пользователей .... Я им сейчас про Хэш спрошу...... Но так как нет серверов. Всю инфу будет обрабатывать кто????? Как у торрентов сервер???. Накрыдся ваш сервер хэшей и дальше что????? А Вася ждет.... Пока сотня компов ему хэш предоставит....

По скорости это мусор. По надежности спорно.

Просто будет в браузере галочка Не хэшировать. Наыига мне Микросовф хэшировать да еще на это дисковое место тратить.... Мне и простого хэша хватает с такими интернет страницами.... Доя одноц транички стилей и графики как на игру в пару гигов. Лепят сайты из блоков. И так все тормозит....

Спасибо но нет

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

Я так понимаю, что идея в том, что большой главный сервер (для каждого продукта) - остаётся, как и сейчас, но при этом все устройства превращаются в cdn и могут ему помогать - передавая с себя кусочки контента.

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

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

вижу несколько проблем:

  1. слежение за пользователями станет сильно проще;

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

  3. подмена контента с цель внедрения в него чего-то вредоносного;

подмена контента с цель внедрения в него чего-то вредоносного;

Не должно быть такого, хеш изменится и файл не будет искаться.

DHT (распределённая хеш-таблица)

Это же какого размера будет эта таблица и где будет хранится? А так вспомнился ослик, даже стоял на компе в 2005 году и было интересно поискать разные файлы в локалке местного провайдера.

Ведь юзер не всегда знает какой ресурс ему нужен. Если покупатель приходит в магазин книг он приходит посмотреть что там нового. В блоге что нового, на сайте статей Хабр что нового. Какие новые фильмы в кино. А откуда у меня хэш того что я не знаю?

Sign up to leave a comment.

Articles