Браузер Brave первым добавил поддержку IPFS
С выпуском версии 1.19 пользователи Brave могут напрямую получать доступ к содержимому распределённой файловой системы IPFS, вводя URI, начинающиеся с ipfs://
Brave стал первым браузером, который внедрил поддержку пирингового сетевого протокола IPFS. Это относительно малоизвестный транспортный протокол, который обещает улучшить доминирующий стандарт HTTP, сделав загрузку контента более быстрой (теоретически), а сайты — более устойчивыми к сбоям и цензуре.
Если вкратце, вместо размещения информации на центральных серверах, контентно-адресуемый, одноранговый гипермедийный протокол IPFS предусматривает размещение в сети распределённых узлов. Этот P2P-протокол в каком-то смысле можно сравнить с торрентами. Каждый ресурс скачивается по хешу, а не по обычному URL. Вы вводите URI с мультихешем, а сеть находит, где хранятся фрагменты этого контента. По сути, узлы IPFS-сети формируют распределённую файловую систему. IPFS можно представить как единый BitTorrent-рой, обменивающийся файлами единого Git-репозитория.
Преимущества нового подхода включают в себя более высокую скорость, поскольку данные могут распространяться и храниться ближе к людям, которые получают к ним доступ, а также более низкие затраты на сервер для того, кто первоначально выкладывает контент в Сеть. Но самое главное, что IPFS обладает потенциалом сделать контент гораздо более устойчивым к сбоям и цензуре.
У браузера Brave в настоящее время аудитория 24 миллиона активных пользователей в месяц. Он давно продвигает IPFS и работал над стандартом с 2018 года. Но с выпуском версии 1.19 пользователи Brave могут напрямую получать доступ к содержимому IPFS, вводя URI, начинающиеся с ipfs://. Они также могут выбрать установку «полного узла IPFS в один клик», сделав свой браузер узлом в одноранговой сети.
«IPFS решает для пользователей проблему централизованных серверов, создающих центральную точку отказа при доступе к контенту, — говорит технический директор Brave Брайан Бонди. — Это даёт возможность беспрепятственно распространять контент миллионам новых пользователей по всему миру с помощью нового и безопасного протокола».
Руководитель проекта IPFS Молли Маккинлей добавляет, что децентрализация интернета через IPFS поможет преодолеть «системную цензуру данных» от правительств и техномонополий: «Сегодня пользователи веба по всему миру не могут получить доступ к запрещённым материалам, включая, например, части Википедии в Таиланде. В Турции заблокировано более 100 000 сайтов, а в Китае блокируется критически важный доступ к информации о COVID-19. Теперь любой человек с подключением к интернету может получить доступ к этой важной информации с помощью IPFS и браузера Brave».
Каждый узел в сети IPFS является потенциальным хостом для запрашиваемого контента, и если на узле нет этого контента, он может получить его из роя одноранговых узлов. Полученное содержимое проверяется локально, что устраняет необходимость проверять целостность у третьей стороны.
IPFS идентифицирует контент по путям и/или идентификаторам контента Content identifier (CID) внутри Uniform Resource Identifier (URI), а не по URL-адресам.
Вот пример URI в IPFS:
Начиная с версии Brave 1.19 вы можете взять этот адрес, вставить его в адресную строку Brave и загрузить контент.
По умолчанию Brave загружает URI через общедоступный HTTP-шлюз, однако при этом предложит установить локальный узел для работы с URI IPFS. Если пользователь согласится, Brave автоматически загрузит go-ipfs в качестве компонента и будет направлять будущий трафик через этот узел. Узел работает автоматически и не требует ручного вмешательства или использования расширения. Пользователь может дополнительно установить расширение IPFS Companion, и оно предложит использовать управляемый узел Brave.
Если вы настроили IPFS для локального узла, он сохранит схему (ipfs: или ipns:) в адресной строке. Эта опция позволит проверять содержимое доступных CID локально, а также получить доступ к ранее просмотренному содержимому IPFS в автономном режиме. Локальный узел также вносит свой вклад в прочность сети IPFS.
Если использовать сторонний шлюз, в адресной строке будет показан перенаправленный URL-адрес на сервере шлюза. В этом случае пользователь не затрачивает лишние системные ресурсы и просто получает доступ к контенту IPFS.
Поддержка IPFS в Brave разработана таким образом, чтобы свести к минимуму влияние на системные ресурсы. Если Brave настроен на использование локального узла IPFS, то этот узел будет лениво загружен только при обращении к первому URI IPFS. Если Brave настроен на использование общедоступного шлюза, узел IPFS никогда не загружается.
Компонент go-ipfs управляет хранилищем данных и настроен на сборку мусора каждый час, если кэш находится на уровне 90% от максимального объема хранилища (1 ГБ). Когда пользователь очищает данные браузера для кэшированных изображений и файлов, также запускается сборка мусора для сохранённого содержимого IPFS, которым управляет go-ipfs. При этом удаляется весь контент IPFS, за исключением закреплённого.
В будущем Brave не исключает, что будет разрешена работа IPFS через окна в режиме инкогнито, сохраняя отдельную конфигурацию и кэш, который автоматически очищается по окончании сеанса.
Почему Интернету нужен IPFS, пока ещё не поздно
IPFS не совсем ещё сделалась хорошо известной технологией, даже в Кремниевой долине многим она ещё не известна, однако вести о ней быстро расходятся из уст в уста в сообществе открытого исходного кода. И многие рады потенциальным возможностям IPFS в области улучшения передачи файлов и ускорения потокового вещания их по Интернету.
С моей личной точки зрения, однако же, IPFS в действительности гораздо важнее этих возможностей. IPFS избавляет сайты от необходимости использовать центральный сервер-первоисточник и поэтому, вероятно, это наш лучший шанс полностью переменить архитектуру Интернета прежде, чем она развалится от внутренних противоречий.
Как и почему это? Для ответа на этот вопрос придётся вдаваться в подробности.
Почему наша Всемирная Паутина медленна, непрочна и забывчива
IPFS является новым p2p-гипермедийным протоколом, цель которого — дополнять собою (или даже, может быть, заменить) протокол передачи гипертекста (HTTP), сейчас господствующий в WWW. Вот в чём проблема HTTP: сегодня, когда вы посещаете сайт, ваш браузер должен напрямую связываться с серверами, на которых этот сайт работает, даже когда серверы эти далеко, а процесс передачи требует немалой пропускной способности.
Провайдеры несут расходы, потому что между сетями заключены пиринговые соглашения, так что пересылка данных из сети в сеть стоит денег провайдеру и расходует пропускную способность канала. Хуже того, файл по HTTP скачивается всего лишь с одного компьютера вместо того, чтобы одновременно получать части файла с разных компьютеров.
Вот почему и вот в каком положении дел мы застряли: медленный и дорогостоящий Интернет, цена которого ещё возрастает в силу хищничества провайдеров «последней мили» (по меньшей мере, в США), и с ускоряющимся ростом запросов на соединение с мобильных устройств. Он не просто медленный и дорогостоящий, но и ненадёжный. Если хотя бы одно звено оборвётся по любой причине, то оборвётся и передача. (А когда или медиафайл грузятся долго, то, скорее всего, виною тому одно из межкомпьютерных соединений.)
Переделываем Интернет посредством IPFS
IPFS (InterPlanetary File System, то есть межпланетную файловую систему: это название — дань памяти идеям о «межгалактическом» Интернете) придумал Juan Benet, который подростком приехал в США из Мексики, в Стэнфорде получил степень по информатике, основал компанию, приобретённую «Yahoo!» в 2013 году, а в прошлом году при посредстве Y Combinator основал Лаборатории Протокола (Protocol Labs), которые сейчас занимаются проектом IPFS и скромно намерены переменить те протоколы, которые последние 20 лет были для нас повседневным явлением жизни.
IPFS — это P2P-распределённая файловая система, стремящаяся соединить все вычислительные устройства одной общей системою файлов; как таковая, она способна превзойти возможности HTTP в нескольких отношениях. Из них два (как сообщил мне Хуан в недавнем разговоре) являются ключевыми:
«Мы используем контентную адресацию, поэтому контент приобретает независимость от серверов первоисточника и может храниться отдельно и долговременно. Это значит, что контент может храниться и раздаваться очень недалеко от потребителя — быть может, даже компьютером из той же самой комнаты. Контентная адресация также позволяет и проверять данные, полученные от других (не доверенных) хостов вместо первоисточника. А когда контент попадает на устройство пользователя, его там можно кэшировать сколько угодно».
IPFS также устраняет некоторые проблемы безопасности, досаждающие нашему основанному на HTTP Интернету: основанная на контенте адресация (и последующая верификация) защищает основанные на IPFS сайты, распределённость IPFS делает невозможными. Помогая смягчить ущерб от закрытия сайтов их владельцами, IPFS также кэширует в себе важный для общества контент и может невозбранно сохранить его.
Главнейшим же из достоинств IPFS служит децентрализованная раздача контента, так что к контенту из Интернета можно обращаться в обстоятельствах нерегулярного доступа к Интернету и даже брать его из оффлайнового кэша. «Мы создаём сайты не имеющие центрального Они могут быть распределёнными подобно тому, как распределённою является HTTP просто не может добиться, так что IPFS послужит во благо сетей, не имеющих первоклассных взаимосвязей (например, в развивающихся странах или в сельской местности).
Появление альфа-версии IPFS в прошлом феврале ужé повлекло за собою множество экспериментов среди ранних восприёмников её (early adopters). Например, 8 сентября хостинг Neocities стал первым крупным сайтом, пользующимся IPFS для хранения контента, то есть последовавшим призыву Internet Archive о необходимости распределённого WWW. В настоящее время все мы претерпеваем непрестанную утрату всё новых и новых сайтов, год за годом покидаемых и закрываемых их создателями, и в этом нарастающем кризисе нашей коллективной интернетовской памяти для нас важен даже малый шаг в сторону перманентной Паутины.
А сайты, принадлежащие крупным корпорациям, последуют ли примеру Neocities, начнут ли внедрение ещё не полностью протестированного протокола — особенно когда даже простое упоминание P2P способно привести их в ужас? А вот тут я подхожу к последнему пункту статьи.
Почему IPFS весьма значим для будущего
Как я разъясняю в моей новой книге (публикация которой ещё впереди), мы быстро приближаемся к той точке, за которою стоимость доставки контента опередит полезность — и финансовую выгоду. Крупнейшие компании Интернета ужé изо всех сил стараются не отстать от нашего спроса на контент, целые армии инженеров заняты одной этой задачею и в Akamai, и в Google, и в Amazon.
Скоро их положение ухудшится. Благодаря быстрой продаже дешёвых смартфонов в ближайшее десятилетие в онлайн выйдут целые континенты новых потребителей. Интернет Вещей также обещает усугубить эту проблему, ведь биллионы устройств с их собственными запросами приналягут на быстро истощающиеся возможности наших каналов связи.
Нам ужé до крайности необходимо ограничение того эффекта, который я называю микросингулярностью: быстрое «вирусное» привлечение пристального внимания биллионов пользователей Интернета к одному и том же событию угрожает удушить собою всю систему. (Перебои в работе сети теоретически угрожают и жизни, когда микросингулярностью становится катастрофа, авария или другое явление того же рода.)
Улучшая связность, IPFS поможет Интернету становиться той системою, которою мы всегда стремились видеть его в наших идеализациях, но которой с нынешними протоколами стать он не мог: истинно способною соединить всех в мире (даже находящихся в оффлайне) перманентным, но постоянно развивающимся выражением того, кто мы такие и к чему мы стремимся.
Послесловие от переводчика
Хабрахабр — это даже не Кремниевая долина, так что и здесь, как можно предполагать, к началу октября 2015 года не все ещё читатели составили для себя достаточное представление об IPFS. Следовательно, окончив перевод статьи из TechCrunch, мне придётся также приложить к ней определённое разъясняющее послесловие; и прилагаю, облекая его в форму вопросов и ответов.
— Распределённая файловая система с контентной адресацией.
— В каком смысле система IPFS является распределённою?
— В смысле P2P-файлообмена. Скачав файл, пользователь становится его источником для других скачивающих.
— В каком смысле система IPFS является файловой системою?
— В прямом: если ваша операционная система является юниксоподобною, то при помощи FUSE можно подключиться к IPFS таким способом, чтобы видеть файлы IPFS по адресу у себя в файловой системе.
— В каком смысле система IPFS является контентно-адресуемою?
— Хэш файла зависит только от содержимого файла. Если файл имеет другое имя или лежит в другом подкаталоге, то это всё равно тот же файл. (Это выгодно отличается, например, от битторрентовского хэша BTIH, который изменяется в зависимости от названия и взаимного расположения файлов.) Если тот же самый файл раздаётся под другим именем или в составе другого подкаталога, раздачи автоматически объединятся, не потребуется удвоение усилий, траффика, пространства на диске.
— Есть ли в файловой системе IPFS подкаталоги?
— Есть; это списки имён (и хэшей) файлов и подкаталогов. Например, для открытия адреса сперва скачивается каталог (по его известному хэшу), затем по имени файла в каталоге выясняется тот хэш, при помощи которого IPFS будет качать файл. Каждое имя подкаталога добавляет один шаг к этому процессу.
— Как узлы IPFS знают, у каких из них есть желаемый файл?
— Используется DHT (наподобие Kademlia, но с большей устойчивостью Нет никакого центрального сервера, который можно было бы захватить, отключить, отнять имя (как захватывают и отключают например).
— Как сайт нынешней Всемирной Паутины может сослаться на файл, лежащий в распределённой файловой системе IPFS?
— Автор сайта ставит себе IPFS и кладёт файл в IPFS. Затем он записывает перед файла и получает, например, работает как гейт из IPFS в WWW, так что читатели, у которых поддержка IPFS не установлена, могут с этого сайта получить файл.
— А читатели, у которых поддержка IPFS установлена?
— А у них появляется личный гейт из IPFS. Остаётся только поставить такое дополнение для Firefox или расширение для Chrome, которое будет «127.0.0.1:8080» автоматически подставлять вместо «ipfs.io» в таких URLах.
— Каким образом IPFS спасает в случае нарушений в работе сети?
— Если иллюстрации (и другие файлы) с самого начала публиковать не по сайтовому адресу, а в IPFS, то тогда, даже если сайт упадёт, читатель всё равно может получать файлы по известному адресу, только не из сайтового кэша IPFS, а из кэша у соседа. (И сосед не сможет подменить файл, потому что будет проверяться соответствие файла хэшу.)
— Каким образом IPFS помогает сайтам экономить траффик?
— Если иллюстрации (и другие файлы) с самого начала публиковать не по сайтовому адресу, а в IPFS, то тогда, даже если вдруг случится микросингулярность и на сайт очень быстро придёт биллион зрителей, всё равно бóльшая часть их будет по IPFS стучаться не на сайт, а в кэш своим соседям по биллиону, успевшим чуть раньше. Так что сайт не приляжет. (Конечно, для этого сперва среди зрителей должна распространиться мода на IPFS, а не то вместо сайта приляжет например.)
— Каким образом IPFS помогает сайтам в случае гибели диска?
— Если иллюстрации и другие статические файлы с самого начала публиковать не по сайтовому адресу, а в IPFS, то тогда можно будет пропавшие картинки (и другие файлы) скачать по IPFS из кэшей читателей сайта в случае чего.
— Каким образом IPFS помогает читателям в случае государственной цензуры?
— Если иллюстрации и другие статические файлы с самого начала публиковать не по сайтовому адресу, а в IPFS, то тогда можно будет запрещённые иллюстрации (например, иллюстрации к ранобэ «精霊使いの剣舞») и другие запрещённые файлы получать по IPFS в обход блокировки (из кэшей читателей сайта, успевших получить файлы до вступления цензуры в силу).
___
* Нарочито «кавайная» запись фамилии Е.Б.Мизулиной; сатира на её роль в #антианиме.
— Каким образом IPFS помогает сайтам экономить дисковое пространство?
— Если иллюстрации с самого начала публиковать не по сайтовому адресу, а в IPFS, то тогда можно через некоторое разумное время стирать их из кэша IPFS, высвобождая пространство и надеясь на то, что иллюстрации продолжат быть доступными для читателей, которые просто будут в дальнейшем получать их из кэша IPFS друг у друга.
— То есть это реальная альтернатива для тех хостингов картинок и для имиджборд, которые сейчас действуют жёстко и после определённого времени просто стирают файлы невозвратно?
— Совершенно верно. (Я предлагал эту альтернативу на Иичане, например.)
— Есть ли прямо сейчас пример такого хостинга картинок, который складывает картинки в IPFS?
— Есть ли прямо сейчас пример такого хостинга произвольных файлов, который складывает их в IPFS?
— Означает ли контентная адресация, что в IPFS можно хранить только статический (неизменный) контент?
— В общем-то да. Впрочем, есть система имён IPNS для сайтов, позволяющая ставить каждому имени IPNS в соответствие свой хэш каталога IPFS, а затем по мере нужды изменять это соответствие. То есть выложить на такой сайт некоторое статическое содержимое, но новое.
— Может быть, придумать новую схему URLов для IPFS? Это позволит записывать их короче, чем длинноватый адрес перед хэшем.
— Две недели обсуждали и решили остановиться предшествующей такому пути в файловой системе, который начинается
— Почему не сделали две раздельные схемы «ipfs:» и «ipns:»?
— Для удобства пользователей юниксоподобных систем, которым теперь достаточно стереть чтобы получить путь. (А не то переправлять ещё возиться.)
— Будут ли адреса «fs:» поддерживаться в гипертекстовом Фидонете?
— Будут; для этого достаточно трёх строк на языке ECMAScript 6. Вот пример фидонетовской блогозаписи, сперва снабжённой иллюстрацией из IPFS, а затем транслированной по RSS в LiveJournal.
— Можно ли добавить поддержку открытия в редактор фидопочты
— Работает ли IPFS под Windows?
Нынешняя альфа-версия под Windows работает довольно скверно, но предыдущая вообще переставала запускаться, так что можно надеяться на дальнейшее улучшение положения дел в будущем, и надеюсь.
Межпланетная файловая система IPFS
InterPlanetary File System — это новая децентрализованная сеть обмена файлами. Также выполняет функцию сети доставки содержимого.
Отличие от других децентрализованных сетей в том что самостоятельной единицей передаваемой в сети является блок. Блок может содержать как часть файла так и ссылки на другие блоки. Из блоков выстраивается направленный ациклический граф из которого в дальнейшем собирается файл или каталог.
Такая система позволяет более гибко подойти к хранению и передаче данных в сети. Недостатком такого подхода является то что всё что загружается в сеть режется на блоки и складывается в отдельный каталог на вашем диске.(Исправлено: «больше нет необходимости копировать в сеть») Поиск по имени файла или каталога в IPFS отсутствует также как и в сети BitTorrent.
Мультихеш
Идентификатором в этой децентрализованной сети служит обёрнутый в мультихеш sha128 от блока. Мультихеш состоит из трёх частей: ID хеш функции, размер хеша в байтах, хеш. Для хранения ID и размера используется сейчас по одному байту но значения их не может быть больше или равно 128 до тех пор пока они не определятся с форматом unsigned-varint коими они обозначены. Мультихеш в ссылках представлен в кодировке Base58 bitcoin.
Мультихеш используется с заделом на будущее что-бы сеть имела возможность перейти на новые более стойкие хеш функции.
Теперь мультихеш входит в состав идентификатора контента.
Клиент
В рабочем состоянии для сети IPFS существует мультиплатформенный клиент написанный GO. Его можно как скачать так и скомпилировать самостоятельно.
Команда ipfs daemon запускает клиент который предоставляет web интерфейс. Войти на него можно по адресу по умолчанию http://127.0.0.1:5001/webui.
Выше я говорил что самостоятельной единицей в сети является блок. Если взять со страницы http://127.0.0.1:5001/webui#objects мультихеш блока файла и добавить к нему http://127.0.0.1:8080/ipfs/ то сеть отдаст часть файла или каталога соответствующую блоку с этим мультихешем.
Для прямой работы с raw блоками у ipfs также имеются команды:
При помощи ipfs block get [мультихеш] я выяснил чему соответствует мультихеш от тестового файла который я только что загрузил командой ipfs add [полный путь к файлу] используя RHash и Base58 online декодер. Файлы размером меньше 262158 байт хранятся в сети одним блоком. Формат этого блока я так и не выяснил по умолчанию это данные упакованные в Protocol Buffers.
Интересно что webui храниться в децентрализованной сети и часть кода самого клиента также храниться в ней. Код подгружается из сети автоматически перед компиляцией клиента. Зачем это сделано не знаю. Это немного затрудняет чтение исходников.
Эксперименты с IPFS и BitTorrent
Экспериментируя с IPFS WebSeed и qBittorent я заметил что локальный IPFS очень медленно отдаёт данные запрашиваемые в случайном порядке. Только когда я включил последовательное скачивание скорость возросла до 1МБ/c. И этом все блоки раздачи находятся в локальном хранилище. Также IPFS сильно грузит процессор.
Для BitTorrent’а IPFS клиент может послужить хорошим дедупликатором. Он сможет найти копии файлов по IPFS мультихешу каталога или файла. Для этого достаточно добавить его как WebSeed в торрент.
IPFS WebSeed
После этого полученные ссылки можно добавить в создаваемый торрент-файл или магнит.
WebTorrent и IPFS WebSeed
WebTorrent сможет работать только с локальным шлюзом IPFS и то только после настройки так как шлюз должен дать разрешение для WebTorrent использовать HTTP заголовок Range.
после чего сохранить и перезапустить IPFS
Межпланетная система имён
Сочетание бесплатного DNS, http://gateway.ipfs.io/ipns/[мультихеш публичного ключа] и IPFS клиента позволяет раздавать с домашнего сервера небольшой статичный сайт даже находясь за NAT.
Межпланетная файловая система и магнит
Сейчас IPFS не умеет работать с магнит-ссылкам и да и не описан URN который содержит в себе используемый в сети мультихеш.
Я предлагаю такой: urn:ipfs:[Base58 bitcoin encoded IPFS multihash]
В магнит ссылке он соответственно будет выглядеть так:
Написав небольшой скрипт можно научить работать IPFS с магнитами или другие децентрализованные клиенты использовать IPFS как WebSeed.
Я думаю использование магнит-ссылки позволит отвязаться от сайта ipfs.io с которым может произойти та же история что и с доменом shareaza. И более чётко обозначить IPFS мультихеш.
Немного не по теме
Я тут для магнитов нарисовал(написал на самом деле) логотип для безвозмездного использования. Хочу его представить чтоб он стал узнаваемым символом магнит-ссылки ну и использовался для её обозначения. Может тогда я смогу откатить отмену моей правки в статье по магнит-ссылкам и вернуть логотип в статью.
Цвета для магнита взяты из логотипов клиентов децентрализованных сетей. Я не дизайнер. Старался сделать рисунок простым и компактным. Вы можете свободно копировать его и изменять.
Источники
Продолжение
Да, намного проще зайти в Google Drive / Dropbox / Amazon Web Services и другие облачные хранилища, чтобы загрузить свой файлы туда, но, делая это вы должны быть готовы к следующему:
Для некоторых людей, вышеперечисленные пункты не вызывают беспокойств или тревог, но любая система должна развиваться и двигаться дальше, на сегодняшний день, крупные корпорации зарабатывают на личных данных пользователях намного больше, чем услуги, которые юзеры получают взамен.
В России, понятие «интеллектуальной собственности» и «защиты личных данных» очень слабо развиты, по этой причине, не всем интересна тема Web 3.0 и возможности монетизации / защиты личных данных, но в таких странах, как Германия, пришло осознание того, что Google / Facebook / Twitter уже начинают терять тот фундамент, на котором стоят и что будущее интернета стоит за возможностью управлять своими данными и возможностью создавать ценность независимо от свой национальности / места рождения / возраста.
IPFS позволяет загрузить файлы в сеть и распространить их по сети другим участникам, чтобы это сделать, сначала требуется установить ipfs на свой ПК.
После этого копируем команду ipfs cat /ipfs/QmS4ustL54uo8FzR9455qaxZwuMiUhyvMcX9Ba8nUH4uVv/quick-start и вместо readme пишем quick-start
Далее нам требуется запустить «Демона», чтобы использовать веб-интерфейс IPFS
Чтобы опубликовать файлы в сети IPFS у нас есть два пути
Так как загрузка через веб-интерфейс достаточно понятна, я объясню как это сделать через командную строку.
Я загружу в сеть архив Ankr-Network, который позволяет делегировать свои вычислительные мощности и получать за это вознаграждение.
2. Теперь наш файл доступен по хешу QmXdGg33KQu4KFszUkZHsyWopXgCb69vhGdoMXdMpV4j6T
3. Чтобы отправлять своим друзьям ссылку на этот файл и они могли получить к нему доступ с любого устройства, нам нужно получить ссылку на этот файл, для этого нам требуется прописать следующую команду:
ipfs name publish
4. Теперь наши файлы доступны по ссылке и вы можете установить себе Desktop версию ANKR-NETWORK, чтобы делиться своей вычислительной мощностью и в скором времени будет возможность получать за это денежное вознаграждение.
p.s в этой статье описывается что такое IPFS и каким образом его можно использовать, здесь не затронуты другие преимущества и возможности этой технологии, потому что это вытекает за рамки основной темы материала.
IPFS является важным компонентом нового Web 3.0, его возможности превосходят простое хранение файлов, его также можно использовать для создания децентрализованного сайта (Wikipedia) или музыкального плеера.
Естественно, не всем приложения требуется децентрализация и устойчивость к цензуре, учитывая, что она ведет к потере контроля над контентом, особенно беря во внимая, что все это еще находится на стадии зарождения и является большим экспериментом, и множество вопросов, на которые сейчас нет ответов очень много, но само по себе возможность таких технологий на сегодняшний день должно двигать нас модернизировать имеющиеся системы.
________________________________________________________________________________
________________________________________________________________________________
Данная статья носит исключительно ИНФОРМАЦИОННЫЙ характер. Настоящая статья ни в коей мере не является предложением или приглашением к предложению купить или продать какие-либо криптовалюты, обсуждаемые здесь. Инвесторы должны провести независимую проверку всех криптовалют, обсуждаемых в этой статье, и сложить мнение о соответствующем рынке до принятия любого инвестиционного решения. Ни один из авторов, соавторов или кто-либо еще, связанный с GT Blockchain Investments никоим образом не может нести ответственность за использование вами информации, содержащейся в данной статье.
