Cloudflare представила шлюз IPFS для создания децентрализованных сайтов

Cloudflare представила шлюз IPFS, чтобы поощрить разработчиков создавать сайты на основе распределенной технологии peer-to-peer. По словам компании, это решение может быть использовано для доступа к контенту InterPlanetary File System (IPFS) без необходимости установки специального клиента.

Такой подход поможет пользователям создавать сайты, основанные на распределенных, а не централизованных моделях. В Cloudflare надеются, что шлюз «станет платформой для многих высоконадежных и безопасных веб-приложений». Разница между традиционными вызовами веб-сайтом контента и IPFS сводится к характеру запросов и тому, как управляется этот самый контент. Как правило, вы получаете доступ к сайту через браузер, запрашивая данные, которые хранятся на определенном IP-адресе. В этом случае Сеть выполнят поиск и возвращает найденную информацию.

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

Таким образом, DDoS-атаки могут спровоцировать падение серверов, которые отвечают за определенный веб-сайт, и пользователи не смогут получить доступ к домену. Однако, если имеются доступные зеркала, на которых хранятся сайты, можно не только сохранить, но и кешировать контент. Это избавит от необходимости полагаться на один серверный блок. IPFS не обрабатывает такие запросы через централизованные запросы, вместо этого они получаются основанными на контенте. Блоки данных, хранящиеся в системе, обрабатываются криптографическими хешами. Запросы на доступ к контенту создаются с помощью хеша, а не IP.

«Следовательно вместо того, чтобы выполнять запрос — ‘’дай мне контент, хранящийся на 93.184.216.34’’, вы выполняете запрос — ‘’дай мне контент, имеющий хэш-значение QmXnnyufdzAWL5CqZ2RnSN gPbvCc1ALT73s6epPrRnZ1Xy’’», — объясняет Cloudflare.

Источник

Цитата:

«Следовательно вместо того, чтобы выполнять запрос — ‘’дай мне контент, хранящийся на 93.184.216.34’’, вы выполняете запрос — ‘’дай мне контент, имеющий хэш-значение QmXnnyufdzAWL5CqZ2RnSN gPbvCc1ALT73s6epPrRnZ1Xy’’», — объясняет Cloudflare.

... и таким образом уже по запросу можно будет видеть, за каким контентом обращается пользователь. Прощай, анонимность.

Лучше бы обязали разработчиков приложений давать скачать ранние версии их продуктов, например ВК)

dimitriy7
+
Какая инфа будет в том хеше..

Цитата:

«Следовательно вместо того, чтобы выполнять запрос — ‘’дай мне контент, хранящийся на 93.184.216.34’’, вы выполняете запрос — ‘’дай мне контент, имеющий хэш-значение QmXnnyufdzAWL5CqZ2RnSN gPbvCc1ALT73s6epPrRnZ1Xy’’», — объясняет Cloudflare.

Чтобы построить хеш нужно как минимум получить доступ к контенту.
Что-то теряется смысл...

Цитата:

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

А мне вот интересно чем это принципиально отличается от CDN. Технически само собой понятно как. А вот проблема slave-master все та же.. И каково время отклика? В свою очередь чем обеспечивается актуальность данных на узле? Опять же csfr-токены, которые теперь всюду есть. Статья ради статьи...

Cloudflare уже порядком мозги мне запарил. Частенько хожу на некоторые сайты через Tor-сети, всё бы ничего, но капча кривая там. Видимо преднамеренно это делают - для деаномизации пользователей ресурсов. К сайтам которые применяют Cloudflare стал относиться с пренебрежением. Ничего хорошего кроме потери безопасности для пользователей не светит. Короче отменная гадость этот Cloudflare.
Я бы предложил создать чёрный список веб-ресурсов что используют сию защиту. Так сказать лист позора, чьи сайты лучше избегать от посещений.

Цитата:

А мне вот интересно чем это принципиально отличается от CDN. Технически само собой понятно как.

1. С IPFS, каждый сам себе CDN, да хоть внутри своей сети.
2. Бесплатно
3. При желании контент можно "прикрепить", чтобы не пропал.

Цитата:

А вот проблема slave-master все та же..

Нету slave-master. Есть только ноды с контентом, а есть без. Если запрашиваешь хеш у ноды у которой его нет, то она поищет его для тебя и закеширует его для будущих запросов.

С обновлением контента сложнее - хеш данных изменить нельзя. Но можно обновлять /IPNS хеш - это такой хитрый адрес который может указывать на новую версию данных.

Цитата:

И каково время отклика?

Если данные близко, то в пределах секунд. А если их ваще нигде нету, то увы..

Цитата:

В свою очередь чем обеспечивается актуальность данных на узле?

Актуальность как сохранность - благодаря хешу контента они именно такие, как их выставили. Малейшая попытка их изменить приведёт к несовпадению.
Актуальность как свежесть - смотри на /IPNS как возможное решение