Исходное сообщение
"GitHub опубликовал судебное решение, имеющее отношение к бло..." Отправлено p2p_or_offline, 31-Окт-20 18:53
Общий подход для публикации изменчивого контента в IPFS - это подписать хэш актуального материала своим секретным ключом и ссылаться на него через соответствующий публичный ключ, который, в отличие от статического хэша, всегда остаётся одинаковым. При запросе нового материала клиенту в ответ приходит из DHT свежий (в теории) статический хэш, подписанный ключом автора. И далее сам материал запрашивается из сети уже известным образом по этому хэшу. Всё вместе это называется IPNS, и все необходимые команды встроены в сам ipfs. Впрочем, IPNS может получать хэши также из некоторых других обновляемых источников, например из специально оформленных TXT-записей в обычном DNS. С Git сложность ещё и в том, что не очень понятно, как получить хотя бы статический хэш репозитория. Первой попыткой решить это "в лоб" был скрипт https://github.com/whyrusleeping/git-ipfs-rehost , прямолинейно перепаковывающий объекты существующего git-репозитория в IPFS. Однако для практического применения он совершенно не годился. Следующим шагом стала поддержка плагинов, одним из которых и стал плагин для работы с git-объектами. Говоря в общем, необходим он для того, чтобы полностью избежать ненужного дублирования данных при добавлении git-репозитория в IPFS. Этого, однако, недостаточно, и для самого Git необходим способ взаимодействия с IPFS. И таким способом стал remote-хелпер https://github.com/ipfs-shipyard/git-remote-ipld , который по замыслу должен уметь добавлять (или создавать) IPNS-ключ в качестве remote-ветки и делать прямо в него push своих коммитов. Однако пока он этого до конца не делает. И вот как-то на этом месте всё с тех пор так и заглохло. Может быть, последние события как-то их расшевелят в этом направлении. Ну и краткая выжимка того, как это всё на данный момент выглядит https://github.com/ipfs/notes/issues/45#issuecomment-403246530

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Общий подход для публикации изменчивого контента в IPFS - это подписать хэш > актуального материала своим секретным ключом и ссылаться на него через соответствующий > публичный ключ, который, в отличие от статического хэша, всегда остаётся одинаковым. > При запросе нового материала клиенту в ответ приходит из DHT свежий > (в теории) статический хэш, подписанный ключом автора. И далее сам материал > запрашивается из сети уже известным образом по этому хэшу. Всё вместе > это называется IPNS, и все необходимые команды встроены в сам ipfs. > Впрочем, IPNS может получать хэши также из некоторых других обновляемых источников, > например из специально оформленных TXT-записей в обычном DNS. > С Git сложность ещё и в том, что не очень понятно, как > получить хотя бы статический хэш репозитория. Первой попыткой решить это "в > лоб" был скрипт https://github.com/whyrusleeping/git-ipfs-rehost , прямолинейно перепаковывающий > объекты существующего git-репозитория в IPFS. Однако для практического применения он совершенно > не годился. Следующим шагом стала поддержка плагинов, одним из которых и > стал плагин для работы с git-объектами. Говоря в общем, необходим он > для того, чтобы полностью избежать ненужного дублирования данных при добавлении git-репозитория > в IPFS. Этого, однако, недостаточно, и для самого Git необходим способ > взаимодействия с IPFS. И таким способом стал remote-хелпер https://github.com/ipfs-shipyard/git-remote-ipld > , который по замыслу должен уметь добавлять (или создавать) IPNS-ключ в > качестве remote-ветки и делать прямо в него push своих коммитов. Однако > пока он этого до конца не делает. И вот как-то на > этом месте всё с тех пор так и заглохло. Может быть, > последние события как-то их расшевелят в этом направлении. > Ну и краткая выжимка того, как это всё на данный момент выглядит > https://github.com/ipfs/notes/issues/45#issuecomment-403246530
	Введите код, изображенный на картинке: