Открылся P2P-хостинг картинок IPFS (InterPlanetary File System)

    По адресу ipfs.pics начал работу бесплатный хостинг картинок. Казалось бы, что тут интересного? С виду обычный бесплатный хостинг, разве что без рекламы. Но IPFS.pics отличается от всех подобных проектов, потому что основан на распределённой файловой системе InterPlanetary File System. Файлы хранятся не на центральном сервере, а в P2P-сети пользователей, которые добровольно принимают участие в проекте.

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

    Хеш соответствует названию файла.

    http://ipfs.pics/ipfs/QmcT99xWRNDAYunp7Zr8wGiwMKSgVfDpfbXw9hBtLCM4Mm


    Для загрузки файла достаточно знать его хеш, даже если веб-сайт IPFS не работает.

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

    Исходный код сервера открыт. Неиспользуемые вычислительные мощности жертвуются проекту по распределённому поиску лекарств Folding@Home.

    Судя по коду проекта, пока что (временно) для бэкенда используется S3, но от него откажутся при регистрации в сети большого количества узлов.

    Запуск узла IPFS:

    ipfs bootstrap add /ip4/45.55.151.20/tcp/4001/ipfs/QmdkJZUWnVkEc6yfptVu4LWY8nHkEnGwsxqQ233QSGj8UP

    P.S. Раньше разработчики IPFS создали криптовалюту, привязанную к распределённому файлохостингу, Filecoin.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 13

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


      А почему 46 байт? 16 байт UUID'а им показалось недостаточно?
        0
        UUID тут не подходит, идентификатор должен однозначно зависеть от содержимого файла, а не генерироваться случайно. Взяли с запасом — чтобы избежать атаки дней рождения с учётом возможных атак злонамеренных личностей. Например, правообладателей (вспомним фирмочки, выкладывавшие мусор с привлекательными названиями в P2P-сети).
        Кстати, неясно, насколько сеть защищена от целенаправленного захламления большим количеством мусорных файлов.
          0
          Я скорее про длину. 16 байт — это и так уже с большим запасом.
            +2
            Насколько я понял статью Mithgol, раздаются только те файлы, которые запрашиваются. Чтобы замусорить сеть, нужно одновременно раздавать и запрашивать мусор на разных краях сети. Это вроде бы не невозможно, но заметно дороже, чем в некоторых других P2P-схемах.
              0
              Замусорить сеть «можно», но для этого понадобится не менее квадриллиона иоттабайтов.
                0
                Для замусоривания сети достаточно, чтобы объём хранимого там мусора на порядки превышал объём полезной информации. Вряд ли участникам сети будет интересно замусоривать свои хранилища терабайтами бессмыслицы, среди которых сиротливо вкраплены отдельные байты чего-то нужного. Квадриллионы йоттабайтов — это для коллизии хешей.
                А вот принцип раздачи только запрошенных файлов, про который говорит ruikarikun, как раз решает проблему с мусором, хотя при этом начинаешь задумываться о том, не начнут ли становиться недоступными непопулярные, но всё же полезные файлы.
          +2
          странная валидация, попытка «угадать хэш» ipfs.pics/ipfs/QmcT99xWRNDAYunp7Zr8wGiwMKSgVfDpfbXw9hBtLCM4Ma (a вместо m ) заставило сервер сильно призадуматься — минут 5 уже ищет
          надеюсь ничего там не сломал
            +1
            Это не валидация. Он просто ищет картинку по всем пирам (по цепочке).
            Если картинка есть — все просто, ее отдаст первый же откликнувшийся пир у которого имеется ее копия.
            Но вот если ее нет — сложнее, тут же нет центрального сервера с БД всех имеющихся картинок (хотя бы их перечнем), который сразу бы ответил — такого файла в нашей сети нет, идите лесом. Если нет у 100 опрошенных пиров, не значит что ее не может быть у 101го.

            Если же задать некорректный хэш (нарушить формат) то проверка и ответ приходят быстро (пару раз проробовал порядка 200-300 мс задержка) и выдает что-то такое:
            Path Resolve error: multihash length inconsistent: &{1 97 [42 112 107 115 78 68 200 48 108 223 141 125 203 120 242 53 141 189 109 235 67 196 53 250 11 151 16 103 192 73 133]}

            А вот корректный хэш, но от несуществующей в реальности картинки — да, задумывается надолго. Правда врядли это какую-то нагрузку значительную создает, скорее всего это просто ожидание истечения таймаутов у пиров которые недавно были в сети (и поэтому еще числятся активными), но отключились/имеют проблемы со связью.
              0
              Просто хэшу не помешал бы какой-нибудь контрольный символ, по которому можно было бы проверять формальную корректность хэша без опроса всех пиров. Это застраховало бы от задержек при подобных «опечатках».
            +1
            P.S. Раньше разработчики IPFS запустили криптовалюту, привязанную к распределённому файлохостингу, Filecoin.

            Поправка — создали (большую часть по крайней мере), но пока так еще и не запустили.
            А жаль, читал про нее давно, идея понравилось. Но пока так и не дождался опробовать в реальной работе…
              +5
              Всё плохо.
              image
                0
                Все работает. Вероятно был «хаброэффект» по случаю запуска. В сети уже тысячи изображений залито и используется.

                Кстати можно посмотреть что обычно сейчас заливают другие пользователи: ipfs.pics/random — при каждом новом клике случайно выбирается любая из картинок хранящихся в этой p2p сети
                0
                Судя по коду проекта, пока что (временно) для бэкенда используется S3, но от него откажутся при регистрации в сети большого количества узлов.
                при этом IP в бутстрапе:
                ipfs bootstrap add /ip4/45.55.151.20/tcp/4001/ipfs/QmdkJZUWnVkEc6yfptVu4LWY8nHkEnGwsxqQ233QSGj8UP
                — относится к сети Digital Ocean; в этот же IP разрешается домен ipfs.pics.

                Может там всё-таки только DO, без S3?

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

                Самое читаемое