? Editing: Post:21.body Save Delete Cancel
Initial sync in progress...

Newest topics

Follow in NewsfeedFollowing
+ Start new topic
Loading...
stickied

Title

Body
^1 ^2 added ━ started by user_name
More topics

 

Follow in NewsfeedFollowing

IPFS в Infonesy

Сейчас (для отработки подходов и концепции) вожусь с заменой в TT-RSS/Infonesy трансляции ссылок на картинки на IPFS-ссылки. Поскольку планирую сохранять оригинальные имена файлов, то добавление wrap/recursive. Кроме самого файла, заодно, это позволит и сохранить Info с указанием ссылки-первоисточника и места использования файла.

Так и не понял, каким способом скармливать recursive-данные через IPFS API.

Поэтому делаю через ipfs - утилиту командной строки.

^2 ^3 balancer73 posted on Dec 03, 2016
Please sign innew comment
Sign in as...
Submit comment
You are running out of your allowed space, please contact the site's admin at unknown to raise your limit.
user_nameadded ^1 ^2
Reply
Body
balancer73on Jan 05, 2018 ^1 ^2
Reply

Подводя итоги. Разочарован я в IPFS. Отдельным постом, потому что с картинками-графиками: http://127.0.0.1:43110/1GQkPB8mFgxH7GQQbkNPJtvRaZZpVi65u1/?Post:28:IPFS:+разочарование

balancer73on Nov 25, 2017 ^1 ^2
Reply

anotherneko: Еще ни разу на своей ноде не наблюдал сборку мусора, инициированую самой нодой.

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

anothernekoon Nov 24, 2017 ^1 ^2
Reply

balancer73: Транзитный трафик в IPFS высокий и сборка мусора проходит часто. [...]

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

balancer73on Nov 24, 2017 ^1 ^2
Reply

Но доступность самих нод это никак не гарантирует.

Нет. Но вероятность такого события относительно невысока. Поэтому десяток нод сохранят файл с достаточно высокой гарантией.

А вот отсутствие пина может привести к потере файла в очень короткий период.

Это как и отработка gc на ноде с незапиненым файлом - случайное событие

Это очень часто срабатывающее событие. Транзитный трафик в IPFS высокий и сборка мусора проходит часто. Поэтому в IPFS без пинов живут только активно используемые файлы.

Если файл используется редко, то с высокой вероятностью его уже и через неделю не найдёшь. Я на это уже нарывался несколько раз :)

anothernekoon Nov 24, 2017 ^1 ^2
Reply

balancer73: Наличие пинов гарантирует, что файл будет сохранён, пока доступны ноды. [...]

Но доступность самих нод это никак не гарантирует. Можно запинить файл, потом удалить ноду и файл перестанет быть доступен. Это как и отработка gc на ноде с незапиненым файлом - случайное событие. При достаточном количестве нод с файлом и статистике их пропадания уже можно строить какие-то прогнозы времени жизни файла, причем в обеих случаях.

balancer73on Nov 24, 2017 ^1 ^2
Reply

anotherneko: Наличие пинов так же не может гарантировать что все запиневшие пиры завтра не уйдут в оффлайн.

Наличие пинов гарантирует, что файл будет сохранён, пока доступны ноды.

Наличие пиров без пинов не гарантирует вообще ничего.

Разница качественная :)

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

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

anothernekoon Nov 24, 2017 ^1 ^2
Reply

balancer73: Это список пиров, но не список пинов. Это число никак не гарантирует, что файл будет доступным хоть завтра.

Наличие пинов так же не может гарантировать что все запиневшие пиры завтра не уйдут в оффлайн.

balancer73on Nov 24, 2017 ^1 ^2
Reply

anotherneko: ipfs dht findprovs <hash> [...]

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

anothernekoon Nov 23, 2017 ^1 ^2
Reply

balancer73: Например, IPFS не обеспечивает контроль наличия файла в сети вообще (ты не знаешь, сколько узлов его раздаёт)[...]

ipfs dht findprovs <hash>

возвращает список пиров у которых есть этот хеш

zerostormon Oct 06, 2017 ^1 ^2
Reply

