devzone.org.ua/post/radicle-detsentralizovanyy-p2p-khostynh-gitdvcs.md

Radicle: децентралізований P2P хостинг Git/DVCS

Radicle - це відносно новий проєкт з відкритим кодом, написаний мовою Rust, що реалізує пірингову модель хостингу Git/DVCS (Distributed Version Control System)

Знав я про нього раніше, і вже встиг трішки поекспериментувати, змусивши привітних розробників навіть підключити цікавий мені пір Yggdrasil.

Утім, через деякий час я відклав ці експерименти, оскільки на той час "вдарився" в тему мережної гігієни. Radicle - націлений на конективність, і розробники не дуже розуміли чому я хочу бачити "чисті" з'єднання на потрібну мені мережу. Утім, це стосується всієї тематики BitTorrent / DHT і якщо у вас крутяться торенти і вони у вашій країні не обмежені законодавством, то дана платформа може бути цікавою: адже дозволяє будувати відмово-стійкі (а в певній конфігурації - цензуро-стійкі) децентралізовані репозиторії, подібно до того, як це відбувається в IPFS, але фокусом на контроль версій та інтуїтивний API, що базується на Git.

Окрім базового набору команд git (які тут обгорнуті в rad) комплекс Radicle реалізує розширену функціональність з пірингової синхронізації:

• облікових записів користувачів
• їх соціальної активності (issues, patches / PR, тощо)
• та поточного стану самого сховища з іншими вузлами

Як майже всюди в децентралізованій індустрії, облікові записи в Radicle базуються на асиметричній криптографії Ed25519, тому реєструючись в мережі, потрібно зробити резервне копіювання профілю. Якщо приватний ключ профілю буде втрачено, то ніякий сапорт не допоможе бо його тут немає.

Щоб зорієнтуватись наочно, розглянемо як схематично виглядає типовий програмний комплекс:

┌─────────────────┐┌────────────────┐
│  Radicle CLI    ││ Radicle Web    │
└─────────────────┘└────────────────┘
┌───────────────────────────────────┐
│  Radicle Repository               │
│ ┌────────┐ ┌────────┐ ┌─────────┐ │
│ │  code  │ │ issues │ │ patches │ │
│ └────────┘ └────────┘ └─────────┘ │
├───────────────────────────────────┤
│  Radicle Storage (Git)            │
└───────────────────────────────────┘
┌────────────────┐┌─────────────────┐
│  Radicle Node  ││  Radicle HTTPD  │
├────────────────┤├─────────────────┤
│    NoiseXK     ││   HTTP + JSON   │
└────────────────┘└─────────────────┘

• Radicle CLI - це клієнтський інтерфейс командного рядка та частково P2P обгортка для git
• Radicle Web - локальний веб-інтерфейс для перегляду репозиторію в браузері
• Radicle Repository - ядро VCS
• Radicle Node - P2P складова для синхронізації вашого коду та коду який ви читаєте (що цікаво, в екосистемі Radicle замість зірочок використовується функція "Seed", якщо у вас наприклад вузол розгорнуто на VPS з виділеним IP - можна таким чином підтримати цікавий вам проєкт його ресідінгом)
• Radicle HTTPD - відповідає за високорівневе Веб-API

Усі ці компоненти ставити окремо не обов'язково, розглянемо тільки базовий мінімум для організації свого репозиторію та публікації його коду через локальний вузол на публічні сервери провайдерів мережі з метою поширення коду з іншими користувачами, у яких інфраструктура Radicle може бути не встановлена.

Встановлення

На сайті є схожий до Rustup скрипт інсталяції "в одну команду":

curl -sSf https://radicle.dev/install | sh

Але Radicle - не Rustup і я вирішив зібратись руками, за одно для себе краще зрозумівши як це працює (офіційний гайд).

git clone https://iris.radicle.xyz/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git heartwood
cd heartwood
cargo install --path crates/radicle-cli --force --locked --root ~/.radicle
cargo install --path crates/radicle-node --force --locked --root ~/.radicle
cargo install --path crates/radicle-remote-helper --force --locked --root ~/.radicle

• само собою, для збірки проєктів Rust з вихідного коду, у вас повинна бути розгорнута відповідна інфраструктура (наприклад, засобами того ж Rustup)
• вихідний код heartwood можна забрати zip-архівом або іншим зручним способом, приклад з git clone передбачає, що у вас під рукою саме Git
• останніми командами компілюємо мінімальний набір radicle-cli, radicle-node і radicle-remote-helper
• radicle-remote-helper тут треба як системна залежність між radicle-cli і radicle-node

Оскільки ми вказали шлях встановлення бінарних пакетів як --root ~/.radicle, потрібно окремо зареєструвати ці шляхи у файлі ~/.bashrc:

export PATH="$HOME/.radicle/bin:$PATH"

• ці зміни застосуються для нової сесії терміналу (або виконайте аналогічну команду для поточної)

radicle-cli

Встановивши radicle-cli, можна працювати з віддаленими та локальними репозиторіями: наприклад клонувати код з вузлів Radicle за їх хешем або працювати з локальним сховищем до його публікації. Як згадувалось вище, для роботи з кодом в Radicle використовується команда rad:

