вебмастер, фидошник
0,0
рейтинг
5 октября 2015 в 18:23

Администрирование → Почему Интернету нужен IPFS, пока ещё не поздно перевод

[узлы к узлам]

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

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

Как и почему это? Для ответа на этот вопрос придётся вдаваться в подробности.

Почему наша Всемирная Паутина медленна, непрочна и забывчива


IPFS является новым p2p-гипермедийным протоколом, цель которого — дополнять собою (или даже, может быть, заменить) протокол передачи гипертекста (HTTP), сейчас господствующий в WWW. Вот в чём проблема HTTP: сегодня, когда вы посещаете сайт, ваш браузер должен напрямую связываться с серверами, на которых этот сайт работает, даже когда серверы эти далеко, а процесс передачи требует немалой пропускной способности.

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

Вот почему и вот в каком положении дел мы застряли: медленный и дорогостоящий Интернет, цена которого ещё возрастает в силу хищничества провайдеров «последней мили» (по меньшей мере, в США), и с ускоряющимся ростом запросов на соединение с мобильных устройств. Он не просто медленный и дорогостоящий, но и ненадёжный. Если хотя бы одно звено HTTP-передачи оборвётся по любой причине, то оборвётся и передача. (А когда веб-страница или медиафайл грузятся долго, то, скорее всего, виною тому одно из межкомпьютерных соединений.)

Переделываем Интернет посредством IPFS


IPFS (InterPlanetary File System, то есть межпланетную файловую систему: это название — дань памяти идеям Дж. К. Р. Ликлайдера о «межгалактическом» Интернете) придумал Juan Benet, который подростком приехал в США из Мексики, в Стэнфорде получил степень по информатике, основал компанию, приобретённую «Yahoo!» в 2013 году, а в прошлом году при посредстве Y Combinator основал Лаборатории Протокола (Protocol Labs), которые сейчас занимаются проектом IPFS и скромно намерены переменить те протоколы, которые последние 20 лет были для нас повседневным явлением жизни.

IPFS — это P2P-распределённая файловая система, стремящаяся соединить все вычислительные устройства одной общей системою файлов; как таковая, она способна превзойти возможности HTTP в нескольких отношениях. Из них два (как сообщил мне Хуан в недавнем разговоре) являются ключевыми:

«Мы используем контентную адресацию, поэтому контент приобретает независимость от серверов первоисточника и может храниться отдельно и долговременно. Это значит, что контент может храниться и раздаваться очень недалеко от потребителя — быть может, даже компьютером из той же самой комнаты. Контентная адресация также позволяет и проверять данные, полученные от других (не доверенных) хостов вместо первоисточника. А когда контент попадает на устройство пользователя, его там можно кэшировать сколько угодно».

IPFS также устраняет некоторые проблемы безопасности, досаждающие нашему основанному на HTTP Интернету: основанная на контенте адресация (и последующая верификация) защищает основанные на IPFS сайты, распределённость IPFS делает DDoS-атаки невозможными. Помогая смягчить ущерб от закрытия сайтов их владельцами, IPFS также кэширует в себе важный для общества контент и может невозбранно сохранить его.

Главнейшим же из достоинств IPFS служит децентрализованная раздача контента, так что к контенту из Интернета можно обращаться в обстоятельствах нерегулярного доступа к Интернету и даже брать его из оффлайнового кэша. «Мы создаём сайты и веб-приложения, не имеющие центрального сервера-источника, — пояснил Хуан. — Они могут быть распределёнными подобно тому, как распределённою является сеть Bitcoin». Этого-то HTTP просто не может добиться, так что IPFS послужит во благо сетей, не имеющих первоклассных взаимосвязей (например, в развивающихся странах или в сельской местности).

Появление альфа-версии IPFS в прошлом феврале ужé повлекло за собою множество экспериментов среди ранних восприёмников её (early adopters). Например, 8 сентября хостинг Neocities стал первым крупным сайтом, пользующимся IPFS для хранения контента, то есть последовавшим призыву Internet Archive о необходимости распределённого WWW. В настоящее время все мы претерпеваем непрестанную утрату всё новых и новых сайтов, год за годом покидаемых и закрываемых их создателями, и в этом нарастающем кризисе нашей коллективной интернетовской памяти для нас важен даже малый шаг в сторону перманентной Паутины.

А сайты, принадлежащие крупным корпорациям, последуют ли примеру Neocities, начнут ли внедрение ещё не полностью протестированного протокола — особенно когда даже простое упоминание P2P способно привести их в ужас? А вот тут я подхожу к последнему пункту статьи.

Почему IPFS весьма значим для будущего интернет-бизнесов


Как я разъясняю в моей новой книге (публикация которой ещё впереди), мы быстро приближаемся к той точке, за которою стоимость доставки контента опередит полезность — и финансовую выгоду. Крупнейшие компании Интернета ужé изо всех сил стараются не отстать от нашего спроса на контент, целые армии инженеров заняты одной этой задачею и в Akamai, и в Google, и в Amazon.

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

Нам ужé до крайности необходимо ограничение того эффекта, который я называю микросингулярностью: быстрое «вирусное» привлечение пристального внимания биллионов пользователей Интернета к одному и том же событию угрожает удушить собою всю систему. (Перебои в работе сети теоретически угрожают и жизни, когда микросингулярностью становится катастрофа, авария или другое явление того же рода.)

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

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


Послесловие от переводчика


Хабрахабр — это даже не Кремниевая долина, так что и здесь, как можно предполагать, к началу октября 2015 года не все ещё читатели составили для себя достаточное представление об IPFS. Следовательно, окончив перевод статьи из TechCrunch, мне придётся также приложить к ней определённое разъясняющее послесловие; и прилагаю, облекая его в форму вопросов и ответов.

— Что такое IPFS?

— Распределённая файловая система с контентной адресацией.

— В каком смысле система IPFS является распределённою?

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

— В каком смысле система IPFS является файловой системою?

— В прямом: если ваша операционная система является юниксоподобною, то при помощи FUSE можно подключиться к IPFS таким способом, чтобы видеть файлы IPFS по адресу «/ipfs/хэш_файла» у себя в файловой системе.

— В каком смысле система IPFS является контентно-адресуемою?

— Хэш файла зависит только от содержимого файла. Если файл имеет другое имя или лежит в другом подкаталоге, то это всё равно тот же файл. (Это выгодно отличается, например, от битторрентовского хэша BTIH, который изменяется в зависимости от названия и взаимного расположения файлов.) Если тот же самый файл раздаётся под другим именем или в составе другого подкаталога, раздачи автоматически объединятся, не потребуется удвоение усилий, траффика, пространства на диске.

— Есть ли в файловой системе IPFS подкаталоги?

— Есть; это списки имён (и хэшей) файлов и подкаталогов. Например, для открытия адреса «/ipfs/хэш_каталога/имя_файла» сперва скачивается каталог (по его известному хэшу), затем по имени файла в каталоге выясняется тот хэш, при помощи которого IPFS будет качать файл. Каждое имя подкаталога добавляет один шаг к этому процессу.

— Как узлы IPFS знают, у каких из них есть желаемый файл?

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

— Как сайт нынешней Всемирной Паутины может сослаться на файл, лежащий в распределённой файловой системе IPFS?

— Автор сайта ставит себе IPFS и кладёт файл в IPFS. Затем он записывает «https://ipfs.io» перед IPFS-путём файла и получает, например, «https://ipfs.io/ipfs/QmcXx5mKDQAc7tCWLq84Hn7XFxWfBdZpvogJk3tNXQRFiv». Сайт «https://ipfs.io» работает как гейт из IPFS в WWW, так что читатели, у которых поддержка IPFS не установлена, могут с этого сайта получить файл.

— А читатели, у которых поддержка IPFS установлена?

— А у них появляется личный гейт из IPFS. Остаётся только поставить такое дополнение для Firefox или расширение для Chrome, которое будет «127.0.0.1:8080» автоматически подставлять вместо «ipfs.io» в таких URLах.

— Каким образом IPFS спасает в случае нарушений в работе сети?

— Если иллюстрации (и другие файлы) с самого начала публиковать не по сайтовому адресу, а в IPFS, то тогда, даже если сайт упадёт, читатель всё равно может получать файлы по известному адресу, только не из сайтового кэша IPFS, а из кэша у соседа. (И сосед не сможет подменить файл, потому что будет проверяться соответствие файла хэшу.)

— Каким образом IPFS помогает сайтам экономить траффик?

— Если иллюстрации (и другие файлы) с самого начала публиковать не по сайтовому адресу, а в IPFS, то тогда, даже если вдруг случится микросингулярность и на сайт очень быстро придёт биллион зрителей, всё равно бóльшая часть их будет по IPFS стучаться не на сайт, а в кэш своим соседям по биллиону, успевшим чуть раньше. Так что сайт не приляжет. (Конечно, для этого сперва среди зрителей должна распространиться мода на IPFS, а не то вместо сайта приляжет гейт «https://ipfs.io», например.)

— Каким образом IPFS помогает сайтам в случае гибели диска?

— Если иллюстрации и другие статические файлы с самого начала публиковать не по сайтовому адресу, а в IPFS, то тогда можно будет пропавшие картинки (и другие файлы) скачать по IPFS из кэшей читателей сайта в случае чего.

— Каким образом IPFS помогает читателям в случае государственной цензуры?

— Если иллюстрации и другие статические файлы с самого начала публиковать не по сайтовому адресу, а в IPFS, то тогда можно будет запрещённые иллюстрации (например, иллюстрации к ранобэ «精霊使いの剣舞») и другие запрещённые файлы получать по IPFS в обход блокировки (из кэшей читателей сайта, успевших получить файлы до вступления цензуры в силу).
— Каким образом IPFS помогает сайтам экономить дисковое пространство?

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

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

— Совершенно верно. (Я предлагал эту альтернативу на Иичане, например.)

— Есть ли прямо сейчас пример такого хостинга картинок, который складывает картинки в IPFS?

— Есть, ipfs.pics.

— Есть ли прямо сейчас пример такого хостинга произвольных файлов, который складывает их в IPFS?

— Есть, http://ipfs.stadja.net/upload/ Увы, нет: закрылся.

— Означает ли контентная адресация, что в IPFS можно хранить только статический (неизменный) контент?

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

— Может быть, придумать новую схему URLов для IPFS? Это позволит записывать их короче, чем длинноватый адрес «https://ipfs.io» перед хэшем.

Две недели обсуждали и решили остановиться на схеме «fs:», предшествующей такому пути в файловой системе, который начинается на «/ipfs/» или на «/ipns/».

— Почему не сделали две раздельные схемы «ipfs:» и «ipns:»?

— Для удобства пользователей юниксоподобных систем, которым теперь достаточно стереть три символа «fs:», чтобы получить путь. (А не то переправлять ещё возиться.)

— Будут ли адреса «fs:» поддерживаться в гипертекстовом Фидонете?

— Будут; для этого достаточно трёх строк на языке ECMAScript 6. Вот пример фидонетовской блогозаписи, сперва снабжённой иллюстрацией из IPFS, а затем транслированной по RSS в LiveJournal.

— Можно ли добавить поддержку открытия адресов «fs:» в редактор фидопочты GoldED-NSF?

Можно:

GroupURL IPFS
   URLEngine PCRE
   URLScheme /ipfs/[1-9A-HJ-NP-Za-km-z]+
   URLHandler start "" "https://ipfs.io@url"
EndGroupURL

— Работает ли IPFS под Windows?

Нынешняя альфа-версия под Windows работает довольно скверно, но предыдущая вообще переставала запускаться, так что можно надеяться на дальнейшее улучшение положения дел в будущем, и надеюсь.
Перевод: Amber Case
Mithgol the Webmaster @Mithgol
карма
60,5
рейтинг 0,0
вебмастер, фидошник
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (98)

  • +26
    Я уже боялся, что про г-т фидонет ничего не будет.
    • +6
      В конце блогозаписи про юбилей Фидонета был тизер-трейлер про внедрение IPFS в Фидонете, так что вот теперь я раскрыл ту тему, на которую тогда намекал.
    • +6
      Несомненно, ключевым аргументом ipfs в статье смотрится фрагмент конфига Голого Деда. Куда же сейчас без него!

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

      Искренне ваш,
      ex. 2:5070/44
      • +2
        Это не некрофилия, потому что Фидонет в известной мере жив. Жизнь эта будет нарастать в нём.
  • +3
    Спасибо. Интересная альтернатива чистому p2p интернету, в котором будет работать только статика нормально. В этом варианте можно использовать смешанное содержимое, которое позволит снять часть нагрузки.
  • +3
    — Хэш файла зависит только от содержимого файла. Если файл имеет другое имя или лежит в другом подкаталоге, то это всё равно тот же файл. (Это выгодно отличается, например, от битторрентовского хэша BTIH, который изменяется в зависимости от названия и взаимного расположения файлов.) Если тот же самый файл раздаётся под другим именем или в составе другого подкаталога, раздачи автоматически объединятся, не потребуется удвоение усилий, траффика, пространства на диске.


    Я немного совершенно не понял — как они собираются бороться с коллизиями? так и вижу, как на серьезном сайте вместо фотографии крупного директора загружается пони или котики или что по-хуже потому что коллизия
    • +1
      Там очень большие хеши. Боюсь, что вероятность коллизии будет много ниже вероятности того, что, например, упомянутого крупного диктора просто собьет машина на улице…
      • 0
        Тем не менее вероятность !=0.
        Случайно может будут редкие совпадения. Но с теми же хешами есть разные варианты атак, поэтому важна криптостойкость, а не только длина.
        • 0
          В таком случае вам не рекомендуется использовать гуиды во всех проявлениях.
          • 0
            Кто-то использует guid как криптоподпись?
            • 0
              Как ID в распределенной системе — легко. А к чему может привести коллизия уникальных идентификаторов — кто знает, от простой пропажи одной записи в БД до отказа в обслуживании и сливания всей инфы на сторону.
              • 0
                Как id — понятно.
                А вот как подпись?
                Во, т кстати, совсем скоро увидим коллизиии — habrahabr.ru/post/268495
                То есть подменить файл и чисто количественно задавить раздачу вполне реально.
                Но еще лучше подменить адреса машин, откуда узлы должны узнавать друг про друга — т.е. просто развалить сеть на части.
                • 0
                  На всякий случай сообщаю, что по адресу http://habrahabr.ru/post/268495/ речь идёт о поиске коллизий в SHA-1, тогда как IPFS, во-первых, использует более современный хэш SHA-2, а во-вторых, употребляет вокруг него такую обёртку (в виде мультихэша), которая позволит в случае необходимости перейти (по общему согласию) от употребления SHA-2 к употреблению ещё более современного хэша, вовсе не трогая остальную логику работы системы (и, весьма вероятно, с некоторым переходным периодом, когда оба хэша будут приниматься к употреблению, но только более новый будет создаваться для дальнейшего употребления).
  • +1
    Получается при заходе на страницу я ее буду качать и хранить у себя как некий кэш, который у меня потом могут взять другие или файл. OK
    Что делать если у меня мало место?
    При изменении динамики, насколько быстро распространится изменения.
    Будет ли полная перекачка файла или только изменения файла?
    Как распределяются права к файлам? Можно ли сделать больше одного человека, который имеет RW права на папку?
    Как быть, если кто-то удалил все файлы в каталоге или сам каталог?
    Как быть с коллизиями?
    • +1
      Если Вы простой посетитель с одним только браузером, то Вы просто скачаете картинку через гейт по обычному http.

      Чтобы получить p2p, нужно ставить локальный софт. Очевидно, что настройки объема локального хранилища там должны быть.
    • +1
      Мало места — мало кэша.

      Изменения динамики распространяются по мере повторных заходов.

      Будет полная перекачка файла.

      Никто не имеет RW-права на папку, потому что по факту там WORM: изменённые файлы и папки рассматриваются как новые.

      Коллизий нет.
      • +4
        Коллизий нет.

        Это невозможно. Коллизии могут быть маловероятными, но совсем исключить вы их не можете.
        • 0
          Там хэшем служит SHA2-256, то есть, как я понимаю, 32-байтовое (256-битовое) число.

          Вероятность коллизий ничтожна (что-то порядка квадратного корня из 10−77, если я это правильно понимаю), так что я не верю, что они есть.
          • 0
            Вероятность коллизии в 0.5 достигается после 4 × 1038 файлов (да здравствует «парадокс» дней рождений). Называть это ничтожным я бы не стал.
            • 0
              Ну да, именно из-за парадокса дней рождений я и заговорил именно о квадратном корне.

              А что касается 4×1038 (2128) файлов, то это очень много. Рассудим теоретически:

              • для записи одного из двух различных файлов достаточно однобитной длины,
                 
              • длина файла от одного до двух битов позволяет записать один из 21+2² различных файлов,
                 
              • длина файла от одного до трёх битов позволяет записать один из 21+2²+2³ различных файлов,

              так что если у нас есть 2128 различных файлов, то их длина варьируется (по меньшей мере) от бита до 264 битов, причём файлов размером 264 битов около половины, так что и средняя длина где-то там.

              Следовательно, суммарный размер этих файлов — что-то около 2128×264 битов = 2192 битов = 2189 байтов = 2179 килобайтов = 2169 мегабайтов = 2159 гигабайтов = 2149 терабайтов = 2139 петабайтов = 2129 эксабайтов = 2119 зеттабайтов = 2109 иоттабайтов… дальше понятно.
              • 0
                Хотя нет, что это я несу. Последние два абзаца предыдущего рассуждения на самом деле должны были быть вот какими:

                …так что если у нас есть 2128 различных файлов, то их длина варьируется (по меньшей мере) от бита до 64 битов, причём файлов размером 64 бита (26 битов) около половины, так что и средняя длина где-то там.

                Следовательно, суммарный размер этих файлов — что-то около 2128×26 битов = 2134 битов = 2131 байтов = 2121 килобайтов = 2111 мегабайтов = 2101 гигабайтов = 291 терабайтов = 281 петабайтов = 271 эксабайтов = 261 зеттабайтов = 251 иоттабайтов… дальше понятно.
          • 0
            Допустим, вероятность случайных коллизий настолько низка, что можно не беспокоиться об этом. А как IPFS защищается от флуда специально созданными мусорными файлами, в которых подобран хэш какого-нибудь полезного (или неугодного кому-то) файла?
            • +1
              в которых подобран хэш

              Там хэшем служит SHA2-256, то есть, как я понимаю, 32-байтовое (256-битовое) число.

              То есть подбирать нужно примерно до тепловой смерти Вселенной.
      • 0
        Ну тогда тут вопрос спорный, зачем оно надо. Гложут сомнения что это взлетит.
        • +1
          Минимум — защита от цензуры.
          • +1
            Насчет цензуры есть несколько вопросов. Протокол ведь будет отдавать IP адреса всех, у кого есть этот контент? Всех можно и взять будет (до кого дотянутся) за распространение. И второе, про гейт. Гейт отдает только IP адреса централизованно?
          • 0
            Для этого лучше подходят мех сети и я думаю лучше их развивать. Например Cjdns. hyperboria.net
            • +1
              Имхо, одно другому не мешает. Кеширование статики может работать как поверх обычного интернете так и поверх CJDNS — ведь она по сути придоставляет IPv6. Параноики могут раздавать кеш только через интерфейс tun от cjdns. В идеале бы людям, которые способны установить одно, ставить и другое, но для того как раз раскручивание на хабре. Надеюсь, когда тут был цикл статей о меш сетях, многие не поленились и поставили ноду (тем более под убунту это ставится из пакетов). Я еще купил и прошил роутер под это дело и жду соседей (:
              • 0
                Сегодня нашел время и поставил ipfs, если можно так выразиться: приложение на го — это один исполняемый файл, который надо только положить и запустить. В общем, оно работает и радует, и тут же через мой CJDNS подхватилось пять пиров сразу без ручного поиска. Т.е., как я и предполагал, есть те, кто осилил и то и это. (:
    • +1
      Никаких изменений. Любое изменение = новый файл.
      • 0
        почему вы так считаете?
        • 0
          Потому что идентификатор файла в IPFS — его содержимое. Это, кстати, позволяет более эффективно использовать популярные файлы, они хранятся только один раз в кеше.
          • 0
            Хранятся не файлы, хранятся блоки, которые могут быть реиспользованы в различных версиях файла:
            IPFS files can be represented by both lists and blobs
    • 0
      Как я понял, используется «Git Merkle DAG 2 object model» и при изменении файла будет скачивание только изменений, а не всего нового файла.
    • 0
      Получается при заходе на страницу я ее буду качать и хранить у себя как некий кэш, который у меня потом могут взять другие или файл. OK
      Что делать если у меня мало место?

      Можно регулировать, сколько места отдавать под кэш. Или по аналогии с тонкими bitcoin-клиентами вообще ничего не сохранять на диск.

      При изменении динамики, насколько быстро распространится изменения.

      Динамика хранится в виде изменяющихся ссылок на статику в системе IPNS (IP Naming System), как ref'ы в Git. Изменения в них распространяются не мгновенно, но являются атомарными, т.е. если выложить новую версию сайта, хэш его корневого элемента будет новым, и новую версию увидят только те пользователи, которые получат новое значение через IPNS.

      Конечно, сайт может ссылаться не только на объекты IPFS, но и на записи в IPNS, но это разбивает его на несколько атомарных частей, так что с этим надо быть аккуратней.

      Будет ли полная перекачка файла или только изменения файла?

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

      Как распределяются права к файлам? Можно ли сделать больше одного человека, который имеет RW права на папку?

      В IPFS единственное понятие, на которое распространяются права — это запись в IPNS. Менять её может только владелец ключа шифрования, которым эта запись адресуется. Они планируют что-то поменять, чтобы можно было одним ключом менять несколько записей в IPNS, но я не видел, чтобы они хотели дать возможность менять одну запись несколькими ключами (что печально и сильно ограничивает область применения).

      Как быть, если кто-то удалил все файлы в каталоге или сам каталог?

      IPFS хочет заменить интернет (ну почти), а что попало в интернет, как известно, не вырубишь и потребнадзором топором. Удалить можно только ссылки на контент из IPNS, но если этот контент кто-то уже скачал, никуда он больше не денется. По аналогии с DNS, придётся искать этот контент не по ключу в IPNS (как доменное имя), а по хэшу контента (как адрес), но контент останется доступен (даже если у вас угнали домен).

      Как быть с коллизиями?

      Не париться по их поводу пока, менять алгоритмы хэширования потом, см. другие комменты.
  • +4
    Присматривался к ipfs для раздачи статики на своем сайте. Остановило неумение раздавать целые каталоги прямо с диска. Т.е. мне для раздачи нужно каждый файл залить в локальное хранилище ipfs и по факту имеет две копии: одна копия в обычной fs (ибо ipfs не обеспечивает весь локальный функционал), вторая — в ipfs. Когда файлов — сотни гигабайт, такое дублирование становится расточительным и бессмысленным :—/

    А в остальном система очень понравилась. Ещё бы чисто браузерную реализацию (js, webrtc), чтобы простой юзер мог бы качать минуя гейт, но при этом не устанавливая дополнительный софт, цены б ей не было :)
    • 0
      Работы над изготовлением реализации IPFS на языке JavaScript ведутся потихоньку.
      • 0
        NodeJS — увы и ах, никак не «чисто браузерная реализация» и в оную, скорее всего, не перерастёт. Общ у них лишь язык, но не среда исполнения.
  • +1
    А что мне мешает на гигабитном канале сделать dd if=/dev/urandom of=/ipfs/flood_file bs=1G count=1000000 и уложить всю сеть?
    • +3
      А кто будет ЭТО качать? p2p — это не когда тебе подсовывают всё, что не нужно. Это когда ты у других берёшь то, что нужно.
      • +1
        Так если оно не дублицируется, тогда зачем нужно. Ну и атаку на хештаблицу можно устроить так же.
        • +3
          ipfs — это не распределённое хранилище. Это распределённый транспортный протокол с попутным кешированием. p2p-транспорты не менее, а скорее более востребованы, чем [анонимные] p2p-хранилища.
          • +4
            Ну и получим мы в итоге, что будет кэш только самого популярного и востребованного. Мы это и наблюдаем в текущий реализации торрентов, когда нужно скачать что-то и сидишь ждешь когда появится кто-то у кого оно есть.

            Но подход понятен, это как у MS с обновлениями по P2P, хочешь не хочешь а будишь раздавать.
          • 0
            О-о-о, т.е. это совершенно не замена тому же tahoe-lafs?
            • 0
              Нет. Tahoe — это хранилище. IPFS — транспорт (хотя и с локальным кеш-хранилищем, но не распределённым, как tahoe). В принципе, они могут быть хоть совмещены. tahoe как средство распределённого хранения, а ipfs — транспорт для передачи клиенту (не требующий, в отличие от tahoe установки клиента)
  • +5
    Все хорошо в этом переводе, кроме стилистики, которая забирает на себя больше внимания, чем следовало бы.
    • +4
      Да ладно вам Мицгол переводит лучше многих «штатных» переводчиков.
      • +10
        Видимо, тем самым балансирует, чтобы слишком хорошо не получилось.
  • +6
    Мне казалось или в p2p сетях обычно долгое ожидание начала загрузки? Если они не решат эту проблему, то протокол уже мертв.

    Экономия трафика — прекрасно, но не в ущерб скорости загрузки.
    • +8
      +1
      Пока дождешься установления соединения, потеряется всякий интерес к старнице.
      Многие исследования говорят, что если веб-страница не загрузилась за 3-5секунд, то среднестатистический пользователь её закрывает.

      Протокол уже мертв.
      Про кэширование на устройстве: ну незнаю, насколько это хорошая идея, ведь есть сайты, на которых контент меняется очень-очень часто — всякие чаты, доски обновлений, популярные форумы. Кэширование будет создавать эффект, что на этом сайте ничего не происходит, выдвигаемый контент будет опаздывать, итд итп. Да, сайт может поставить какой-нибудь псевдо-флаг «не кэшировать», но тогда теряется вся суть «СПАСИТЕЛЯ ИНТЕРНЕТА». Я молчу про то, больше половины пользователй интернета сидят с телефонов и планшетов.

      Насчет Ддос: всю тяжесть ддосов будут нести не владельцы сайтов, а пользователи, на которых схэшировалось довольно много файлов. Если у пользователя узкий канал, или он играет в онлайн игры, или у него нет SSD, то всё для него будет весьма печально- страницы будут загружаться медленнее из-за высокой отдачи, онлайн-игры будут лагать и вырастут пинги, если всё у пользователя крутится на одном HDD то о нормальной работе на ПК можно забыть — HDD будет постоянно занят, снижая свою производительность, т.е. все программы будут запускаться гораздо дольше.

      «И всё ради чего?» -спросит себя пользователь, и снесет всю эту лабуду, чтобы нормально пользоваться СВОИМ компьютером, а не для того, чтобы всякие владельцы сайтов снижали с себя расходы.
      • 0
        Кэшироваться с адресацией по контенту будет только статика. Для изменяемых частей сайта используется адресация через ipns
      • +1
        Полагаю, что реализация ноды будет позволять настроить количество используемых ресурсов, а не как вы предположили, отбирать у пользователся всю производительность его компьютера
    • +1
      ipfs интересен тем, что в нём реально получается небольшое время ожидания. Что-то типа tor. Не сравнить с i2p или freenet/gnunet.

      И речь именно о холодном ожидании. Как закачалось в кеш — отдаётся мгновенно.
      • –1
        Я изучал причины задержки p2p протоколов на примере nmdc и пришёл к выводу, что причины в плохой реализации. Если использовать более продуманный протокол, то задержки будут минимальны, если вообще будут.
        Например, есть способ вообще гарантированно увеличить скорость передачи данных, а не вносить задержки. Но это зависит от реализации. Проще говоря — тут надо не думать, а делать.
      • 0
        Задежки уровня tor подойдут только для видео. Для картинок они уже будут слишком большими.
        • 0
          Если быть совсем точным, то задержки _холодных_ данных в ipfs сравнимы с задержкой _горячих_ данных в tor. Горячие же данные в ipfs отдаются с обычной для web'а скорость. Ну, вот, чтобы не быть голословным, залитая мной картиночка в ipfs: gateway.ipfs.io/ipfs/QmTUeRKutKfbTRmoXsgRTv4r9zKJyFVrX3NVLQctRmoa1v
  • +3
    Всё-таки неплохо было бы перечитывать перед публикацией. Биллион — это миллиард, да и ещё мелочи цепляют глаз.

    По теме же, кажется, время этой системы ушло, не наступив. Кэширование на локальной машине — это неплохо, но в связи со всё уменьшающейся «толщиной» юзерских машин, кажется, не случится.

    Могу понять мечту об анархизме, но без скоростных И дальнобойных каналов «точка-точка» никакого анархизма не случится. А как пропустить через радиоэфир гигабиты — не представляю.

  • 0
    Нужно придумать все таки систему управления правами и авторством. Иначе это никак не поможет ютубу тому же.
  • –5
    Украли мою технологию Peering cloud :-) Я подошёл немного с более приземлённого решения использовать nmdc протокол и его хабы. В дальнейшей перспективе — это так же превратиться в протокол передачи данных. А сегодня это помогает мне раздавать статику. Исходный код здесь: https://github.com/master255/ImmortalPlayer
    Рабочая программа здесь: https://play.google.com/store/apps/details?id=com.medialibrary.mycollection

    Должен заметить, эта технология может совместно сосуществовать с другой моей очень обсуждаемой (http://habrahabr.ru/post/267329/) технологией DoubleDomain.
  • +3
  • 0
    Интересная вещь, возможно найдет свое место в корпоративных сетях, но вот в качестве замены интернету нет.
    Тут уже писали, про то, что есть коллизии… Теоретически я могу насоздавать у себя кучу файлов с текстами этих хешей… и тогда мне не нужно будет кого то там DDOS ить, вирус люди скачают себе сами.

    Возможно эта штука будет полезна для больших сетей, раздающих контент, таких как youtube, vk. Если все большие контент хранилища перейдут на этот протокол, то возможно интернет уже почувствует облегчение. От пользователя к пользователю — это долго, не безопасно и не нужно, есть торрент в конце концов.
    • +1
      Попробую объяснить на примере.

      Допустим, что по хэшу «QmQZB43ePCwDsow74gehT8v74M2tKtTs9FCbH4wpoUksfF» находится текстовый файл, состоящий из единственного слóва «Хабрахабр» (в UTF-8 с сигнатурою).

      Внимание, вопрос: сколько лет придётся работать над достижением цели «вирус люди скачают себе сами» (то есть над достижением коллизии), если строка «QmQZB43ePCwDsow74gehT8v74M2tKtTs9FCbH4wpoUksfF» состоит из 46 символов в формате base58, являющихся мультихэш-обёрткою вокруг SHA2-256?
      • 0
        Прибавлю, что хэши SHA-256 используются и в Bitcoin, так что, если бы коллизии и впрямь были такой проблемою, то сперва их первооткрыватели немало озолотились бы, а затем биткоины резко обесценились бы. Мы не видим ни того, ни другого.
        • 0
          Вопрос времени и необходимости. Мир уже не один раз проходил стадию, вот мы сделаем и теперь точно хватит на всегда!
          • +2
            Вопрос вычислительной сложности. Сейчас, если я ничего не путаю найти коллизию в SHA-256 можно за 265 операций, но это просто коллизия. Семантическая коллизия (т.е., подбор такого исходника, который выполняет нужную вам функцию, и который бы совпадал по хэшу с другим исходником, выполняющим другую нужную вам функцию) не факт, что вообще возможна.
          • 0
            Понятно, что конкретный хэш (SHA-256) не навсегда. В том числе поэтому существует обёртка в форме мультихэша, которая позволит в случае чего перейти к употреблению другого конкретного хэша в IPFS, не трогая ничего более в логике работы файлообмена.
            • 0
              Вот я создам 2^65 файлов (сейчас вряд ли, но когда нибудь в будущем) где будет строка s = 'Уникальный хеш'. То есть получается я переберу все варианты из 2^65. (Хеш в исходнике может не совпадать с хешем самого файла). Ну даже если не 2^65, а меньше… все равно будет вероятность, что мой код будут считать за другой файл.
              • 0
                Это замечание по сути верно, но по формулировке не совершенно справедливо, так что я выскажу к нему две поправки.

                Во-первых, хэш SHA-256 является (насколько я его понимаю) 256-битным, так что вместо 265 файлов понадобится 2256 файлов, а это гораздо больше.

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

                (Это для хранения, но задача их генерации также никак не может быть названа простейшею.)
              • 0
                Так, для сравнения, оценка количества атомов во вселенной ≈1080,
                а 2256 всего на три порядка меньше
                • 0
                  Ну в статье приводится вполне конкретный хеш:

                  QmcXx5mKDQAc7tCWLq84Hn7XFxWfBdZpvogJk3tNXQRFiv

                  вот и возник такой вопрос.
                  • 0
                    Этот хэш состоит из сорока шести пятидесятивосьмеричных цифр.
                    • –2
                      ну а это уже = 5846 < 2 51
                      • 0
                        По-моему, по меньшей мере, 5846 > 3246 = (25)46 = 25×46 = 2230.
        • 0
          А это надёжней чем TTH? Если да, то на сколько?
          • +1
            Что вы понимаете под TTH? Если Tiger, то где-то на десять десятичных порядков, если по birthday attack смотреть.
    • 0
      Файлы передаются блоками от разных пользователей
      • 0
        ну у блока тоже есть какой то размер, вполне вероятно что мой файл скачают сразу весь и от меня.
  • 0
    Вот ведь копирайтеры-то обрадуются: каждый «клиент» в таком p2p-интернете есть распространитель контента — это просто подарок им: «письма счастья — в каждый дом».

    Законодательно исключить такой p2p-интернет, чтобы логика не попадала под распространение с нарушением авторского права (aka copyright law, Urheberrechtsgesetz и иже с ними) — та еще проблема, имхо.
    По крайней мере в известных своей бюрократией странах.

    Где-то читал около-юридическую статью на похожую тему — реально обсуждалась идея с хранением origin. Чтобы значит копирайтера туда отправлять. Про-то как технически реализовать такой бред… лучше не здесь, а то сильно толсто получится.
    • +1
      Вы сейчас слово «копирайтеры» не вон в том значении употребили, правда ведь?
    • 0
      Думаю, что лессиговский принцип «code is law» будет действовать, то есть трудновато будет в связи с появлением новой программы буквально каждого читателя Сети бросить за решётку или штрафовать (сейчас провайдеров не сажают же и не штрафуют за распространение, например).
      • 0
        К сожалению, вы не правы, и во многих странах уже несколько лет как штрафуют, поэтому пользоватся p2p (тот же торрент) ой как небезопасно для собственного кармана.

        А штрафы кстати не маленькие: ~ 800 за фильм или ~ 300 за песню (в вечнорастущих).
        К тому же право как правило прецедентное или близко к тому, то есть судья и не силно долго разбирается, и если просто из принципа попробовать все же в суде, еще и все судебные издержки в случае очень вероятной неудачи оплачивать.

        А провайдер вообще не причем, он просто тупо сливает (ибо обязан) домашний адрес «распростронителя» по IP+timestamp адвокату «потерпевшей» стороны, по предьявлению им прокурорской авизо.
        И это например в тех же Европах поставлено на поток, т.е. дело нескольких минут.
        • 0
          а есть ли прув на пример такого дела из-за торрент раздачи? И как можно систематизировано проверять торрент раздачи, если файлы раздаются частями, ссылки на эти файлы находятся на каких-то не понятных форумах, а в раздаче попеременно участвуют сотни ip адресов.
          Что, неужели на поток поставили отслеживание всех торрент трекеров в интернете???
          Если да, то как :-)?
          Что с другими п2п сетями? Например dc++? Там вроде всегда было больше контента, чем в торрентах.
          • 0
            Прувов в сети немерено, гуглить по Abmahnung Filesharing «Urheberrechte verletzt» (это если на немецком например).
            Без разницы, какая p2p сеть — filesharing есть filesharing.
            По поводу остального как-то отвечал уже на хабре. Но с тех пор все гораздо хуже (строже).
        • –2
          я уже не раз говорил, что введение подобных фич в странах типо нашей просто приведет к тому, что в торрент-клиент будут встраивать тот же CJDNS или тор. Т.е. активно внедряться механизмы скрытия своего адреса. Если в Европе в контексте данной ситуации мораль рабов выигрывает (проще заплатить за каждую лицензию не по разу, чем заморачиваться), то у нас после девальвацией уже есть резон вникнуть и установить.

          CJDNS вообще отлично получается — скорость максимальная, нет специального прогона трафика где-попало, но при этом бегать по цепочке нод ради каждого раздающего, чтобы найти его обычный айпишник — нафиг кому-то надо. Особенно если этот умник еще и счастливчик, и у него часть трафика ходит через реальным меш!
  • +1
    — Есть ли прямо сейчас пример такого хостинга произвольных файлов, который складывает их в IPFS?
    — Есть, ipfs.stadja.net/upload

    Уже нет :D fucking russians :D :D
    image
    • 0
      О как.
  • +1
    А что с провайдерами будет? Сейчас, наверняка, есть некие оптимизации. Юзеры обычно отдают мало, качают много, причем основной траффик известно с каких сайтов. А тут появится куча траффика там, где отродясь не водилось. Ну, если появится, конечно, если взлетит.
    • 0
      Провайдерам регионального уровня это будет выгодно, потому что больше траффика будет переходить в локалку из глобалки, так что меньше придётся тратиться на доступ к магистральному каналу. (Пример 2010 года: решение ОАО «ЮТК» о бесплатном и обязательном безлимите между абонентами Краснодарского края, принятое силою моего убеждения.)
  • +1
    Поигрался, очень интересная штука, работает шустро. Смущает только невозможность (или я не нашел) удалить файл, если я являюсь его владельцем (почему бы и нет?).
    Конечно, знаю пословицу про 7 раз отмерь… но все же, если по случайно в паблик выкатить ошибочный (или не тот) файл, дать на него ссылку и по ней его скачает другой человек, то даже при всем желании владельца, выпилить его из сети будет уже нереально никогда, пока сеть существует.
    Плюс, сеть будет захламляться со временем старыми версиями файлов, которые и нафик ни кому не нужны. Владельцы бы и рады устроить чистку, да не смогут.
    • 0
      С точки зрения борьбы с цензурою даже полезно, что файл не имеет того одного владельца, до которого было бы возможно добраться и принудить к стиранию файла. Потому что если возможно, то оно было бы и повадно.
    • 0
      Не пытайтесь изменить факт, пытайтесь изменить своё отношение к этому факту.
      Под технологии подстроится и психология.

      В давние времена и фотографии-то незнакомым людям не показывали,
      а сейчас инстаграмм, ютюб, перископ, лишь бы кто-нибудь посмотрел и лайкнул.
    • 0
      Рискну предположить, что реализован (или в скором времени будет реализован) механизм, по мере заполнения кэша удаляющий невостребованные файлы. Но удалить с гарантией — невозможно.
  • +1
    Счётчики посещений и прочая статистика лесом пойдут?
  • 0
    https://github.com/jbenet/multihash/blob/master/hashtable.csv
    code name
    0x11 sha1
    0x12 sha2-256
    0x13 sha2-512
    0x14 sha3-512
    0x15 sha3-384
    0x16 sha3-256
    0x17 sha3-224
    0x18 shake-128
    0x19 shake-256
    0x40 blake2b
    0x41 blake2s
    # 0x00-0x0f reserved for application specific functions
    # 0x10-0x3f reserved for SHA standard functions
    # 0x14 formerly had the name «sha3», now deprecated


    То есть, TIGER, из которого получается TTH, тут нет, петабайтная локалка уже сегодня в качестве кеша работать не сможет, а вот если все поставят IPFS, ну тогда, может быть, что–нибудь и получится. Inter-Planetary как бы намекает, в каком временном диапазоне это может случиться.
    • 0
      Присоединяюсь. Больше хэшей, если они надёжны! Существующие хранилища и кэши задействовать всекратно, убеждаясь в двух вещах: безопасности хэш-функции и публичности информации, т. е. возможности невозбранной её раздачи.
  • 0
    1. Ссылка https://ipfs.io/ipfs/QmQZB43ePCwDsow74gehT8v74M2tKtTs9FCbH4wpoUksfF валится с 504-й ошибкою. Сей факт вкупе с наличием в статье ссылок на некий другой IPFS-гейт наводит на печальные мысли о том, что наличие единственного домена-гейта — это плохо и централизация. Куда логичнее было бы обрабатывать адреса вида ipfs.anydomain.tld: владелец anydomain.tld не принуждается доверять доступность своей статики некоему серверу, а расширение по-прежнему может брать данные с локальной IPFS.

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


    3. Реквестирую PPA для установки сего в Ubuntu 12.04 или хотя бы толковый мануал.
    • 0
      1. Прошу прощения, в спешке не подумал о хабрапарсере. Пример следует читать так:
        <img src="https://ipfs.anydomain.tld/HASH" ipfs="HASH"/>
  • 0

    Ещё не поздно для IPFS https://habrahabr.ru/post/310554/

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