balancer73: В торрентах нет, в IPFS — есть. Если я добавляю файл на одном сервере, то я могу немедленно передать ссылку не него клиентам и они по хешу смогут сразу получить его у себя. Естественно, когда сеть работает. Да, может быть задержка распространения, но файл придёт. [...]

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

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

тут нужно смотреть на всякие RetroShare или даже I2P. Но это снова другая история...

Как сказать. Tor, I2P - это протоколы луковой маршрутизации. Думаю, со временем они ровно эту задачу и будут выполнять. Незачем в децентрализованном приложении пилить свой протокол луковой маршрутизации, когда можно использовать Tor или I2P. ZN уже работает с Tor. RetroShare и FreeNet несут в себе свой инструменты анонимизации, но там доверие остается узким местом, а так же их неуниверсальность. Выложить файл в ZN через тор, даже более безопасно, в плане деанонимизации, если правильно подойти.

balancer73: Но это совсем другая история :) которые не позволяют в ряде конкретных задач заменить IPFS на ZN.

Да. ZN разрабатывается с упором на сам ZN. Не для использования в других приложениях. Притом, во многом разработка идет на ощупь, по ситуации. IPFS наоборот конструктор, который сам по себе малоюзабелен, но хорошо подходит для использования в приложениях.

ZN BigFiles в нынешнем виде пока тоже не годится для нормального «пиратского» файлообмена, например кино. Но тут, надеюсь, ещё допилят :)

Это как посмотреть. Столь популярные торренты в открытую просматриваются, что ты качаешь. Агрессивный поиск узлов приводит к тому, что IP протекает даже за VPN или Tor. Здесь, пока такого нет, и получается что с использованием режима Tor Only тут даже безопаснее раздавать.

balancer73on Oct 06, 2017 ^1 ^2
Reply

zerostorm: В этом году его разработчики представили свой блокчей проект Filecoin.

Но это совсем другая история :) Кроме того, IPFS — тоже далеко не «серебряная пуля». У неё тоже много своих тараканов. Я писал выше только о тех недостатках ZN, которые не позволяют в ряде конкретных задач заменить IPFS на ZN. Но точно также есть много задач, где нельзя заменить ZN на IPFS :) Например, IPFS не обеспечивает контроль наличия файла в сети вообще (ты не знаешь, сколько узлов его раздаёт), что ставит крест на гарантированном длительном хранении и консистентности системы. Я поэтому в ZeroBlog пришёл к необходимости, таки, хранить фотки средствами ZeroBlog, а не IPFS :)

...

Кстати, IPFS не годится для пиратского файлообмена ближе к слову «никак» из-за раскрытия информации о пирах :) Тут нужно смотреть на всякие RetroShare или даже I2P. Но это снова другая история...

ZN BigFiles в нынешнем виде пока тоже не годится для нормального «пиратского» файлообмена, например кино. Но тут, надеюсь, ещё допилят :)

balancer73on Oct 06, 2017 ^1 ^2
Reply

zerostorm: Думаю, этого и в тех же торрентах и IPFS нет.

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

В ZeroNet, если немедленно обратиться к файлу, до того, как изменение дойдёт до клиента, ты получишь ошибку отсутствия файла. ZN не выкачивает файлы, о которых ничего не знает. Файл можно забрать только после того, как клиентская нода получит о нём информацию.

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

Простой пример. Я выкладываю фото на форум через теги [img]...[/img] со ссылкой на посторонний p2p-ресурс. Само фото кладу у себя. В IPFS читатель форума, немедленно открыв моё сообщение, при работающей сети увидит фото гарантированно — сторонний ресурс утянет файл по запросу. В ZN читатель в этой ситуации с высокой вероятностью картинку не увидит, так как до того, как на третий ресурс не дойдёт моё фото, он будет отдавать статус «файл не найден».

zerostormon Oct 06, 2017 ^1 ^2
Reply

Есть вот какой момент с IPFS. В этом году его разработчики представили свой блокчей проект Filecoin. Суть в маркетплейсе для платного закрепления IPFS контента или вроде того. Но там даже больше с планом на нативные смартконтракты. ICO собрали денег болше 250 лямов баксов. Так что с финансированием теперь проблем нет, тут дело в том, смогут ли они эти деньги использовать с умом.

А основной момент вот в чем. ICO проводилось с требованием SEC, с допуском только аккредитованных инвесторов. Не для простого народа, в общем. Получилась довольно нехорошая ситуация по отношению к сообществу, но это другое. Я просто предполагаю, что теперь инвесторы будут оказывать излишнее влияние на проект, требуя "чистого" использования. Например, препятствованию для использования в пиратском файлообмене. Даже раньше уже. Было обсуждение для нативной реализации соединения узлов через Tor. Потом это заглохло. Теперь, думаю, точно не увидим в скором времени. Но кто знает.

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

zerostormon Oct 06, 2017 ^1 ^2
Reply

balancer73: Не совсем. Или совсем не :) [...]

Контентная адресуемость

Почему нет? Как я понял, та же идея с деревом мёркла, что и в торрентах. Это и есть КА, пусть не настолько продвинутая как в IPFS, впрочем не мешает сделать ту же дедупликацию между зайтами.

Проксирование без выкачивания

Может это будет. Эта фишка вообще нужна в ZN. Думаю, рано или поздно она появится.

Гарантированная доставка при наличии в сети

Думаю, этого и в тех же торрентах и IPFS нет.

Тут просто это давняя проблема. Все хотели тяжелый контент, но не было нативных средств. WebTorrent требует внешний софт и WebRTC, IPFS хромает по производительности, поиску узлов через Tor, закреплению контента. ZeroMux был примитивным костылем и требовал дополнительную утилиту для добавления файлов.

balancer73on Oct 06, 2017 ^1 ^2
Reply

zerostorm: Касательно ZeroNet, то с новым релизом необходимость сторонних костылей отпала.

Не совсем. Или совсем не :)

Большие файлы ZeroNet пока ещё очень кривые и не имеют пока многих полезных фишек, типа отсутствия работы с файлами с cli, отсутствие возможности раздачи со сторонних каталогов без копирования и т.п. Это, в общем, со временем решается (но ещё не). А вот некоторые вещи в big files ZN не решаются в имеющемся виде в принципе. Например:

  • Гарантированная доставка при наличии в сети
  • Контентная адресуемость
  • Проксирование без выкачивания
zerostormon Oct 06, 2017 ^1 ^2
Reply

balancer73: Кроссплатформенность — гут. Но IPFS часто тяжела даже для сервера (память, трафик) — на мобильном поэтому от неё проку мало :)

Касательно ZeroNet, то с новым релизом необходимость сторонних костылей отпала.

balancer73on Oct 06, 2017 ^1 ^2
Reply

zerostorm: Но постепенно IPFS идет и на мобилки.

Кроссплатформенность — гут. Но IPFS часто тяжела даже для сервера (память, трафик) — на мобильном поэтому от неё проку мало :)

zerostormon Oct 05, 2017 ^1 ^2
Reply

Вот, для всех кто критиковал. Но постепенно IPFS идет и на мобилки. Новые версии IPFSdroid уже умеют работать с локальным демоном скомпиленным под андроид. Тут я таки должен признать это преимущество языка Go.

murkaon May 13, 2017 ^1 ^2
Reply

В 0.4.9, так понимаю, идут в сторону использования multihash. Не очень то это хорошо, кмк. Два человека могут опубликовать один файл с разными хэш-фунциями и у них будт разный multihash-адрес. А плюс в том, что переход на новую хэш-фунцию в случае взлома текущей, становится бесшовным.

balancer73on Apr 28, 2017 ^1 ^2
Reply
balancer73on Apr 11, 2017 ^1 ^2
Reply

unit875309: Наверно оно как-то так и работает пока, только пока файл остается на своем месте. Но мне оно как бы не особо нужно, потому я подожду когда нормально пользоваться можно будет.

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

balancer73on Apr 11, 2017 ^1 ^2
Reply

unit875309: Демонстрация работы js-ipfs https://codepen.io/konsumer/pen/xqNBJX?editors=0010

Интересно. Хотя, как я понял, оно не запоминает состояние и при каждом повторном заходе бутстрапится с нуля?

unit875309on Apr 08, 2017 ^1 ^2
Reply

Демонстрация работы js-ipfs https://codepen.io/konsumer/pen/xqNBJX?editors=0010

unit875309on Mar 21, 2017 ^1 ^2
Reply

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

balancer73on Mar 21, 2017 ^1 ^2
Reply

Сглазил. Стало ругаться на cannot add filestore references outside ipfs root даже на тех файлах, что только что добавлялись нормально :-/

balancer73on Mar 21, 2017 ^1 ^2
Reply

Протестировал добавление из ФС. Работает. Только нужно после ipfs config --json Experimental.FilestoreEnabled true ещё не забыть и демона перезапустить, а то я не сразу понял, почему опцию --nocopy ipfs add принимает, а .ipfs всё растёт :)

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

balancer73on Mar 14, 2017 ^1 ^2
Reply

mist: в будущем релизе 4.7 добавили экспериментальный режим добавления файлов, без дублирования его в ipfs blockstore. Так же добавлен режим приватной сети, тоже экспериментальный.

О! И то, и другое — здорово. А то из-за второго я перестал использовать IPFS на ноутах (постоянно большой транзитный трафик, не смотря на то, что ноут вообще в глубине локалки за серым роутером), а из-за первого я недавно снёc IPFS с основных серверов. При размере хранилища в 100Гб сервера перестали с ним справляться. Непрерывный IO, страшные тормоза...

miston Mar 13, 2017 ^1 ^2
Reply

DHT довольно медленная штука, оно и взлетело в файлообмене только потому, что там это не критично. Но довольно проблематично использовать IPFS для транспорта сообщений. Это обратная сторона масштабируемости.

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

Вот AKASHA. Найти IPFS узлы не проблема, блокчейн синхронизируется быстро. Теперь нам известны IPFS адреса. Но теперь ещё нужно найти узлы, где оно храниться. И особенно это касается только добавленного контента. Кажется нужны рассылки, в качестве третьего компонента системы в добавок к блокчейну + IPFS.

miston Mar 13, 2017 ^1 ^2
Reply

в будущем релизе 4.7 добавили экспериментальный режим добавления файлов, без дублирования его в ipfs blockstore. Так же добавлен режим приватной сети, тоже экспериментальный.

balancer73on Feb 18, 2017 ^1 ^2
Reply

mist: А интересно, оно умеет разбивать крупные файлы на блоки?

В IPFS файлы бьются на блоки по 256к.

miston Feb 17, 2017 ^1 ^2
Reply

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

balancer73on Feb 16, 2017 ^1 ^2
Reply

mist: Там тихо и незаметно вышел 0.4.5 несколько дней назад. Но на сайте инфы нет ещё.

Ага, точно. Правда, в changelog ничего революционного :)

https://github.com/ipfs/go-ipfs/blob/master/CHANGELOG.md

miston Feb 16, 2017 ^1 ^2
Reply

Там тихо и незаметно вышел 0.4.5 несколько дней назад. Но на сайте инфы нет ещё.

balancer73on Jan 28, 2017 ^1 ^2
Reply

Не про использование в Infonesy, но про IPFS :)

Наткнулся на неприятную фичу. Копирую базу файлов с одной машины на другую. С виду всё просто, pin ls на одной, кидаем хеши в файл, забираем на другую и грузим их там по одному по pin add. База на 42Гб. Вначале было шустро. Но прошли сутки и теперь добавление одного хеша занимает 10-15 секунд. Ладно бы, можно б было перетерпеть один раз (хотя хешей 30000 штук — такими темпами неделю копировать!), но проблема в том, что тормозит и добавление уже имеющихся пинов! Т.е. нельзя быстро повторно прогнать базу, добавив только то, что отсутствует.

Хотя, конечно, можно получить список пинов целевой машины, вычесть его из исходного списка... Так жить можно. Но — сложно, блин! :)

В Гитхабе есть соответствующий тикет. Отметился там. Посмотрим...

This page is a snapshot of ZeroNet. Start your own ZeroNet for complete experience. Learn More