rad --help

Наша мета - ознайомитись з екосистемою, тому спробуймо розмістити власний код десь в когось. Для цього, спочатку створімо новий профіль користувача:

rad auth

• alias - юзернейм
• passphrase - пароль

В системах Linux, дані створеного профілю Radicle будуть стандартно розміщені в теці ~/.radicle; приватний ключ (який варто забекапити) знаходиться в ~/.radicle/keys/radicle

• тут глянув права: 0600 - молодці, часто про цей нюанс розробники забувають і його можна дістати траверсом, тут же з цим все окей.

Подивитись інформацію про свій новостворений профіль можна командою:

rad self

Тепер можемо додати перший репозиторій, а точніше - прив'язати існуючий репозиторій Git до нового апстріму Radicle. Для цього власне спершу потрібно ініціювати репозиторій Git, він повинен містити щонайменше один коміт:

mkdir ~/repo
cd ~/repo
git init
echo -e 'hello world' >> test.txt
git add .
git commit -m 'initial commit'

• логічно, що можна взяти готовий репозиторій у якості донору для тестів, але для перших кроків краще створити тестовий з одним файлом (насправді на вузлах стандартного провайдера стільки цих тестових репозиторіїв, що я досі не бачив там справжніх проєктів)
• варто зауважити, що в Radicle використовуються метадані профілю Git (username, e-mail тощо)

Коли стандартний репозиторій Git підготовлено, з теки проєкту, ініціюємо для нього середовище:

rad init

• Name - назва репозиторію (в Radicle для ідентифікації використовуються унікальні хеші)
• Description - опис проєкту
• Default branch - master (класика)
• Visibility - вказуємо публічний, щоб мати можливість його перевірити після публікації в мережі Radicle

Типових команд rad commit / rad push тут немає, бо rad - це лише пірингова обгортка для git. Для реєстрації змін, використовується саме рівень Git: git commit / git push... Якщо вказати git status то побачимо, що в апстрім Git командою rad init раніше було додано rad/master. Таким чином, коли змінюється код, зміни фіксуються як завжди - через git commit / git push і при увімкненому вузлі Radicle - ці зміни автоматично синхронізуються з P2P мережею та іншими сховищами, якщо такі є (наприклад Radicle, Codeberg і GitHub).

Якщо для наявного репозиторію вже налаштований апстрім origin (наприклад, на Codeberg) потрібно вручну додати rad до pushurl в .git/config. Не знаю, чому це не відбувається на етапіrad init, утім робиться це наступними командами:

git remote set-url --add --push origin <URL_ВАШОГО_ORIGIN>
git remote set-url --add --push origin <URL_ВАШОГО_RAD>

• <URL_ВАШОГО_ORIGIN> - у мене Codeberg
• <URL_ВАШОГО_RAD> - Radicle
• дізнатись обидві адреси URL, можна командою git remote -v - відповідно, це має бути секція push (за потреби, аналогічні кроки виконуються і для fetch)

Перевірити список проініціалізованих репозиторіїв Radicle, можна командою:

rad ls

• тут повинен бути щойно створений репозиторій

Переглянути поточний, в якому зараз знаходитесь, командою:

rad .

radicle-node

Перш як запускати вузол Radicle, рекомендую перевірити та актуалізувати публічні піри, засобами яких відбуватиметься підключення та синхронізація з мережею:

rad config

• звертаємо увагу на publicExplorer і preferredSeeds
• файл конфігурації знаходиться в /.radicle/config.json

Керування вузлом відбувається групою команд rad node, усі її доступні опції можна отримати виконавши:

rad node --help

Перед git push, запустимо вузол з аргументами --foreground і дебагом --verbose:

rad node start --foreground --verbose

Поточний статус вузла можна перевірити (наприклад, з іншої сесії терміналу) командою:

rad node status

Якщо не вказати --foreground, зупинити процес можна командою:

rad node stop

Після публікації змін до апстріму Radicle командою git push (з увімкненим вузлом) дані мають з'явитись на публічних ресурсах за ідентифікатором з команди rad .:

rad:z2q5m7WMZnHGzumpt7tRDyaFStVTj

Відповідно, URL мого репозиторію на сайті app.radicle.xyz та сіді iris.radicle.xyz буде:

https://app.radicle.xyz/nodes/iris.radicle.xyz/rad:z2q5m7WMZnHGzumpt7tRDyaFStVTj

Оскільки екосистема децентралізована, той же репозиторій буде доступний і на сіді rosa.radicle.xyz:

https://app.radicle.xyz/nodes/rosa.radicle.xyz/rad%3Az2q5m7WMZnHGzumpt7tRDyaFStVTj

Та на інших, які було оголошено у конфігурації Radicle, а також на вузлах, які почали вас "фоловити" (у випадку Radicle - "сідити")

Якщо після публікації з git push репозиторій не з'явився на публічних Веб-хабах - це може бути пов'язано зі швидкістю поширення даних в мережі BitTorrent, а також ймовірною перед-модерацією, не зважаючи на оголошену політику окремого сіда. Якщо локальний вузол Radicle було щойно створено, перевірте статус синхронізації командою:

