Git von Sourcehut zu Radicle verlagern

Lange Zeit war mein öffentliches Git-Zuhause Sourcehut — git.sr.ht/~ff0x, Builds auf builds.sr.ht, Mailinglisten wenn nötig. Sourcehut mag ich weiter: ein Forge als Dienst, den man nutzt, keine Plattform, die den Social Graph besitzt.

Trotzdem wandern Repositories schrittweise zu Radicle . Nicht weil Sourcehut gescheitert wäre, sondern weil distributed git endlich einen Stack hat, der sich wie ein echtes Forge anfühlt — nicht nur git push auf den Server eines Freundes und ein Issue-Tracker irgendwo anders.

Zentrales Forge vs. distributed git

Git ist von Haus aus distributed: jeder Clone ist eine vollständige Kopie. Praktisch nutzt fast jeder das Client–Server-Modell — GitHub , GitLab , Sourcehut, Codeberg. Man vertraut einem Hostnamen; git clone von dort ist Source of Truth.

Radicle behält Git als Storage und ergänzt, was plain Git im offenen Internet nicht bietet:

Der Workflow bleibt vertraut (rad clone, git push, Review, Merge), aber Autorität ist kryptografisch und lokal — nicht „was auch immer origin sagt“.

Warum nicht bei Sourcehut bleiben?

Sourcehut passt weiterhin, wenn builds.sr.ht, Inbound-Mail oder eine einzige HTTPS-URL für alle wichtig sind.

Ich migriere, weil:

1. Souveränität — eigener Baum, eigener Node, eigene Seeding-Policy. Kein Account auf fremdem PostgreSQL.
2. Offline-freundliche Metadaten — Issues und Patches reisen mit der Git-Object-Database; Arbeit ohne laufende Forge-UI.
3. Passung zum Lab — Infrastruktur selbst betreiben (Kubernetes GitOps, IRC, …). Ein Radicle seed neben anderen stateful Apps unter k8s/clusters/hydra/applications/radicle/seed-node/ passt ins gleiche Muster.
4. Das Netzwerk ist real — Anfang 2026 dokumentiert radicle.dev tausende Repositories und hunderte Nodes wöchentlich auf public seeds.

Radicle ist kein Blockchain-Projekt, kein GitHub-Skin und keine magische Discovery (Search entwickelt sich — FAQ ). Local-first-Software mit Social Layer ohne Firma in der Mitte.

Domains: radicle.dev und radicle.network

Im April 2026 zog das Projekt die Dokumentation nach radicle.dev , nachdem radicle.xyz ISP-Blocks traf; Explorer-Content liegt auf radicle.network. Beim Bookmarken oder Verlinken prüfen, welches Front-end der Node nutzt — das Protokoll ist gleich; Namen trennen Content und Explorer.

Lab-Repo und eigener Seed

Das Kubernetes-Lab lebt in einem Monorepo — öffentlich auf Radicle:

Flux auf hydra zieht das Lab bereits per HTTPS vom eigenen Seed — k8s/clusters/hydra/flux/cluster.yaml zeigt auf https://seed.this-is-fine.io/z6MQ7ck2rSh7h4qEgbRYg3ftnrGv.git. Kyverno erlaubt neben GitHub und git.sr.ht auch https://seed.this-is-fine.io/* (k8s/clusters/common/applications/kube-system/kyverno/policies/verify-git-repositories.yaml). In common-config steht GIT_REPO_URL noch als ssh://[email protected]/~ff0x/lab — Legacy-Variable für Templates und SSH-Workflows; der laufende Cluster-Remote ist der Seed.

Radicle ist die Forge für Patches, Issues und menschliche Review; ZeroClaw nutzt dieselbe Identität (RADICLE_GIT_URL in k8s/clusters/hydra/applications/zeroclaw/zeroclaw/app/radicle.env). Das Image oci.this-is-fine.io/radicle/node läuft als Deployment seed-node mit PVC unter /node/radicle.

Migration von Sourcehut (läuft)

Inkrementell, kein Big-Bang.

Pro Repo:
  rad auth (Identity)
  -> rad init / push bestehende History
  -> RID rad:z… veröffentlichen (README, Whoami, Issues)
  -> eigener Seed oder public seeds
  -> Sourcehut-Remote spiegeln oder entfernen
  -> builds.sr.ht nur solange CI dort bleibt

Typische Schritte pro Repository:

1. Tooling installieren ( radicle.dev/install oder Distro-Pakete) und Radicle-Identity anlegen (rad auth).
2. Projekt im Netz initialisieren (rad init / bestehende History pushen).
3. RID veröffentlichen überall, wo früher git.sr.ht/~ff0x/... stand.
4. Node betreiben (oder public seeds nutzen); Repos pinnen oder seeden.
5. Sourcehut-Remote ausmisten oder spiegeln, wenn Traffic und CI umgezogen sind.

Repos mit builds.sr.ht bleiben auf Sourcehut (oder CI woanders), bis das Radicle-Workflow-Äquivalent steht — Radicles Stärke ist git + Collaboration, nicht hosted CI. Container-Images und Lab-Glue liegen im gleichen Tree wie die Apps (images/, .build.yml).

Was distributed git praktisch bedeutet

• Verification — RID prüfen, nicht DNS. Maintainer-Sets im Identity-Dokument.
• Replication — Freunde und Seeds cachen das Repo; Host-Ausfall ist Availability, kein sofortiges Löschen.
• Patches — Reviews an Revisionshistorie, ohne proprietäres „PR“-Objekt auf einem Server (git push rad HEAD:refs/patches/…).
• Policy — der eigene Seed kann repliziertes Material allow oder block (RAD_SEEDING_POLICY, pinned repos).

Trade-offs: man betreibt einen Node (Bandbreite, Updates, Patches). Multi-Device-Identity reift noch. Windows ist noch kein First-Class-Ziel. Für mich soll das Forge nicht Single Point of Failure für Open Source sein.

Wo ich erreichbar bin

Während der Transition bleiben einige Projekte auf Sourcehut; Neues und Umgezogenes erscheint auf Radicle unter meiner Identity. Die Whoami-Seite bekommt einen Radicle-Link, sobald Repos stehen. Wer von git.sr.ht klont: Radicle-Remote ergänzen, wenn ein Maintainer eine RID bekannt gibt.

Radicle ausprobieren: getting started guide , rad node starten, Toy-Repo pushen, im Explorer öffnen. Distributed git klickt, wenn man von etwas pullt, das nicht der eigene Server ist — und man trotzdem weiß, was man geklont hat.