- PVSM.RU - https://www.pvsm.ru -
SSB (Secure Scuttlebutt [1]) - это децентрализованная социальная сеть и протокол, на основе которого она работает. git-ssb заворачивает обычные git-репозитории в этот протокол. SSB хочет заменить собой Facebook, а git-ssb - GitHub. Под катом - краткое руководство по git-ssb. Актуально для тех, кому дискомфортна сама идея использования централизованных сервисов в качестве посредника. Своеобразная красная таблетка с полагающимися в этом случае неожиданными последствиями.
Протокол SSB описывает правила синхронизации ваших данных между заинтересованными в них узлами сети. Ваши данные - это история ваших действий в сети, связный список json-объектов. Связь задаётся hash-суммой предыдущего объекта (как в блокчейне). Таким образом, однажды опубликованные объекты неизменяемы и неудаляемы. Добавлять можно только в конец списка. Типичный use case предполагает, что каждый объект в списке - это пост или комментарий в блоге. Картинки и другие тяжёлые объекты хранятся вне списка в виде blob-ов и реплицируются отдельно. Объекты в списке могут на них ссылаться.
Большинство пользователей сети ведут блоги в приложениях Patchwork [2] и Manyverse [3]. Приложений для ведения блогов около десятка, они, в основном, совместимы друг с другом и отличаются интерфейсом. Кроме этого есть шахматы, чат, менеджер пакетов (ssb-npm) и git (git-ssb) [4]. Некоторые разработчики SSB используют git-ssb [5] как основной сервис для управления версиями исходников. Мы тоже попробуем.
ssb-server нужен для синхронизации с другими узлами в p2p сети. Он должен быть запущен, когда вы делаете push, pull, fetch, создаёте pull-request или форкаете репозиторий.
Пакет git-ssb включает:
программу для управления репозиториями (git-ssb)
git-remote-helper [6], который понимает адреса, начинающиеся с ssb://
web-интерфейс [5], отдалённо напоминающий GitHub
Все три компонента взаимодействуют с запущенным на вашей машине ssb-server.
$ sudo apt install git nodejs npm
$ npm install ssb-server git-ssb
ssb-server и git-ssb установятся в папку $HOME/node_modules
. Чтобы было удобнее их вызывать, добавьте в конец файла ~/.profile
стоки:
if [ -d "$HOME/node_modules/.bin/" ] ; then
PATH="$HOME/node_modules/.bin/:$PATH"
fi
Чтобы переменная $PATH
обновилась в текущей сессии, наберите
$ source ~/.profile
При логине файл ~/.profile
должен исполниться автоматически. Некоторые среды рабочего стола (например, Xfce) этого не делают. Если после перезагрузки переменная $PATH
не обновилась, то добавьте в .xsessionrc
явный вызов ~/.profile
:
. ~/.profile
Запустите ssb-server и оставьте его работающим на время экспериментов.
$ ssb-server start
При первом запуске он создаст identity по умолчанию в папке ~/.ssb
.
Инвайт нужен для того, чтобы другие узлы сети узнали о вашем существовании. Узел, который выдаст вам инвайт, подпишется на вас и будет реплицировать ваши данные. Через него это смогут сделать и другие пользователи. Без инвайта можно, но сложнее.
У каждого узла могут быть свои правила выдачи инвайта. На данный момент большинство узлов ничего не спрашивают и просто дают строку, которую нужно скопировать. Список выдающих инвайты узлов. [7] Примите инвайт, подставив полученную строку в следующую команду.
$ ssb-server invite.accept <ваш-инвайт-код>
Теперь вы с тем узлом взаимные друзья: вы начинаете копировать себе данные его и его друзей, а он - ваши.
@cel - это разработчик git-ssb.
$ ssb-server publish --type contact --contact "@f/6sQ6d2CMxRUhLpspgGIulDxDCwYD7DzFzPNr7u5AU=.ed25519" --following
Сейчас в папку ~/.ssb
скачается около 1Gb данных - это его история (там и его git-репозитории) и истории тех пользователей, на которых он подписан. Эта подписка нужна, чтобы последующие примеры у всех работали примерно одинаково.
Установка и настройка завершены. Теперь вы многое можете:
$ git-ssb-web
Перейдя по напечатанной в консоли ссылке вы увидите хронологический список коммитов, issue и других действий в видимых репозиториях. Это, разумеется, не всё, а только то, что скачалось после подписки на предыдущем шаге. Нажав на имя пользователя вы увидите его activity log, нажав на репозиторий - интерфейс, похожий на GitHub.
Все ваши действия в web-интерфейсе (например, комментарий, создание issue или форка) запишутся в вашу историю и уйдут вашим подписчикам при синхронизации. Если вы в данный момент отключены от сети, то этот интерфейс будет продолжать работать: репозитории будут форкаться, issue создаваться и т.д.. ssb-server работает (вы же его ещё не выключили) и отправит все ваши изменения как только сеть появится.
$ mkdir my-new-repo
$ cd my-new-repo
$ git init
Initialized empty Git repository in /tmp/my-new-repo/.git/
$ git-ssb create ssb my-new-repo
Created repo: ssb://<hash-code>.sha256 (my-new-repo)
Added remote: ssb
$ git remote -v
ssb ssb://<hash-code>.sha256 (fetch)
ssb ssb://<hash-code>.sha256 (push)
К привычному git init
добавилась команда git-ssb create ssb my-new-repo
, которая запишет в вашу историю факт создания нового репозитория с именем my-new-repo
и добавит его URL в качестве remote с именем ssb
. Аналогичным образом можно добавить такой remote к любому существующему репозиторию.
Вы добавили ssb ссылку в качестве дополнительного remote к вашему репозиторию. Теперь можно пушить.
Важно: невозможно удалить что-то из SSB. Не ставьте эксперименты на чувствительных данных.
$ git push ssb master
Если репозиторий большой, то может не получиться. В git-ssb допустимый размер pack-файла [8] зависит от максимального размера blob, а он ограничен 5Mb. Больший размер сеть не примет. Но закоммитить, тем не менее, возможно:
$ git push ssb master -o allow-big
Это не сделает вашу историю невалидной (blob синхронизируются отдельно от истории), но скачать большой pack-файл другие пользователи не смогут, пока не увеличат у себя в настройках [9] максимальный размер blob.
Альтернативный способ вписаться в ограничение на размер pack-файла - это пушить небольшими порциями так, чтобы создаваемые git-ом pack-файлы не превышали 5Mb.
Будем ставить эксперименты с git-ssb на репозитории git-ssb [10]. В SSB нет DNS и красивых названий чего бы то ни было. Ссылку на репозиторий ssb://%n92DiQh7ietE+R+X/I403LQoyf2DtR3WQfCkDKlheQU=.sha256
я скопировал из web-интерфейса.
$ git clone ssb://%n92DiQh7ietE+R+X/I403LQoyf2DtR3WQfCkDKlheQU=.sha256 git-ssb
$ cd git-ssb
$ git remote -v
origin ssb://%n92DiQh7ietE+R+X/I403LQoyf2DtR3WQfCkDKlheQU=.sha256 (fetch)
origin ssb://%n92DiQh7ietE+R+X/I403LQoyf2DtR3WQfCkDKlheQU=.sha256 (push)
В этом репозитории у нас единственный remote, и он из SSB.
$ git-ssb fork my-fork
Created repo: ssb://<new-hash-code>.sha256 (git-ssb)
Added remote: my-fork
$ git remote -v
my-fork ssb://<new-hash-code>.sha256 (fetch)
my-fork ssb://<new-hash-code>.sha256 (push)
origin ssb://%n92DiQh7ietE+R+X/I403LQoyf2DtR3WQfCkDKlheQU=.sha256 (fetch)
origin ssb://%n92DiQh7ietE+R+X/I403LQoyf2DtR3WQfCkDKlheQU=.sha256 (push)
В вашей истории появится запись о создании нового репозитория, а в текущей папке добавится новый remote.
Вы внесли изменения и сделали коммит.
$ git-ssb pull-request
Откроется текстовый редактор, вы напишете описание ваших изменений. После сохранения распечатается новый объект, добавленный в вашу историю.
Это не баг, а фича. Согласно документации (git-ssb-intro [11]), это одна из принятых моделей совместной работы. Вы создаёте в чужом репозитории ветку с именем @ваш-юзернейм/master
(git checkout -b @ваш-юзернейм/master
), пушите в неё (git push ssb
), а после делаете пулл-реквест (git ssb pull-request
). Но ничто не помешает вам запушить прямо в master без всяких пулл-реквестов.
Возможность асинхронного внесения изменений в одну ветку может привести к конфликту, если при помощи двух разных identity (про identity - см. ниже) были созданы два конкурирующих коммита. Когда git-ssb встречает такие ситуации, он просит пользователя сделать слияние этих альтернативных версий. Всё это происходит локально на вашем компьютере. Если вы не подписаны на ту другую identity, которая пушит в ваш репозиторий, то вы не увидите никакого конфликта. Другие же пользователи, которые на неё подписаны, увидят. Таким образом, один и тот же репозиторий будет выглядеть по-разному в зависимости от того, чьи обновления вы получаете.
Identity задаётся закрытым ключом в файле ~/.$ssb_appname/secret
. Если переменная ssb_appname
не задана, то будет использована identity по умолчанию (~/.ssb
). Если в указанном месте нет файла secret
, то ssb-server его создаст со случайным ключом.
Положительная сторона этой вседозволенности permissionless модели в том, что вы можете работать с одним репозиторием с нескольких устройств, на которых установлены разные identity.
С другой стороны, это может привести к распространению вредоносного кода: вы делаете что-то полезное, все об этом знают, клонируют и делают sudo make install
не глядя в историю коммитов. У одних пользователей установится ваше приложение, а у других - ваше приложение с добавлением зловреда. Возможно, что даже вы сами не увидите, что после очередного git pull
у вас появились чужие коммиты. Тогда зловред придёт к каждому, в том числе и к вам.
Обсуждение этой возможности [12] внутри SSB.
git-ssb-intro: a guide to hacking together on the distributed web [11]
Другие способы децентрализации git:
GitTorrent (на основе BitTorrent)
HyperGit (на основе Dat)
igis-remote (на основе IPFS)
ipld-remote (на основе IPFS)
GitCenter (на основе ZeroNet)
Mango [13] (Ethereum + IPFS)
Radicle [14]
Gitopia [15]
Первые четыре подробно проанализированы в статье Daniel Aleksandersen "Four P2P distribution tools for Git repositories compared [16]". К ней есть комментарии [17] разработчиков SSB.
Спасибо за внимание. Надеюсь, что было не очень скучно. Хорошей децентрализации тем, кому это важно.
Картинка в шапке сгенерирована при помощи сервиса myoctocat.com [18].
Автор: solarfunk
Источник [19]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/git/360730
Ссылки в тексте:
[1] Secure Scuttlebutt: https://scuttlebutt.nz/
[2] Patchwork: https://github.com/ssbc/patchwork
[3] Manyverse: https://www.manyver.se/
[4] шахматы, чат, менеджер пакетов (ssb-npm) и git (git-ssb): https://handbook.scuttlebutt.nz/applications
[5] git-ssb: https://git.scuttlebot.io/
[6] git-remote-helper: https://git-scm.com/docs/gitremote-helpers
[7] Список выдающих инвайты узлов.: https://github.com/ssbc/ssb-server/wiki/Pub-Servers
[8] pack-файла: https://git-scm.com/book/en/v2/Git-Internals-Packfiles
[9] настройках: https://github.com/ssbc/ssb-blobs
[10] git-ssb: https://git.scuttlebot.io/%25n92DiQh7ietE%2BR%2BX%2FI403LQoyf2DtR3WQfCkDKlheQU%3D.sha256
[11] git-ssb-intro: https://git.scuttlebot.io/%25RPKzL382v2fAia5HuDNHD5kkFdlP7bGvXQApSXqOBwc%3D.sha256
[12] Обсуждение этой возможности: http://ssb.cosmocr.at/%25r%2F6bLB3kimrlHqOUKAgHqXFyrVLW90xLM0%2F9j6FsM1s%3D.sha256
[13] Mango: https://medium.com/@alexberegszaszi/mango-git-completely-decentralised-7aef8bcbcfe6
[14] Radicle: https://radicle.xyz/
[15] Gitopia: https://gitopia.org
[16] Four P2P distribution tools for Git repositories compared: https://www.ctrl.blog/entry/git-p2p-compared.html
[17] комментарии: http://ssb.cosmocr.at/%25zOnBq32Q5llDNTK4TP5OUzprKQ0Bxrlg7jCgGIXEhXs%3D.sha256
[18] myoctocat.com: https://myoctocat.com
[19] Источник: https://habr.com/ru/post/537678/?utm_source=habrahabr&utm_medium=rss&utm_campaign=537678
Нажмите здесь для печати.