rad sync status

та у разі проблем, виконайте її вручну:

rad sync

Згадка про "синхронізацію" зустрічається ще на етапі rad init та на сторінці документації:

... Your project has been announced to the network and is now discoverable by peers. You can check for any nodes that have replicated your project by running rad sync status.

Сервіс systemd

Для зручності авто-запуску при старті системи, варто створити системний сервіс.

Актуальні приклади можна отримати в офіційному репозиторії heartwood/systemd/system/*

Особиста думка

Git - по своїй архітектурі, вже є децентралізованою системою контролю версій, для якої легко налаштувати реплікацію засобами clone. Навіщо потрібен додатковий шар P2P - мабуть для доступу до вихідного коду з розподілених сховищ за NAT, що використовують свої незалежні мости.

Мережна безпека

Як писав на самому початку, для мене відкрите питання мережних витоків та моніторингу активності DHT третіми особами. В світі обміну файлами через BitTorrent, така активність використовується в першу чергу рекламними компаніями, а звідти - потенційними засобами масової маніпуляції свідомістю, в якій я бачу куди більшу загрозу щонайменше для себе. Якщо ви переймаєтесь подібними питаннями, то в Radicle я помічав міжмережний трафік при намаганні крутити його ноду через тунель (Yggdrasil) - тобто на момент публікації, якщо ви підключаєтесь виключно до вузла певної мережі (Інтернет, Yggdrasil, Tor, тощо), він видасть вам айпішники іншої, таким чином конект піде в іншу мережу.

Ноді байдуже куди конектитись і якщо ви не блокуєте подібну активність зовнішніми засобами, цей інструментарій є потенційно "брудним" як і обмін файлами через класичні торент-клієнти, що намагаються з'єднатись будь з ким аби тільки з'єднатись. Всю цю кашу наочно видно в Etherape.

Децентралізація

Тим не менше, розподілені моделі зберігання мають свої переваги в плані вибору провайдера, що може бути зручно для публікації забороненого централізованими сервісами вмісту. До "забороненого" можна віднести й публікацію бінарних файлів, якщо наприклад ви хочете законтролити певну їх ревізію, або публікуєте в репозиторії блог та бажаєте розмістити в ньому контекстні відео-файли чи фото (використання яких обмежено користувацькою угодою через ліміти дискових спроможностей централізованих сервісів). Також, децентралізовані рішення можуть бути інструментом для обходу глобальних фаєрволів, хоча особисто я вважаю такі рішення не ефективними, бо технологія BitTorrent створювалась для іншої мети.

Серед потенційних проблем пірингового VCS, бачу затримку оновлень та фрагментацію версій - цю модель потрібно перевіряти на практиці, бо з IPFS вона виявилась абсолютно провальною і технічний трафік там перевищує практичний.

У випадку Radicle, виходить, що ви так само обираєте якийсь кустарний сервер, який згодом через свою нерентабельність буде вимкнено за настроєм адміна, а у вас - залишаться по мережі мертві лінки 404, якими ділились для реклами свого продукту. Тут, як і всюди, найкраще запустити свій сервер (ноду) але знову таки, чим це буде краще за класичний сервер Git або Git + Gitea, де ви повністю контролюєте вхідні та вихідні підключення і не морочитесь при цьому з імпровізаціями PEX?

Інтерфейс

Мені досі не дуже зрозумілий Web-UI Radicle. Вони перейменували Pull в Patch, це вже збиває з толку. Я безнадійно звик до GitHub. З іншого боку, активно експериментую з переходом на протокол Gemini, а з ним - зміною концепції взаємодії з контентом: для текстових сторінок - свій застосунок, для месенджера - інший, для медіа - третій. Тобто намагаюсь відучити себе від Веб-браузеру, в який перекочувало буквально все моє життя.

В соціальному плані, тут немає властивих Веб-прошаркам тікетів, пул-реквестів та смайликів: спілкування розробників відбувається в середовищі командного рядка і більше нагадує концепцію ngit. Технічно, я думаю, що це може бути реалізовано в перспективі, утім зараз тільки Git-like CLI.

Тому, суб'єктивно, Radicle - це інструмент в першу чергу для людей, які готові змінювати свідомість та власні звички, чий розум відкритий для нового досвіду і тестування на цьому ясному розумі нових концепцій, у даному випадку - на базі старих технологій. Цей проєкт однозначно вартий уваги через як мінімум свою інтенсивність розробки і я особисто за ним з цікавістю спостерігаю.

Сфери застосування

На мою думку, Radicle слід сприймати саме як повноцінний варіант self-hosted сервера Git: як для своїх проєктів, так і для мірорингу проєктів, які вам подобаються. З тією лише відмінністю, що користувачам проєктів які вам сподобались (ресідом) - не потрібно знати ваш домен, щоб скачати потрібний їм код, при тому зробити це безпечно в плані компрометації, засобами криптографічного доказу походження оригіналу.

Посилання

• Офіційний Веб-сайт Radicle
• Офіційний канал Zulip
• Веб-інтерфейс офіційного репозиторію Heartwood