mirror of
https://codeberg.org/postscriptum/gemlog.git
synced 2026-02-18 22:12:40 +00:00
283 lines
No EOL
25 KiB
Text
283 lines
No EOL
25 KiB
Text
# Radicle: децентралізований P2P хостинг Git/DVCS
|
||
|
||
Radicle - це відносно новий проєкт з відкритим кодом, написаний мовою Rust, що реалізує пірингову модель хостингу Git/DVCS (Distributed Version Control System):
|
||
=> https://radicle.xyz
|
||
|
||
Знав я про нього раніше, і вже встиг трішки поекспериментувати, змусивши привітних розробників навіть підключити цікавий мені пір Yggdrasil:
|
||
=> https://yggdrasil-network.github.io/services.html#radicle-nodes
|
||
|
||
Утім, через деякий час я відклав ці експерименти, оскільки на той час "вдарився" в тему мережної гігієни. 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 скрипт інсталяції "в одну команду":
|
||
|
||
``` bash
|
||
curl -sSf https://radicle.dev/install | sh
|
||
```
|
||
|
||
Але Radicle - не Rustup і я вирішив зібратись руками, за одно для себе краще зрозумівши як це працює.
|
||
|
||
=> https://app.radicle.xyz/nodes/iris.radicle.xyz/rad%3Az3gqcJUoA1n9HaHKufZs5FCSGazv5#from-source Офіційний гайд
|
||
|
||
``` bash
|
||
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`:
|
||
|
||
``` ~/.bashrc
|
||
export PATH="$HOME/.radicle/bin:$PATH"
|
||
```
|
||
* ці зміни застосуються для нової сесії терміналу (або виконайте аналогічну команду для поточної)
|
||
|
||
### radicle-cli
|
||
|
||
Встановивши radicle-cli, можна працювати з віддаленими та локальними репозиторіями: наприклад клонувати код з вузлів Radicle за їх хешем або працювати з локальним сховищем до його публікації. Як згадувалось вище, для роботи з кодом в Radicle використовується команда `rad`:
|
||
|
||
``` bash
|
||
rad --help
|
||
```
|
||
|
||
Наша мета - ознайомитись з екосистемою, тому спробуймо розмістити власний код десь в когось. Для цього, спочатку створімо новий профіль користувача:
|
||
|
||
``` bash
|
||
rad auth
|
||
```
|
||
* alias - юзернейм
|
||
* passphrase - пароль
|
||
|
||
В системах Linux, дані створеного профілю Radicle будуть стандартно розміщені в теці `~/.radicle`; приватний ключ (який варто забекапити) знаходиться в `~/.radicle/keys/radicle`
|
||
* тут глянув права: 0600 - молодці, часто про цей нюанс розробники забувають і його можна дістати траверсом, тут же з цим все окей.
|
||
|
||
Подивитись інформацію про свій новостворений профіль можна командою:
|
||
|
||
``` bash
|
||
rad self
|
||
```
|
||
|
||
Тепер можемо додати перший репозиторій, а точніше - прив'язати існуючий репозиторій Git до нового апстріму Radicle. Для цього власне спершу потрібно ініціювати репозиторій Git, він повинен містити щонайменше один коміт:
|
||
|
||
``` bash
|
||
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 підготовлено, з теки проєкту, ініціюємо для нього середовище:
|
||
|
||
``` bash
|
||
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`, утім робиться це наступними командами:
|
||
|
||
``` bash
|
||
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, можна командою:
|
||
|
||
``` bash
|
||
rad ls
|
||
```
|
||
* тут повинен бути щойно створений репозиторій
|
||
|
||
Переглянути поточний, в якому зараз знаходитесь, командою:
|
||
|
||
``` bash
|
||
rad .
|
||
```
|
||
|
||
### radicle-node
|
||
|
||
Перш як запускати вузол Radicle, рекомендую перевірити та актуалізувати публічні піри, засобами яких відбуватиметься підключення та синхронізація з мережею:
|
||
|
||
``` bash
|
||
rad config
|
||
```
|
||
* звертаємо увагу на `publicExplorer` і `preferredSeeds`
|
||
* файл конфігурації знаходиться в `/.radicle/config.json`
|
||
|
||
Керування вузлом відбувається групою команд `rad node`, усі її доступні опції можна отримати виконавши:
|
||
|
||
``` bash
|
||
rad node --help
|
||
```
|
||
|
||
Перед `git push`, запустимо вузол з аргументами `--foreground` і дебагом `--verbose`:
|
||
|
||
``` bash
|
||
rad node start --foreground --verbose
|
||
```
|
||
|
||
Поточний статус вузла можна перевірити (наприклад, з іншої сесії терміналу) командою:
|
||
|
||
``` bash
|
||
rad node status
|
||
```
|
||
|
||
Якщо не вказати `--foreground`, зупинити процес можна командою:
|
||
|
||
``` bash
|
||
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 було щойно створено, перевірте статус синхронізації командою:
|
||
|
||
``` bash
|
||
rad sync status
|
||
```
|
||
|
||
та у разі проблем, виконайте її вручну:
|
||
|
||
``` bash
|
||
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`.
|
||
|
||
та на сторінці документації:
|
||
|
||
=> https://radicle.xyz/guides/user#git-going-with-repositories
|
||
|
||
### Сервіс systemd
|
||
|
||
Для зручності авто-запуску при старті системи, варто створити системний сервіс. У такому випадку, бінарні файли `rad`, `radicle-node` і `git-remote-rad` розміщуються у глобальному просторі `/usr/local/bin` замість `~/.radicle/bin`, інакше можуть виникнути проблеми з правами на запуск сервісу через обмеження середовища.
|
||
|
||
Актуальні приклади можна отримати в офіційному репозиторії:
|
||
=> https://app.radicle.xyz/nodes/iris.radicle.xyz/rad%3Az3gqcJUoA1n9HaHKufZs5FCSGazv5/tree/systemd/ heartwood/systemd
|
||
|
||
## Особиста думка
|
||
|
||
Git - по своїй архітектурі, вже є децентралізованою системою контролю версій, для якої легко налаштувати реплікацію засобами clone. Навіщо потрібен додатковий шар P2P - мабуть для доступу до вихідного коду з розподілених сховищ за NAT, що використовують свої незалежні мости.
|
||
|
||
### Мережна безпека
|
||
|
||
Як писав на самому початку, для мене відкрите питання мережних витоків та моніторингу активності DHT третіми особами. В світі обміну файлами через BitTorrent, така активність використовується в першу чергу рекламними компаніями, а звідти - потенційними засобами масової маніпуляції свідомістю, в якій я бачу куди більшу загрозу щонайменше для себе. Якщо ви переймаєтесь подібними питаннями, то в Radicle я помічав міжмережний трафік при намаганні крутити його ноду через тунель (Yggdrasil) - тобто на момент публікації, якщо ви підключаєтесь виключно до вузла певної мережі (Інтернет, Yggdrasil, Tor, тощо), він видасть вам айпішники іншої, таким чином конект піде в іншу мережу.
|
||
|
||
Ноді байдуже куди конектитись і якщо ви не блокуєте подібну активність зовнішніми засобами, цей інструментарій є потенційно "брудним" як і обмін файлами через класичні торент-клієнти, що намагаються з'єднатись будь з ким аби тільки з'єднатись. Всю цю кашу наочно видно в Etherape:
|
||
|
||
=> https://etherape.sourceforge.io
|
||
|
||
### Децентралізація
|
||
|
||
Тим не менше, розподілені моделі зберігання мають свої переваги в плані вибору провайдера, що може бути зручно для публікації забороненого централізованими сервісами вмісту. До "забороненого" можна віднести й публікацію бінарних файлів, якщо наприклад ви хочете законтролити певну їх ревізію, або публікуєте в репозиторії блог та бажаєте розмістити в ньому контекстні відео-файли чи фото (використання яких обмежено користувацькою угодою через ліміти дискових спроможностей централізованих сервісів). Також, децентралізовані рішення можуть бути інструментом для обходу глобальних фаєрволів, хоча особисто я вважаю такі рішення не ефективними, бо технологія BitTorrent створювалась для іншої мети.
|
||
|
||
Серед потенційних проблем пірингового VCS, бачу затримку оновлень та фрагментацію версій - цю модель потрібно перевіряти на практиці, бо з IPFS вона виявилась абсолютно провальною і технічний трафік там перевищує практичний.
|
||
|
||
У випадку Radicle, виходить, що ви так само обираєте якийсь кустарний сервер, який згодом через свою нерентабельність буде вимкнено за настроєм адміна, а у вас - залишаться по мережі мертві лінки 404, якими ділились для реклами свого продукту. Тут, як і всюди, найкраще запустити свій сервер (ноду) але знову таки, чим це буде краще за класичний сервер Git або Git + Gitea, де ви повністю контролюєте вхідні та вихідні підключення і не морочитесь при цьому з імпровізаціями PEX?
|
||
|
||
### Інтерфейс
|
||
|
||
Мені досі не дуже зрозумілий Web-UI Radicle. Вони перейменували Pull в Patch, це вже збиває з толку. Я безнадійно звик до GitHub. З іншого боку, активно експериментую з переходом на протокол Gemini, а з ним - зміною концепції взаємодії з контентом: для текстових сторінок - свій застосунок, для месенджера - інший, для медіа - третій. Тобто намагаюсь відучити себе від Веб-браузеру, в який перекочувало буквально все моє життя.
|
||
|
||
В соціальному плані, тут немає властивих Веб-прошаркам тікетів, пул-реквестів та смайликів: спілкування розробників відбувається в середовищі командного рядка і більше нагадує концепцію ngit (https://gitworkshop.dev/ngit). Технічно, я думаю, що це може бути реалізовано в перспективі, утім зараз тільки Git-like CLI.
|
||
|
||
Тому, суб'єктивно, Radicle - це інструмент в першу чергу для людей, які готові змінювати свідомість та власні звички, чий розум відкритий для нового досвіду і тестування на цьому ясному розумі нових концепцій, у даному випадку - на базі старих технологій. Цей проєкт однозначно вартий уваги через як мінімум свою інтенсивність розробки і я особисто за ним з цікавістю спостерігаю.
|
||
|
||
### Сфери застосування
|
||
|
||
На мою думку, Radicle слід сприймати саме як повноцінний варіант self-hosted сервера Git: як для своїх проєктів, так і для мірорингу проєктів, які вам подобаються. З тією лише відмінністю, що користувачам проєктів які вам сподобались (ресідом) - не потрібно знати ваш домен, щоб скачати потрібний їм код, при тому зробити це безпечно в плані компрометації, засобами криптографічного доказу походження оригіналу.
|
||
|
||
## Посилання
|
||
|
||
=> https://radicle.xyz Офіційний Веб-сайт Radicle
|
||
=> https://radicle.zulipchat.com Офіційний канал Zulip
|
||
=> https://app.radicle.xyz/nodes/iris.radicle.xyz/rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5 Веб-інтерфейс офіційного репозиторію Heartwood
|
||
=> https://devzone.org.ua/post/radicle-detsentralizovanyy-p2p-khostynh-gitdvcs Веб-адаптація цього матеріалу з коментарями на DevZone
|
||
|
||
### Репозиторій цього блогу
|
||
|
||
```
|
||
rad:z4FoMnoSve6Ku6gz4qiuSpzmGr1YE
|
||
```
|
||
|
||
Графічний інтерфейс доступний щонайменше на таких Веб-хабах:
|
||
|
||
=> app.radicle.xyz/nodes/iris.radicle.xyz/rad%3Az4FoMnoSve6Ku6gz4qiuSpzmGr1YE iris.radicle.xyz
|
||
=> app.radicle.xyz/nodes/rosa.radicle.xyz/rad%3Az4FoMnoSve6Ku6gz4qiuSpzmGr1YE rosa.radicle.xyz
|
||
|
||
### Дивіться також
|
||
|
||
=> rust-cross-compilation-with-cross-crate.gmi Простий спосіб крос-компіляції Rust з cross |