Została zaprezentowana wersja 1.5 platformy P2P Radicle, której celem jest stworzenie zdecentralizowanej usługi współpracy w zakresie rozwoju i przechowywania kodu, podobnej do GitHub i GitLab, ale niezwiązanej z konkretnymi serwerami, niepoddającej się cenzurze i działającej za pomocą zasobów uczestników sieci P2P. Platforma wspiera typowe elementy społecznej interakcji programistów, takie jak zadania, poprawki i recenzje kodu. Opracowania projektu napisane są w języku Rust i są rozpowszechniane na licencjach Apache 2.0 i MIT. Kompilacje przygotowano dla systemów Linux i macOS. Dodatkowo rozwijane są klient desktopowy, interfejs webowy oraz interfejs konsolowy.
Radicle pozwala na niezależność w rozwijaniu i dystrybucji kodu od scentralizowanych platform i korporacji, których powiązania wprowadzają dodatkowe ryzyka (pojedynczy punkt awarii, firma może zniknąć lub zmienić warunki współpracy). Do zarządzania kodem w Radicle wykorzystywany jest znany Git, rozszerzony o mechanizmy określania repozytoriów w sieci P2P. Wszystkie dane są przede wszystkim przechowywane lokalnie (koncepcja local-first) i zawsze dostępne na komputerze dewelopera, niezależnie od stanu połączenia sieciowego.
Uczestnicy udostępniają dostęp do swojego kodu oraz powiązanych z kodem artefaktów, takich jak poprawki oraz dyskusje dotyczące błędów (issues), które są przechowywane lokalnie i replikowane na węzły innych zainteresowanych deweloperów podłączonych do wspólnej zdecentralizowanej sieci P2P. W efekcie tworzy się globalne, zdecentralizowane repozytorium Git, którego dane są replikowane i duplikowane na różnych systemach uczestników.
Do określania sąsiednich węzłów w sieci P2P stosowany jest protokół Gossip, a do replikacji danych między węzłami protokół Heartwood, oparty na Git. Ponieważ protokół jest oparty na Git, platformę łatwo zintegrować z istniejącymi narzędziami do rozwoju wykorzystującymi Git. Do identyfikacji węzłów oraz weryfikacji repozytoriów stosuje się kryptografię opartą na kluczach publicznych, bez użycia kont. Uwierzytelnianie i autoryzacja odbywają się na podstawie kluczy publicznych bez scentralizowanego systemu uwierzytelniania. serwerów.
Każde repozytorium w sieci P2P ma swój unikalny identyfikator i jest samoświadome (self-certifying), co oznacza, że wszystkie działania w repozytorium, takie jak dodawanie commitów i pozostawianie komentarzy do problemów, są poświadczane przez właściciela podpisem cyfrowym, co pozwala na upewnienie się o poprawności danych na innych węzłach bez użycia scentralizowanych centrów certyfikacji. Aby uzyskać dostęp do repozytorium, wystarczy, że w trybie online będzie przynajmniej jeden węzeł, na którym znajduje się jego zreplikowana kopia.
Węzły w sieci P2P mogą subskrybować określone repozytoria i otrzymywać aktualizacje. Możliwe jest tworzenie prywatnych repozytoriów, które są dostępne tylko dla określonych węzłów. Do zarządzania i posiadania repozytorium stosuje się koncepcję „delegatów” (delegates). Delegatem może być zarówno pojedynczy użytkownik, jak i bot lub grupa przypięta do specjalnego identyfikatora. Delegaci mogą przyjmować poprawki do repozytorium, zamykać problemy i ustalać prawa dostępu do repozytorium. Do każdego repozytorium może być przypisanych kilku delegatów.
Repozytoria Radicle są przechowywane na systemach użytkowników jako standardowe repozytoria git, które zawierają dodatkowe przestrzenie nazw do przechowywania danych węzłów i forków, z którymi prowadzone są bieżące prace. Dyskusje, proponowane poprawki i komponenty do organizacji recenzji również są przechowywane w repozytorium git w postaci wspólnych obiektów (COB — Collaborative Objects) i replikowane między węzłami.
W nowym wydaniu:
- Udoskonalono wsparcie dla bare repozytoriów, które nie zawierają katalogu roboczego z kopiami plików projektu, a przechowują jedynie historię zmian i metadane, takie jak gałęzie i tagi. Do polecenia „rad clone” dodano opcję „—bare”, która umożliwia klonowanie repozytorium w trybie bez katalogu roboczego. W narzędziu „git-remote-rad” poprawiono działanie z bare repozytoriami przy użyciu poleceń „git push” i „git fetch” przy komunikacji z zewnętrznym serwerem rad.
- Dodano ustawienie „patch.branch”, które można używać w narzędziu git-remote-rad („git-remote-rad -o patch.branch[=<name>]”) przy dodawaniu poprawki w celu automatycznego tworzenia gałęzi w repozytorium upstream, bez konieczności używania polecenia „rad patch checkout”.
- Poprawiono wyświetlanie polecenia „rad patch show”, które teraz pokazuje pierwotną wersję poprawki, wyświetlaną wcześniej tylko przy użyciu flagi „—verbose”. Wszystkie rewizje są teraz prezentowane w jednej chronologii, bez rozdzielania na zmiany od oryginalnego autora i innych uczestników.
- Dodano możliwość wyświetlania logów w ustrukturalizowanej formie, aktywowanej przez opcje „—log-logger structured” oraz „—log-format json”.
Źródło: opennet.ru
