Willkommen zu allesnurgecloud.com – Ausgabe #221
da geht er dahin, der Januar – Willkommen im Februar, bald ist schon wieder Weihnachten. Naja, die Zeit vergeht einfach auch schneller, wenn so viel aufregendes passiert.
Microsoft hat übrigens nun auch für Windows 11 bestätigt, dass man den zum Account gehörenden Encryption Key an das FBI rausrücken würde, sofern man danach gefragt werde. Für Unternehmen sicherlich spannend – da müsste es doch auch eine andere Lösung geben? Schon lange kein Windows mehr genutzt – falls du dazu was weisst, schreib mir gerne.
Happy Bootstrapping Podcast
In der aktuellen Podcast Folge 157 spreche ich mit Andreas Krause von Weinwunder. Bei Weinwunder gibt es Weine, die es sonst in Deutschland nicht gibt. Von speziellen Weingütern aus dem Ausland oder auch feines aus Deutschland selbst. Andreas arbeitet eigentlich in der Eventbranche und baut Weinwunder nebenher auf — gar nicht so leicht, in Deutschland wird immer weniger Wein getrunken (Folge bei Spotify/Apple).
Wenn dir die Podcastfolgen zu lang sind, kannst du gerne auch den Newsletter dazu abonnieren – erscheint jeden Montag (in der Regel).
Support the Newsletter
Übrigens kannst Du meine Arbeit nun auf Patreon supporten, mir ein Bier ausgeben oder mal auf meiner Amazon-Wunschliste vorbeischauen – Danke! Falls du Interesse hast, im Newsletter oder Podcast Werbung zu buchen, kannst du das auf passionfroot machen oder mir einfach ne E-Mail als Antwort auf den NL schicken.
allesnurgecloud.com ist ein kuratierter Newsletter mit Inhalten aus der Open-Source, Cloud und IT-Welt.
Für weiteren Content folge mir gerne auf Twitter, Mastodon oder LinkedIn.
Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren:
OpenClaw-Entwickler im Interview: „I ship code I don’t read“
Der Pragmatic Engineer Gergely Orosz hat Peter Steinberger in seinem Podcast interviewt, den Entwickler von OpenClaw (ehemals Moltbot, ehemals Clawdbot) – umbenannt, weil Anthropic sich am Namen störte). Das Projekt ist aktuell das am schnellsten wachsende Repository auf GitHub und wird häufiger gegoogelt als Claude Code oder Codex.
Steinbergers Workflow ist radikal: Er hat im Januar über 6.600 Commits alleine gemacht. „From the commits, it might appear like it’s a company. But it’s not. This is one dude sitting at home having fun.“ Er betreibt 5-10 AI-Agenten parallel, plant Tasks ausführlich mit dem Agenten durch, und lässt sie dann laufen. Pull Requests nennt er „Prompt Requests“ – ihn interessiert der Prompt mehr als der generierte Code. Code Reviews? Tot. Stattdessen diskutiert er mit seinem Team nur noch Architektur.
Einige seiner Prinzipien: Agenten müssen ihre eigene Arbeit verifizieren können (compile, lint, test). Lokale CI schlägt Remote-CI, weil er nicht 10 Minuten warten will. Er promptet manchmal absichtlich vage, um unerwartete Lösungen zu entdecken. „Most code is boring data transformation – focus energy on system design instead.“
Steinberger ist kein Vibe-Coder im negativen Sinn – er ist Software-Architekt, der Struktur, Tech Debt und Erweiterbarkeit im Kopf behält. Der Erfolg von OpenClaw/Moltbot liegt auch an der modularen Architektur.
Auth0 hat allerdings einen Security-Leitfaden für Moltbot veröffentlicht (da hieß es noch Moltbot), der die Kehrseite beleuchtet: Ein AI-Agent mit Zugriff auf Shell, SSH-Keys und Slack-Tokens ist kein Chat-Toy, sondern ein neuer Security Principal. Sandbox-Mode aktivieren, Allow-Lists für Commands und Pfade, keine langlebigen Credentials – die Empfehlungen lesen sich wie für einen Junior-Mitarbeiter mit Root-Zugriff.
Hast du den OpenClow schon am Start und bist dem Trend gefolgt, dafür gleich einen Mac Mini zu bestellen? Oder alles auf dem Hetzner VPS?
The creator of Clawd: „I ship code I don’t read“
Gegenposition eines Entwicklers: „Pure, unadulterated slop“
Mo Bitar hat einen ernüchternden Erfahrungsbericht nach zwei Jahren Vibe Coding veröffentlicht. Seine Entwicklung folgte dem typischen Muster: Erst beeindruckt von kleinen Tasks, dann von großen, dann der Versuch, immer größere Aufgaben zu delegieren. Er schrieb ausführliche Specs in Obsidian, verbrachte 30 Minuten mit einem einzigen Prompt.
Das Problem: Spec-driven Development funktioniert mit Agenten nicht. Design Docs sind in der Realität lebende Dokumente, die sich über Wochen durch Discovery und Implementation entwickeln. Agenten können das nicht – sie treffen Entscheidungen upfront und weichen nicht mehr davon ab. „Agents write units of changes that look good in isolation. But respect for the whole, there is not.“
Als Bitar seine gesamte Codebase von vorne bis hinten durchlas, fand er „pure, unadulterated slop“. Jeder einzelne Pull Request sah gut aus, jede Änderung war in sich konsistent. Aber das Ganze? Ein Chaos ohne strukturelle Integrität. „The AI had simply told me a good story“ – wie ein Roman, bei dem jeder Absatz funktioniert, aber das Kapitel keinen Sinn ergibt.
Sein Fazit: „I’m not shipping this shit. I’m not gonna charge users for this.“ Er schreibt jetzt wieder von Hand – und ist schneller, kreativer und produktiver, „when you price everything in, and not just code tokens per hour.“
Ein neues Paper auf arXiv („Vibe Coding Kills Open Source“) untermauert die Bedenken aus ökonomischer Perspektive: Wenn Nutzer OSS nur noch über AI-Agenten konsumieren, ohne Dokumentation zu lesen, Bugs zu melden oder mit Maintainern zu interagieren, bricht das Geschäftsmodell vieler Open-Source-Projekte zusammen. Das Modell zeigt: Trotz höherer Produktivität sinken Qualität und Verfügbarkeit von OSS – ein klassisches Tragedy-of-the-Commons-Szenario.
After two years of vibecoding, I’m back to writing by hand
Anzeige
Buchtipp: „Team Topologies“
Team Topologies (*) von Matthew Skelton und Manuel Pais ist quasi das fehlende Handbuch zu „Accelerate“ und „Phoenix Project“ – wie schneidet man Teams eigentlich richtig?
Die Kernidee: Es gibt nur vier fundamentale Team-Typen (Stream-aligned, Platform, Enabling, Complicated Subsystem) und drei Interaktionsmuster (Collaboration, X-as-a-Service, Facilitating). Klingt simpel, ist es auch?. Statt endloser Reorg-Diskussionen hat man plötzlich ein gemeinsames Vokabular.
Das Buch nimmt Conway’s Law ernst: Deine Software-Architektur wird so aussehen wie deine Kommunikationsstrukturen. Also design die Teams gleich so, dass die gewünschte Architektur dabei rauskommt – nicht umgekehrt. Dazu kommt Cognitive Load als Design-Faktor: Wenn ein Team zu viel gleichzeitig betreuen muss, wird es langsam – egal wie gut die Leute sind.
Mit 240 Seiten angenehm kompakt und deutlich weniger zäh als manch anderes IT-Revolution-Buch. Seit 2019 Standardwerk, 2025 kam die Second Edition mit neuen Case Studies. Gibt es auch auf Deutsch.
(*) – Ja, das sind Amazon Affiliate-Links.
MinIO ist tot – welche Alternativen für lokales S3 taugen
Robin Moffatt hat die Alternativen zu MinIO für lokale S3-Emulation getestet. Der Anlass: Ende 2025 hat das Unternehmen hinter MinIO das Projekt aufgegeben, um andere kommerzielle Interessen zu verfolgen. Das trifft viele Demos und Build-Pipelines, die MinIO für S3-Kompatibilität nutzten.
Moffatts Anforderungen: Docker-Image, S3-Kompatibilität, Open-Source-Lizenz, einfache Single-Node-Konfiguration, aktive Community oder kommerzieller Backer. Sein Testaufbau: DuckDB schreibt Iceberg-Daten auf S3.
Empfohlen:
- S3Proxy (Apache 2.0, 5M+ Pulls) – leichtgewichtig, sehr einfach zu konfigurieren
- SeaweedFS (Apache 2.0, 5M+ Pulls) – seit 2012 aktiv, eigene UI, solide
Mit Einschränkungen:
- RustFS (Apache 2.0, 100k+ Pulls) – einfache Konfiguration, aber Alpha-Release und kürzlich Security-Vulnerability
- CloudServer/Zenko (Apache 2.0, 5M+ Pulls) – funktioniert, aber Teil einer größeren Suite
Nicht empfohlen für den Use Case:
- Garage (AGPL, 1M+ Pulls) – zu komplexe Konfiguration für einfache Demos
- Apache Ozone (Apache 2.0, 1M+ Pulls) – mindestens 4 Nodes nötig, Hadoop-Vibes
Moffatts Empfehlung: SeaweedFS oder S3Proxy als Drop-in-Replacement. Garage und Ozone sind für den Use Case zu komplex. RustFS sei vielversprechend, aber noch zu jung.
Ein Hinweis zur Governance: Außer Apache Ozone gehören alle Projekte keiner Foundation – theoretisch könnten sie ihre Lizenz jederzeit ändern, genau wie MinIO das schon gemacht hat.
Alternatives to MinIO for single-node local S3
Customer Experience: Die einzige Reliability-Metrik, die zählt
Spiros Economakis erzählt in diesem Artikel eine Geschichte, die jeder On-Call-Engineer kennt: Das Team war auf einem Company Meetup, er hielt alleine die Stellung. Keine Alerts, alles ruhig. Dann, kurz nach Schichtende, explodierten die Dashboards – High CPU, Memory Exhaustion, Database Saturation.
Das Problem: Keine Kundenbeschwerden, keine wütenden Tweets. Erst Stunden später, als die US-Kunden aufwachten, kamen die echten Probleme. Multi-Tenant-Workspaces kämpften, Complaints trudelten ein. Die Resource-Metriken hatten Alarm geschlagen, aber nichts über die tatsächliche User Experience verraten.
Economakis‘ Kernthese: CPU-Utilization und Memory-Consumption sind verlockend einfach zu messen, sagen aber nichts darüber aus, was Nutzer erleben. High CPU kann effiziente Auslastung bedeuten, Memory Saturation smartes Caching. Beides ist nicht automatisch ein Problem – aber wenn Nutzer sich nicht einloggen können, ist es eines.
Die Lösung: Golden Signals aus dem Google SRE Book – Latency, Traffic, Errors, Saturation. Diese Metriken sind keine reinen Tech-Metriken, sondern Business-Metriken. Latenz im Checkout-Flow kostet Umsatz. Errors bei Payment Processing zerstören Vertrauen. Traffic-Spikes bei einem Streaming-Release müssen smooth laufen.
Sein Framework: Alerts aufräumen (beantwortet dieser Alert die Frage „Betrifft das den Kunden?“), SLOs und SLIs auf kritische User Journeys ausrichten, und cross-funktionale Zusammenarbeit zwischen Product, Engineering und Business etablieren.
Die entscheidende Frage bei jedem Alert sollte lauten: „Does this metric reflect customer pain, or is it just noise?“.
Meiner Erfahrung nach ist es super schwer, aber auch super wichtig, die Customer Experience vernünftig zu überwachen.
Customer Experience: The Reliability metric that matters
Unkonventionelle PostgreSQL-Optimierungen
Haki Benita hat einen lesenswerten Artikel über PostgreSQL-Optimierungen veröffentlicht, die über das übliche „slap an index on it“ hinausgehen. Drei Techniken stechen heraus.
Check Constraints für Query-Planung nutzen: Wenn eine Spalte einen Check Constraint hat (z.B. plan IN ('free', 'pro')), kann PostgreSQL Queries für unmögliche Werte eigentlich sofort verwerfen – tut es aber standardmäßig nicht. Ein WHERE plan = 'Pro' (mit falschem Case) führt trotzdem zu einem Full Table Scan. Die Lösung: SET constraint_exclusion TO 'on'. PostgreSQL erkennt dann anhand des Constraints, dass die Bedingung nie wahr sein kann, und überspringt den Scan komplett. Besonders relevant für BI-Umgebungen, wo Analysten Ad-hoc-Queries mit Tippfehlern schreiben.
Function-Based Indexes für niedrigere Kardinalität: Ein B-Tree-Index auf sold_at (Timestamp) für Daily Reports ist Overkill – 214 MB für Millisekunden-Präzision, wenn nur Tage gebraucht werden. Ein Index auf date_trunc('day', sold_at)::date ist nur 66 MB groß, weil weniger distinct Values mehr Deduplizierung ermöglichen. Mit PostgreSQL 18’s Virtual Generated Columns lässt sich das elegant lösen: Eine virtuelle Spalte mit dem exakten Ausdruck garantiert, dass Queries den Index nutzen können, ohne dass Entwickler diszipliniert denselben Ausdruck schreiben müssen.
Hash Index für Unique Constraints auf großen Werten: Ein Unique B-Tree auf einer URL-Spalte (Text) war 154 MB groß. PostgreSQL unterstützt keine Unique Hash Indexes direkt – aber mit einem Exclusion Constraint (EXCLUDE USING HASH (url WITH =)) lässt sich Uniqueness trotzdem per Hash Index erzwingen. Ergebnis: 32 MB statt 154 MB, also 5x kleiner. Einschränkung: Funktioniert nicht mit Foreign Keys und hat Limitationen bei ON CONFLICT DO UPDATE.
Man lernt einfach nie aus – ob die KI das so auch gecheckt hätte?
Unconventional PostgreSQL Optimizations
DNS-Reihenfolge: Cloudflare-Incident durch CNAME-Sortierung
Am 8. Januar 2026 verursachte ein Routine-Update bei Cloudflares 1.1.1.1-Resolver DNS-Auflösungsfehler für Nutzer weltweit. Die Ursache: Eine subtile Änderung in der Reihenfolge von DNS-Records – konkret, ob CNAME-Records vor oder nach A-Records erscheinen.
Im verlinkten Blog-Artikel gibt es eine wie immer sehr transparente Darstellung der Ereignisse.
Was passiert ist: Um Speicher zu sparen, wurde Code geändert, der CNAME-Chains mit aufgelösten A-Records zusammenführt. Vorher: CNAMEs zuerst, dann A-Records. Nachher: A-Records zuerst, CNAMEs angehängt. Eine scheinbar harmlose Optimierung.
Warum das problematisch wurde: Einige DNS-Client-Implementierungen – darunter glibc’s getaddrinfo, das auf Linux weit verbreitet ist – parsen DNS-Antworten sequentiell und erwarten CNAMEs am Anfang. Wenn der CNAME plötzlich unten steht, findet der Parser den A-Record nicht mehr, weil er nicht zum erwarteten Namen passt.
Besonders kurios: Drei Cisco-Switch-Modelle gingen in Reboot-Loops, wenn sie die neu geordneten Antworten erhielten. Warum man jetzt auf Switchen einen 1.1.1.1 Resolver einträgt, verstehe ich nicht – vermutlich zu faul? Oder. kann mir einer erklären, warum man das macht (Link zum Cisco KB Artikel + Fix).
Die 40 Jahre alte Protokoll-Ambiguität: RFC 1034 von 1987 sagt, CNAME-Records erscheinen „possibly preface“ vor anderen Records. Das klingt nach Anforderung, verwendet aber keine normativen Schlüsselwörter wie „MUST“ oder „SHOULD“ (die erst 1997 mit RFC 2119 standardisiert wurden). Cloudflare hat jetzt einen Internet-Draft beim IETF eingereicht, um das Verhalten explizit zu klären.
Ein interessantes Beispiel dafür, wie jahrzehntealte Protokoll-Ambiguitäten in modernen Systemen plötzlich relevant werden. Die Änderung wurde revertiert, Cloudflare plant keine erneute Änderung der Reihenfolge.
What came first: the CNAME or the A record?
HSBC: Tracking-Pixel-Blocking und unzustellbare E-Mails
Der britische Blogger Dan Q erhielt einen Brief von Bank HSBC: Seine E-Mails würden als unzustellbar zurückkommen, er solle seine E-Mail-Adresse aktualisieren. Das Problem: Die E-Mails kamen alle an. Sie lagen gelesen in seinem Posteingang.
Was war passiert? HSBC verwendet Tracking-Pixel in ihren E-Mails – winzige 1×1-Pixel-Bilder, die beim Öffnen der E-Mail geladen werden und der Bank verraten, wann, wie oft und von wo aus jemand eine E-Mail liest. Dan Q blockiert solche Tracker aus Datenschutzgründen. HSBC interpretierte das Ausbleiben des Tracking-Signals offenbar als „E-Mail nicht zugestellt“.
Die Tracking-Pixel verwenden http:// statt https://. Das bedeutet: Wer im selben WLAN sitzt – im Café, im Hotel, zu Hause – kann potenziell mitsehen, dass jemand gerade eine HSBC-E-Mail öffnet. Bei einer Bank. Ein vermeidbarer Sicherheitsfehler.
Der Kundenservice bestand zunächst darauf, dass Dan seine E-Mail-Adresse ändern müsse, wenn die Bank einen solchen Brief schicke. Erst ein Telefonat mit einer anderen Abteilung klärte: Er könne den Brief doch ignorieren.
Der so genannte „Surveillance Capitalism“ ist so allgegenwärtig geworden, dass HSBC offenbar davon ausgeht, Tracking-Pixel seien ein zuverlässiger Indikator für E-Mail-Zustellung. Sind sie nicht. Sie produzieren False Negatives (Privacy-Tools, primitive E-Mail-Clients, Accessibility-Software) und False Positives (Antispam-Software, die Pixel vor dem User lädt).
Dans Vorschlag: Wenn HSBC prüfen will, ob E-Mails ankommen, könnten sie einfach eine E-Mail mit Bestätigungslink schicken. Funktioniert, ist transparent, und respektiert die Privatsphäre.
That’s Not How Email Works, HSBC
Incident-Response: Runbooks, Rechte, Deployment-Marker
Hrishikesh Barua von Uptime Labs hat die typischen Zeitfresser während Incidents zusammengestellt – Dinge, die Teams ausbremsen, wenn jede Minute zählt.
Das Finden der richtigen Person ist in verteilten Teams schwieriger als gedacht. Die Lösung: Cross-Timezone-Coverage pro Microservice, sodass immer jemand mit dem nötigen Wissen erreichbar ist.
Fehlende Runbooks sind ein Klassiker. Best Practice: Alerts direkt mit Runbooks verlinken, idealerweise per Pre-Commit-Hook erzwungen.
Fehlende Zugriffsrechte zum falschen Zeitpunkt – der neue Auth-Provider wurde noch nicht migriert, die IAM-Permissions fehlen. Baruas Empfehlung: Runbooks periodisch testen, idealerweise von neuen Teammitgliedern auf frischen Maschinen. Bei Web-de haben wir das früher in „Bootcamps“ gemacht – 30 Tage, die ein neuer MA in die verschiedenen Produkte eingeführt wurde und „nebenbei“ Dinge wie einen Restore Prozess anhand einer DB getestet hat.
Ohne Korrelation zwischen Deployments und Metriken wird Root-Cause-Analyse mühsam. Deployment-Marker in Grafana helfen, Anomalien mit Code- oder Infrastruktur-Änderungen zu korrelieren.
Fehlende Sichtbarkeit auf Third-Party-Outages: Der Connection Timeout könnte ein Google-Cloud-Incident sein. Statusseiten der Dependencies im Blick behalten. Sentry und andere Tools helfen hier – sämtliche 3rd Party Abhängigkeiten sollten bekannt und deren Uptime/Respone Time irgendwo getracked werden.
Dann zitiert Hrishikesh noch John Allspaw:
“The competitive advantage is not for a leader to say, ‘Why did it take so long to restore this issue or resolve this outage?’ A competitive advantage is, ‘Oh my God, that is amazing. Tell me what made this hard and what are any of the things that made it difficult to resolve? Is there anything I can do to help get out of the way for people to do the work?’“
Jep, da hat er auf jeden Fall recht!
The Biggest Time Sinks During Outages
Rackspace verdreifacht E-Mail-Preise – Kunden empört
Rackspace hat die Preise für E-Mail-Postfächer von 3 auf 10 US-Dollar pro Monat erhöht – eine Verdreifachung zum Jahresstart. Auch die Add-ons wurden teurer: Rackspace E-Mail Plus kostet jetzt 2 statt 1 Dollar, das Archiving-Add-On 6 statt 3 Dollar.
Die Begründung des Unternehmens bleibt vage: „steigende Betriebskosten für Infrastruktur und Hardware“. Das Angebot selbst ist unverändert – 25 GB E-Mail-Speicher, 30 GB Onlinespeicher, 100-Prozent-Verfügbarkeitsgarantie, 24/7-Support. Alles wie vorher, nur dreimal so teuer.
Reseller, die Rackspace an Geschäftskunden weiterverkaufen, können die Erhöhung nicht anders erklären, als dass der Dienstleister einfach mehr Geld haben will. Auf X schreibt ein Kunde: „Frustrierend drückt es nicht einmal annähernd aus.“ Andere erwägen den Umzug zu Konkurrenzprodukten – allerdings bleiben bis zur nächsten Abrechnung nur wenige Wochen.
Ähnlich sieht es bei Google Workspace aus:
Lieber Google Workspace-Administrator,
wir möchten Sie über eine Preisänderung für Ihr Google Workspace Business Standard-Abo informieren, die am oder nach dem 19. Februar 2026 in Kraft tritt. Die aktualisierten Abopreise spiegeln den deutlichen Mehrwert von KI sowie der vielen neuen Funktionen wider, die wir in den Google Workspace-Versionen eingeführt haben und noch einführen werden
Anstatt 11,50€ pro User bezahle ich in Zukunft 13,60€ – das hört sich jetzt nicht viel an, die kurze Frist von 4 Wochen hat aber ein „Geschmäckle“ und in Summe ist es trotzdem eine Erhöhung um 18,3% – das ist schon nicht ohne – Zeit, sich nach Alternativen umzuschauen. Einen Opt-Out für Gemini gibt es an der Stelle nicht, alle bezahlen es mit und so rollt dann halt der Rubel und vermutlich auch der Aktienkurs.
Rackspace macht E-Mail um mehr als 200 Prozent teurer
Schmunzelecke
Dinge, die einen in der US Regierung nicht mehr überraschen: „US cybersecurity chief leaked sensitive government files to ChatGPT„
Hier gibt es eine isometrische Karte von NYC zum reinzoomen – ist recht schnell und irgendwie abgefahren.
💡 Link Tipps aus der Open Source Welt
rostr – CLI-First Server Inventory Management
rostr ist ein leichtgewichtiges Server-Inventory-System mit CLI-First-Ansatz, das YAML-Dateien als Single Source of Truth verwendet. Das in Python geschriebene Tool generiert automatisch SSH-Configs, Ansible-Inventories und weitere Konfigurationen aus zentralen Inventory-Files und eignet sich ideal für Infrastructure Engineers, die ihre Server-Landschaft versionskontrolliert verwalten möchten.
Features:
- YAML-based Inventory – Einfach lesbar, versionskontrollierbar, Git-freundlich
- SSH Config Generation – Automatische
~/.ssh/configEinträge - Ansible Inventory – Dynamische Inventories mit Auto-Grouping (Tag, OS, Notes)
- Fuzzy SSH Matching –
rostr ssh webmatchedweb-prod-01 - OS Auditing – Parallel-SSH zur Erkennung von OS-Mismatches mit
--fixOption - Git Sync – Auto-Commit und Push bei Inventory-Änderungen
- Monitoring Setup – One-Command Uptime Kuma Installation mit Rootless Docker
- Cloud-Init Automation – Auto-Registrierung neuer Server via Webhook on Boot
- Backup & Restore – Timestamped Backups der Inventory-Daten
- Dry-Run Mode – Preview Changes vor Ausführung
rostr punktet durch radikale Simplizität und Unix-Philosophy: YAML als Single Source of Truth, keine Datenbank, vollständig versionskontrollierbar. Die Kombination aus SSH-Config-Generation, Ansible-Integration und Fuzzy-Matching macht das tägliche Server-Management deutlich effizienter.
https://github.com/wnstify/rostr
Radicle – Sovereign Peer-to-Peer Code Forge
Radicle ist eine dezentrale, Open-Source Code-Collaboration-Plattform, die auf Git basiert und ohne zentrale Kontrollinstanz auskommt. Im Gegensatz zu GitHub oder GitLab werden Repositories peer-to-peer über ein Netzwerk repliziert, wobei User volle Kontrolle über ihre Daten und Workflows behalten. Alle Social Artifacts (Issues, Patches, Diskussionen) werden als Git-Objekte gespeichert und kryptografisch signiert.
Features:
- Peer-to-Peer Architecture – Keine zentrale Plattform, Repositories werden über Peers repliziert
- Cryptographic Identities – Public-Key-Kryptographie für Authentifizierung und Authorship
- Local-First – Volle Funktionalität auch offline, Daten gehören dem User
- Collaborative Objects (COBs) – Issues, Patches und Discussions als Git-Objekte
- Git-native – Nutzt Git für effizienten Datentransfer zwischen Peers
- Custom Gossip Protocol – Austausch von Repository-Metadaten
- Censorship-Resistant – User können eigene Nodes betreiben
- Modular Stack – CLI, Web Interface, TUI backed by Radicle Node und HTTP Daemon
- Evolvable & Extensible – Developer können eigene Collaboration-Flows bauen
- Radicle Desktop – Grafischer Client für komfortablere Nutzung
Radicle ist der konsequenteste Ansatz für dezentrale Code-Collaboration – radikal anders als federated Alternativen wie Forgejo. Die Kombination aus Git-native Storage, kryptografischen Identitäten und Peer-to-Peer-Replikation schafft echte Daten-Souveränität. Interessant für Teams, die absolute Unabhängigkeit von zentralen Plattformen suchen.
❓ Feedback & Newsletter Abo
Vielen Dank, dass du es bis hierhin geschafft hast!
Kommentiere gerne oder schicke mir Inhalte, die du passend findest.
Falls dir die Inhalte gefallen haben, kannst du mir gerne auf Twitter folgen.
Gerne kannst du mir ein Bier ausgeben oder mal auf meiner Wunschliste vorbeischauen – Danke!
Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren: