Darknight Coffee Netzwerk

Carrabelloy ' Meine Hobbys sind so vielseitig

Politik & Persönliches

Open Source & KI

Kategorie: Open-Source

Ihre ultimative Quelle für Politik, Open-Source, Digitalisierung und mehr! 🌟
Informationselite wie oben beschrieben.

Sie fragen sich, wie Sie Ihre Daten sicher halten können? Interessiert an den neuesten Entwicklungen in der Open-Source-Welt? Oder möchten Sie einfach nur auf dem Laufenden bleiben, was in der Politik passiert? Dann sind Sie hier genau richtig!
Warum Sie uns folgen sollten:

Vielfältige Themen: Von der Politik bis zur Datensicherheit – wir haben für jeden etwas dabei.

Expertenmeinungen: Unsere Artikel, Tutorials und Podcasts werden von Fachleuten in den jeweiligen Bereichen verfasst.

Interaktive Community: Nehmen Sie an unseren lebhaften Diskussionen teil und teilen Sie Ihre Meinung mit der Welt.

Exklusive Inhalte: Melden Sie sich für unseren Newsletter an und erhalten Sie exklusive Einblicke und Updates direkt in Ihr Postfach.

👇👇👇

Jetzt Newsletter abonnieren!
Schnellzugriff zu unseren Themenbereichen:

🌐 Politik
💻 Open-Source
📱 Digitalisierung
🔒 Datensicherheit
🐧 Linux & Handy
🎨 Hobbys & Lifestyle

Bleiben Sie vernetzt!

Folgen Sie uns auf unseren verschiedenen Netzwerk-Portalen und werden Sie Teil unserer wachsenden Community.

Mehr erfahren

  • Agent, Skill oder Workflow? Wer den Unterschied nicht kennt, installiert schnell die nächste Sicherheitslücke

    Überall tauchen neue KI-Agenten, Skills, MCP-Server, Erweiterungen und „Autopiloten“ auf. Fast jedes Projekt verspricht mehr Reichweite, mehr Gedächtnis, mehr Selbstständigkeit und weniger Arbeit. Die Installation soll am besten mit einem einzigen Befehl erledigt sein. Danach könne der Agent recherchieren, planen, schreiben, programmieren, Kontakte pflegen und sich angeblich sogar selbst verbessern.

    Das klingt bequem. Es ist aber genau der Moment, in dem aus einer nützlichen Erweiterung eine neue Angriffsfläche werden kann.

    Viele Nutzer unterscheiden nicht zwischen einem Agenten, einem Skill und einem Workflow. Deshalb installieren sie eine ganze Plattform, obwohl sie nur eine einzige Fähigkeit benötigen. Zusammen mit dieser Fähigkeit landen dann womöglich Shell-Zugriff, Cookies, Tokens, Hintergrunddienste, Telemetrie, externe Modellanbieter und fremde MCP-Server auf dem System.

    Unsere Gegenposition ist einfach: Ein Agent wird nicht klüger, nur weil man ihm mehr Schlüssel gibt.

    Der Agent ist die Rolle

    Ein Agent beschreibt, wer handelt, welche Verantwortung er trägt und wo seine Grenzen liegen.

    Ein E-Mail-Sekretär braucht andere Regeln als ein Programmieragent. Ein Redaktionsassistent muss Quellen prüfen, Tatsachen von Meinungen trennen und vor einer Veröffentlichung eine Freigabe einholen. Ein Serverassistent darf Diagnosen durchführen, aber nicht ohne Sicherung und Bestätigung mehrere Konfigurationen gleichzeitig verändern.

    Die Rolle beantwortet Fragen wie:

    • Wofür ist der Agent zuständig?
    • Welche Entscheidungen darf er selbst treffen?
    • Wann muss er den Menschen fragen?
    • Auf welche Daten darf er zugreifen?
    • Welche Handlungen sind grundsätzlich ausgeschlossen?

    Ohne diese Grenzen ist „Autonomie“ nur ein freundliches Wort für unkontrollierte Berechtigungen.

    Der Skill ist eine begrenzte Fähigkeit

    Ein Skill beschreibt, wie eine konkrete Aufgabe zuverlässig erledigt wird. Das kann eine E-Mail-Triage, eine Sicherheitsprüfung, eine Podcastproduktion oder eine strukturierte Recherche sein.

    Ein guter Skill ist klein genug, um verstanden und geprüft zu werden. Er legt nicht nur fest, was funktionieren soll, sondern auch, was nicht passieren darf. Eine Mail-Fähigkeit darf zum Beispiel Nachrichten lesen und Entwürfe anlegen, ohne automatisch zu antworten. Eine Recherchefähigkeit darf öffentliche Quellen auswerten, ohne Browser-Cookies oder private Kontositzungen einzusammeln.

    Genau hier liegt ein verbreiteter Denkfehler: Wer eine neue Fähigkeit braucht, installiert häufig ein komplettes Agentensystem. Das ist so, als würde man für einen neuen Schraubendreher gleich eine fremde Werkstatt übernehmen – mitsamt Generalschlüssel und unbekanntem Personal.

    Der Workflow ist der kontrollierte Prozess

    Ein Workflow verbindet Rolle, Fähigkeiten, Wissen, Freigaben und Prüfungen zu einem nachvollziehbaren Ablauf.

    Bei Darknight-Coffee bedeutet das zum Beispiel:

    1. Eine Quelle oder Aufgabe kommt in den Eingang.
    2. Inhalt und Herkunft werden geprüft.
    3. Die aktive Arbeit liegt eindeutig unter „In Arbeit“.
    4. Tatsachen, Hinweise und offene Fragen werden getrennt.
    5. Vor externen Nachrichten oder Veröffentlichungen erfolgt eine ausdrückliche Freigabe.
    6. Das Ergebnis wird öffentlich oder technisch überprüft.
    7. Erst danach wandert es in „Veröffentlicht“ oder ins Archiv.

    Der Workflow verhindert, dass ein Agent eine gute Idee mit einem ungeprüften Schnellschuss verwechselt. Er ist nicht das Gegenteil von Selbstständigkeit. Er ist die Voraussetzung dafür, dass Selbstständigkeit belastbar bleibt.

    Open Source ist eine Einladung zur Prüfung – kein Freifahrtschein

    Open Source ist für digitale Souveränität unverzichtbar. Der Quellcode kann untersucht, verändert und selbst betrieben werden. Doch eine freie Lizenz beweist weder Sicherheit noch Qualität.

    Auch ein offenes Projekt kann veraltete Abhängigkeiten, unsaubere Installationsskripte, ungewollte Telemetrie oder gefährliche Standardrechte enthalten. Es kann Cookies verlangen, Daten an externe Dienste senden oder im Hintergrund Prozesse starten. Und selbst wenn der Quellcode sauber ist, können die empfohlenen Zusatzdienste das eigentliche Datenschutzproblem verursachen.

    Die richtige Frage lautet deshalb nicht: „Ist es Open Source?“

    Die richtige Frage lautet: „Welchen belegten Nutzen bringt es, welche Rechte verlangt es und wohin fließen unsere Daten?“

    Der Angriff kann bereits im gelesenen Inhalt stecken

    Nicht jede Gefahr muss installiert werden. Ein Agent kann auch über Inhalte angegriffen werden, die er lediglich lesen soll: eine manipulierte Webseite, ein GitHub-Issue, eine README, ein PDF oder eine fremde Skill-Datei. Darin können Anweisungen versteckt sein, die den Agenten dazu bringen sollen, seine eigentliche Aufgabe zu verlassen, Daten preiszugeben oder ungeprüfte Befehle auszuführen. Dieses Verfahren wird als Prompt Injection bezeichnet.

    Deshalb sind externe Inhalte grundsätzlich Daten – keine vertrauenswürdigen Arbeitsanweisungen. Eine Webseite darf uns informieren, aber sie darf nicht unsere Sicherheitsregeln umschreiben. Ein GitHub-Text darf Installationsschritte beschreiben, aber er erhält dadurch keine Ausführungserlaubnis. Und ein Anhang bleibt potenziell riskant, auch wenn sein Dateiname harmlos klingt.

    Die Stahltür beginnt also nicht erst beim Installationsbefehl. Sie beginnt bei der Frage, wem wir überhaupt erlauben, Anweisungen zu geben.

    Härtung ist keine Dauerpanik

    Zu einer verantwortlichen Sicherheitskultur gehört auch der Gegenpunkt: Nicht jede denkbare Gefahr wird tatsächlich eintreten. Ein kurzer Social-Media-Clip behauptet sogar, ein Experiment beweise, dass „99 Prozent unserer Sorgen niemals eintreffen“. Zu sehen sind viele herabfallende Bälle, von denen nur wenige ein Gefäß treffen. Das ist ein einprägsames Bild – aber kein wissenschaftlicher Beweis. Der Clip nennt weder Studie noch Stichprobe, Methode oder überprüfbare Quelle.

    Gerade darin steckt eine doppelte Lehre. Wir dürfen ein spektakuläres Bild nicht mit belastbaren Daten verwechseln. Gleichzeitig müssen wir auch nicht vor jedem Ball davonlaufen. Gute Härtung unterscheidet zwischen bloß denkbaren Möglichkeiten und realistischen Risiken. Sie schützt die wichtigen Ziele, begrenzt Schäden und schafft einen Rückweg, ohne Menschen in permanente Angst zu versetzen.

    Unsere Stahltür ist deshalb kein Ausdruck von Panik. Sie ist eine nüchterne Entscheidung: Kritische Daten und Schlüssel werden stark geschützt; harmlose Experimente dürfen in einer isolierten Umgebung stattfinden. Sicherheit soll Ruhe schaffen – nicht neue Unruhe.

    Fallstudie RuFlo: große Versprechen, konkreter Fehler

    Wir haben RuFlo isoliert geprüft, statt die angebotene Ein-Zeilen-Installation auf das laufende System loszulassen. Das Projekt verspricht Agentenschwärme, Gedächtnis, MCP, lokale Modelle, Autopilot, Daemons und eine große Pluginlandschaft.

    Unser isolierter Test deaktivierte bewusst Installationsskripte, damit keine ungeprüften Lifecycle-Aktionen ausgeführt werden konnten. Unter genau diesen restriktiven Bedingungen fehlte die native SQLite-Bindung. Der lokale Memory-Baustein warnte deshalb selbst, dass die dauerhafte Speicherung möglicherweise nicht gewährleistet sei; die unmittelbar folgende Suche fand den eben gespeicherten Testeintrag nicht. Zusätzlich entstanden mehrere Konfigurations- und Datenbankdateien außerhalb des ausdrücklich gesetzten Testpfads.

    Das beweist nicht, dass RuFlo grundsätzlich kein funktionierendes Gedächtnis besitzt. Es beweist aber, dass der Baustein unter unseren sicheren Installationsbedingungen nicht zuverlässig genug funktionierte. Damit war die Entscheidung klar: kein Autopilot, kein Daemon und keine Integration in Crow. Ein Gedächtnis, das in unserem Prüfweg nicht zuverlässig erinnert, ist für unser System kein Fortschritt.

    Fallstudie Agent-Reach: sicherer Prüfmodus, aber Cookie-Falle

    Agent-Reach verfolgt einen nachvollziehbaren Ansatz: Ein Agent soll Webseiten, RSS, GitHub, YouTube und soziale Netzwerke erreichen können. Der sichere Prüfmodus hielt in unserem Test tatsächlich seine Schreibgrenzen ein. RSS funktionierte ebenfalls.

    Der entscheidende YouTube-Test scheiterte jedoch an der Bot-Prüfung des Plattformbetreibers. Der Zugriff verlangte eine Anmeldung beziehungsweise Cookies. Genau dort endet für uns der Nutzen. Browser-Cookies sind keine harmlosen Textschnipsel, sondern häufig vollständige Sitzungsschlüssel. Wer sie einem Tool übergibt, übergibt im schlimmsten Fall sein Konto.

    Öffentliche Webseiten und GitHub konnten wir bereits mit vorhandenen Werkzeugen prüfen. Für einen kleinen Zusatznutzen eine neue Cookie- und Toolkette einzuführen, wäre schlechte Sicherheitspolitik gewesen. Also wurde auch diese Testinstallation wieder entfernt.

    Fallstudie Comp AI CRM: die Ideen behalten, den Unterbau weglassen

    Das offene Comp AI CRM enthält starke Grundsätze. Personenbezogene Angaben sollen nicht geraten werden. Beobachtungen erhalten einen Belegstatus. Wiedervorlagen brauchen einen konkreten Grund. Unsichere Zuordnungen werden einem Menschen vorgelegt.

    Der technische Unterbau wäre für unseren Bedarf jedoch überdimensioniert: Docker, PostgreSQL, dauerhafte Agentenprozesse sowie eine starke Ausrichtung auf Google, Microsoft, Vercel und weitere externe Dienste.

    Deshalb haben wir nicht das komplette CRM installiert. Wir haben die guten Regeln in unsere bestehende Sekretärsrolle übernommen:

    • personenbezogene Angaben niemals erraten;
    • Quellen als belegt, Hinweis oder offen kennzeichnen;
    • Korrekturen nachvollziehbar dokumentieren;
    • Wiedervorlagen begründen;
    • bei Fälligkeit den Sachstand erneut prüfen;
    • keine externe Nachricht allein wegen eines Termins automatisch versenden.

    Das ist digitale Souveränität in der Praxis: die brauchbare Idee übernehmen, ohne sich den unnötigen Unterbau ans Bein zu binden.

    Unser Härtungsweg: erst prüfen, dann entscheiden

    Bevor eine neue Erweiterung dauerhaft auf ein Agentensystem kommt, sollte sie mindestens diese Prüfung bestehen:

    1. Bedarf benennen: Welche konkrete Fähigkeit fehlt wirklich?
    2. Quelle prüfen: Wer entwickelt das Projekt, wie aktiv ist es und welche Lizenz gilt?
    3. Rechte prüfen: Braucht es Shell, Root, Cookies, Tokens, Browserprofile oder Zugriff auf private Daten?
    4. Datenwege prüfen: Welche externen Dienste, Modellanbieter oder Telemetrie-Endpunkte werden verwendet?
    5. Isoliert testen: Niemals zuerst auf dem laufenden Produktivsystem.
    6. Fehlerfall provozieren: Speichert das Gedächtnis wirklich? Bleiben Schreibgrenzen erhalten? Was passiert ohne Netzwerk oder Schlüssel?
    7. Rückweg vorbereiten: Vorher Backup und Wiederherstellung prüfen; Version und Herkunft festhalten.
    8. Minimal übernehmen: Nur die tatsächlich benötigte Fähigkeit aktivieren.
    9. Geheimnisse widerrufen können: Tokens, Cookies und Schlüssel müssen gezielt entzogen und ersetzt werden können.
    10. Verifizieren und dokumentieren: Was wurde geändert, wie wird es vollständig entfernt und woran erkennt man einen Fehler?

    Wenn ein Projekt diese Fragen nicht sauber beantwortet, kommt es nicht auf das System. Nicht heute, nicht aus Neugier und schon gar nicht wegen eines begeisterten Beitrags auf X, Instagram, Facebook oder YouTube.

    Langsam ernährt sich das Eichhörnchen

    Im KI-Markt gilt derzeit häufig das Gegenteil: möglichst viele Agenten, möglichst viele Tools, möglichst viele automatische Entscheidungen. Doch viele Köche verderben den Brei – besonders dann, wenn jeder Koch eigene Schlüssel, Datenleitungen und Hintergrundprozesse mitbringt.

    Wir gehen bewusst langsamer. Wir prüfen, lernen, dokumentieren und härten. Was uns nachweislich weiterbringt, darf bleiben. Was nur beeindruckend klingt, fliegt wieder raus.

    Unser Ziel ist kein digitaler Gemischtwarenladen. Unser Ziel ist ein verlässlicher Assistent mit klarer Rolle, begrenzten Fähigkeiten und sicheren Workflows. Ein System, das lange nutzbar bleibt, weil es nicht jedem Trend seine Türen öffnet.

    Dabei ist es gleichgültig, woher der Druck kommt: aus der Politik, von einem Konzern, aus einem sozialen Netzwerk oder von Entwicklern, die sich ohne erkennbare Grenzen die nächste „Monster-KI“ zusammenbauen. Herkunft und Selbstbeschreibung ersetzen keine Prüfung. Niemand erhält Zutritt, nur weil er Sicherheit verspricht, „Open Source“ auf die Verpackung schreibt oder gerade besonders laut Reichweite erzeugt.

    Im Zweifel kommt die sprichwörtliche Stahlplatte vor die Tür. Nicht aus Technikfeindlichkeit, sondern weil ein verweigerter Zugang leichter zu korrigieren ist als ein abgeflossenes Postfach, ein gestohlener Sitzungsschlüssel oder ein kompromittierter Server. Wir bauen lieber langsam an unserem eigenen Fort Knox, als fremden Automatismen vorschnell den Generalschlüssel zu geben.

    Alles muss für unseren konkreten Zweck sicher, kontrollierbar und wieder entfernbar sein. Alles andere ist kalter Kaffee. Und kalter Kaffee kommt bei Darknight-Coffee nicht in die Kanne.

    Oder mit einem alten Handwerkersatz: Schuster, bleib bei deinem Leisten. Ein Agent bleibt bei seiner klaren Rolle. Eine neue Fähigkeit kommt erst dazu, wenn Bedarf, Sicherheit und Rückweg geklärt sind.

    Der Satz zum Mitnehmen lautet:

    Installiere keine Plattform, wenn du nur eine Fähigkeit brauchst.

    Diskussion: https://treff.darknight-coffee.eu

    Blog: https://carrabelloy.darknight-coffee.org/blog/

    Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

    Quellen und Transparenz

    Die beschriebenen technischen Befunde stammen aus isolierten Prüfungen vom 26.08.2026. Sie sind Momentaufnahmen der damals getesteten Versionen und keine Behauptung, dass spätere Ausgaben dieselben Eigenschaften besitzen. Interne Adressen, Zugangsdaten und sensible Betriebsdetails wurden bewusst nicht übernommen.

    Der erwähnte Social-Media-Clip wurde nur als redaktionelles Anschauungsmaterial geprüft. Da er keine überprüfbare Quelle für die eingeblendete 99-Prozent-Behauptung nennt, wird diese Zahl nicht als Tatsache übernommen; das Video selbst wird nicht veröffentlicht oder eingebettet.

  • Erst blockieren, dann um Freischaltung bitten: Wie T-Online legitime Mailserver aussperrt

    Eine wichtige E-Mail verlässt den eigenen Server – und kommt beim Empfänger nicht an. Nicht weil die Adresse falsch wäre. Nicht weil SPF, DKIM oder DMARC scheitern. Nicht weil der Inhalt als Spam erkannt wurde. Der empfangende Telekom-Server verweigert bereits das Gespräch:

    554 IP=203.0.113.42 - None/bad reputation. Ask your postmaster for help or to contact tobr@rx.t-online.de for reset. (NOWL)

    Die IP-Adresse in der öffentlich wiedergegebenen Fehlermeldung wurde durch eine reservierte Dokumentationsadresse ersetzt.

    Damit ist die Nachricht aussortiert, bevor T-Online Absender, Signatur und Inhalt überhaupt regulär prüfen kann. Betroffen war in unserem Fall eine sachliche Kontaktaufnahme an einen T-Online-Empfänger. Eine zweite legitime Nachricht blieb aus demselben Grund in der Warteschlange. Beide Nachrichten gingen nicht verloren; unser Postfix hält sie zurück und versucht die Zustellung später erneut. Aber sie kamen nicht rechtzeitig an.

    Das ist kein kleines Komfortproblem. E-Mail ist weiterhin Infrastruktur für Behördenkontakte, politische Kommunikation, Fristsachen, medizinische Hinweise und persönliche Notfälle. Wer ganze Server-IP-Adressen pauschal an der Tür abweist, übernimmt deshalb Verantwortung für reale Kommunikationsabbrüche.

    Was technisch passiert ist

    Unser selbstbetriebener YunoHost-Mailserver sendet unter srv.darknight-coffee.org. T-Online blockierte die öffentliche IPv4-Adresse 203.0.113.42 unmittelbar beim SMTP-Verbindungsaufbau. Die hier genannte Adresse ist eine reservierte Dokumentationsadresse; die echte Server-IP veröffentlichen wir nicht. Ein direkter Test gegen den Telekom-Mailserver reproduzierte exakt dieselbe Ablehnung. Der Mailinhalt spielte dabei keine Rolle, weil die Gegenstelle die SMTP-Sitzung gar nicht erst annahm.

    Die Postfix-Warteschlange zeigte zwei zurückgehaltene Nachrichten mit derselben Ursache. Das ist wichtig: Eine Warteschlange ist der Rückweg eines ordentlich betriebenen Mailservers. Sie verhindert den sofortigen Verlust und erlaubt spätere Zustellversuche. Sie löst aber nicht das Grundproblem. Solange T-Online die IP ablehnt, läuft jeder automatische Versuch gegen dieselbe Wand.

    Unsere eigene Konfiguration war zunächst nicht fehlerfrei

    Wer Kritik übt, muss die eigene Seite offenlegen. Nach einem Serverwechsel waren mehrere öffentliche DNS-Einträge noch nicht vollständig auf die neue Hetzner-IP umgestellt. In den DNS-Zonen lagen alte IPv4- und IPv6-Adressen; außerdem fehlten für einzelne Domains Mail-Einträge. Das haben wir nicht kleingeredet, sondern systematisch repariert.

    Geprüft und korrigiert wurden unter anderem:

    • die A- und AAAA-Einträge der Hauptdomain und aktiver Subdomains;
    • MX und SPF;
    • der von YunoHost tatsächlich verwendete DKIM-Selektor mail._domainkey;
    • DMARC;
    • CAA für Let’s Encrypt;
    • Reverse-DNS für IPv4 und IPv6.

    Beim DKIM-Test lag zunächst auch unsere eigene Annahme daneben: YunoHost nutzte nicht den vermuteten Selektor dkim, sondern mail. Erst die von YunoHost erzeugte DNS-Empfehlung lieferte den korrekten Schlüssel. Genau so muss technische Fehlersuche aussehen: Annahme prüfen, Fehler eingestehen, autoritative Quelle heranziehen und anschließend erneut messen.

    Nach den Korrekturen bestätigte YunoHost für den Bereich E-Mail ausdrücklich: Success! Everything looks OK for Email! Der Server war von außen erreichbar, Port 25 offen, Versand und Empfang grundsätzlich möglich. Die öffentliche IPv6-Rückwärtsauflösung zeigte autoritativ korrekt auf srv.darknight-coffee.org. Die Diagnose meldete außerdem keine einschlägige Blacklist-Notierung.

    T-Online blockierte die IPv4 trotzdem weiterhin mit None/bad reputation.

    Reputation ist eine private Schranke

    Der Begriff „Reputation“ klingt objektiver, als er ist. Dahinter stehen Datenbestände, Gewichtungen, Schwellenwerte und Entscheidungen des jeweiligen Anbieters. Von außen ist häufig nicht nachvollziehbar, wodurch eine IP schlecht bewertet wurde, welche Beobachtung zugrunde liegt, wie aktuell sie ist oder wann eine Neubewertung stattfindet.

    Gerade kleine selbstbetriebene Mailserver geraten dadurch in eine strukturell schwache Position. Große Plattformen verfügen über etablierte Zustellbeziehungen, eigene Abuse-Abteilungen und erhebliche Mengen historischer Versanddaten. Ein kleiner Server kann technisch sauber arbeiten und trotzdem an einer pauschalen Reputationsentscheidung scheitern. Er muss anschließend beweisen, dass er kein Störer ist.

    Die Telekom nennt in ihrer Fehlermeldung immerhin einen Kontaktweg für den Reset. Wir haben ihn genutzt und eine sachliche Prüfung beantragt. Übermittelt wurden die betroffene IP, der Hostname, die vollständige Fehlermeldung und der Hinweis auf die korrigierten Authentifizierungs- und DNS-Daten. Zum Veröffentlichungszeitpunkt steht die inhaltliche Antwort der Telekom noch aus.

    Das ist ein dokumentierter Zwischenstand. Wir behaupten nicht, die Telekom habe den Reset endgültig verweigert. Wir halten aber fest: Bis zur manuellen Prüfung bleiben legitime Nachrichten blockiert.

    Spamabwehr ist nötig – Pauschalblockaden bleiben problematisch

    Natürlich muss T-Online seine Kunden vor Spam, Phishing und Schadsoftware schützen. Ein ungeschützter Mailbetrieb wäre verantwortungslos. Auch eine IP-Reputation kann ein sinnvoller Teil mehrerer Schutzschichten sein.

    Problematisch wird sie, wenn sie zur undurchsichtigen Vorentscheidung wird. In unserem Fall wurden weder DKIM noch Inhalt zum entscheidenden Kriterium, weil die Verbindung vorher endete. Damit entwertet die pauschale IP-Sperre einen Teil der Mechanismen, die legitime Absender gerade zur Authentifizierung betreiben.

    Die Gegenposition lautet: Ein Provider kann nicht jede eingehende Verbindung individuell untersuchen, wenn eine IP zuvor durch Missbrauch auffiel. Das stimmt. Daraus folgt aber nicht, dass legitime Betreiber tage- oder wochenlang in einer undurchsichtigen Sperre festhängen dürfen. Nötig sind nachvollziehbare Gründe, ein erreichbarer Entstörungsweg, kurze Reaktionszeiten und eine überprüfbare Neubewertung.

    Was bei wichtigeren Nachrichten passieren kann

    Unsere beiden wartenden Nachrichten sind konkret und relevant. Der strukturelle Punkt reicht weiter. Derselbe Mechanismus kann auch eine Fristsetzung, eine Nachricht an Angehörige oder einen Hinweis auf einen Krankheitsfall verzögern. Der Absender sieht zwar bei sauberem Serverbetrieb die Warteschlange oder später einen Rückläufer. Der Empfänger weiß jedoch nicht, dass überhaupt jemand versucht hat, ihn zu erreichen.

    Deshalb darf E-Mail für echte Notfälle nie der einzige Kontaktweg sein. Für vorher vereinbarte Notfallkommunikation braucht es mindestens einen zweiten, unabhängig betriebenen Kanal und klare Regeln, wann er benutzt wird. Technische Redundanz ist keine Paranoia, sondern die Lehre aus einem System, in dem ein einzelner Provider Kommunikation bereits am Eingang beenden kann.

    Selfhosting heißt auch Verantwortung übernehmen

    Dieser Fall ist kein Werbetext nach dem Muster „Selfhosting gut, Konzerne schlecht“. Ein eigener Mailserver verlangt Arbeit. DNS, Reverse-DNS, Schlüssel, Warteschlangen, Updates, Missbrauchsschutz und Protokolle müssen verstanden werden. Ein Serverwechsel kann alte Einträge zurücklassen. Wer selbst hostet, muss Fehler suchen und öffentlich geäußerte Kritik mit eigenen Messwerten absichern.

    Der Vorteil liegt nicht in Fehlerfreiheit. Er liegt in der Prüfbarkeit. Wir konnten die Warteschlange sehen, die Ablehnung reproduzieren, die autoritativen DNS-Daten korrigieren und den Zustand erneut diagnostizieren. Bei einem geschlossenen Maildienst bliebe häufig nur die Meldung: „Die Nachricht konnte nicht zugestellt werden.“

    Digitale Souveränität bedeutet deshalb nicht, alles allein zu machen. Sie bedeutet, die eigenen Abhängigkeiten zu kennen, einen Rückweg zu besitzen und gegenüber marktmächtigen Zugangswächtern nicht auf bloßes Vertrauen angewiesen zu sein.

    Fazit

    T-Online hat unseren Mailserver trotz inzwischen sauber bestätigter Mailkonfiguration weiterhin aufgrund einer internen IP-Reputation abgewiesen. Die betroffenen Nachrichten liegen sicher in der Postfix-Warteschlange, sind aber bis zur Aufhebung der Sperre nicht zugestellt.

    Spamabwehr legitimiert keine Blackbox ohne Folgenabschätzung. Wer E-Mail-Infrastruktur für Millionen Menschen betreibt, entscheidet mit solchen Sperren darüber, welche Kommunikation rechtzeitig ankommt. Gerade kleine, unabhängige Server brauchen faire und schnelle Entstörungswege – sonst wird aus Spamabwehr eine Zentralisierung durch technische Tatsachen.

    Wir ergänzen diesen Artikel, sobald die Telekom auf den beantragten Reputation-Reset inhaltlich reagiert und die Zustellung erneut geprüft wurde.

    Quellen und technische Belege

    • T-Online-SMTP-Ablehnung vom 25. August 2026: Fehlercode 554, Begründung None/bad reputation, Reset-Kontakt in der Serverantwort.
    • Postfix-Warteschlangenprüfung auf srv.darknight-coffee.org, 25./26. August 2026: zwei zurückgehaltene Nachrichten mit derselben T-Online-Ablehnung.
    • YunoHost-DNS-Empfehlung und anschließend autoritativ geprüfte A-, AAAA-, MX-, SPF-, DKIM-, DMARC- und CAA-Einträge.
    • Autoritative IPv6-PTR-Prüfung über die Hetzner-Nameserver: Die Rückwärtsauflösung der echten Serveradresse verweist auf srv.darknight-coffee.org; die konkrete IPv6-Adresse wird öffentlich nicht wiedergegeben.
    • YunoHost-Maildiagnose vom 26. August 2026: Success! Everything looks OK for Email!

    Diskussion: https://treff.darknight-coffee.eu

    Blog: https://carrabelloy.darknight-coffee.org/blog/

    Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

  • KI-Aufsicht in Deutschland: Ein Eingang, viele Behörden – und die Machtfrage bleibt offen

    Redaktioneller Folgeentwurf zum Artikel „Das KI-Label kommt – die Hochrisiko-Kontrolle wartet“ Inhaltlicher Vorgänger: https://carrabelloy.darknight-coffee.org/blog/2026/08/02/ki-label-kommt-hochrisiko-kontrolle-wartet/

    Deutschland hat jetzt einen zentralen Eingang für Beschwerden über KI-Systeme. Das ist die gute Nachricht. Die unbequeme Nachricht: Hinter diesem Eingang beginnt kein klarer, gerader Weg, sondern ein Geflecht aus Bundesnetzagentur, Fachaufsichten, Finanzaufsicht, Landesbehörden, Datenschutzaufsicht und einer neu geschaffenen unabhängigen Kammer.

    Seit dem 29. Juli 2026 gilt das KI-Marktüberwachungs- und Innovationsförderungsgesetz, kurz KI-MIG. Damit ist ein offener Punkt meines Artikels vom 2. August geklärt: Deutschland hat sein Durchführungsgesetz, benennt Marktüberwachungsbehörden und schafft einen zentralen Beschwerdeweg. Nicht geklärt ist damit, ob die neue Konstruktion in der Praxis unabhängig, verständlich und wirksam arbeitet.

    Ein Beschwerdeformular ist noch keine Kontrolle. Entscheidend ist, wer nach dem Weiterleiten prüfen, eingreifen und sanktionieren kann.

    Keine Universalbehörde für jede KI

    Das KI-MIG wurde am 22. Juli 2026 ausgefertigt, im Bundesgesetzblatt 2026 Teil I Nummer 223 verkündet und trat eine Woche später in Kraft. Nach Paragraf 2 ist die Bundesnetzagentur grundsätzlich Marktüberwachungsbehörde, soweit keine Sonderzuständigkeit greift.

    Diese Einschränkung ist entscheidend. Bestehende Produkt- und Fachaufsichten bleiben für regulierte Produkte zuständig. BaFin und weitere Finanzaufsichten behalten ihre Aufgaben für beaufsichtigte Finanzunternehmen und Finanzdienstleistungen. Für KI-Systeme bei Landesbehörden legen die Länder ihre zuständigen Marktüberwachungsbehörden durch Landesrecht fest. Bei journalistischen und werblichen KI-Anwendungen von Medienanbietern weist das Gesetz ebenfalls den Ländern eine Rolle zu.

    Die verkürzte Schlagzeile „Die Bundesnetzagentur kontrolliert künftig jede KI in Deutschland“ wäre daher falsch. Deutschland hat ein hybrides Aufsichtssystem geschaffen. Dafür gibt es einen sachlichen Grund: Ein KI-System in einem Medizinprodukt verlangt anderes Fachwissen als ein Kreditmodell, eine biometrische Anwendung oder Software in einer Kommunalverwaltung.

    Das Problem beginnt an den Schnittstellen. Wenn Fachaufsicht, Marktüberwachung, Datenschutz und Landesbehörden jeweils nur ihren Ausschnitt bearbeiten, kann Verantwortung zwischen Zuständigkeiten verdunsten. Das kennt jeder aus dem Serverbetrieb: Synapse kann korrekt laufen, während Nginx Anfragen falsch weiterleitet. Wer nur eine Komponente prüft, findet den Fehler nicht.

    Eine unabhängige Kammer innerhalb der Bundesnetzagentur

    Für bestimmte besonders sensible Hochrisiko-Systeme richtet Paragraf 4 KI-MIG eine unabhängige KI-Marktüberwachungskammer bei der Bundesnetzagentur ein. Dazu gehören bestimmte biometrische Anwendungen sowie Systeme in Strafverfolgung, Migration, Justiz und demokratischen Prozessen.

    Die Kammer besteht aus dem Präsidenten und den Vizepräsidenten der Bundesnetzagentur. Das Gesetz erklärt sie für vollständig unabhängig und frei von Weisungen. Sie muss jährlich dem Bundestag berichten; der erste Bericht für das Jahr 2026 ist bis zum 31. März 2027 vorgesehen. Gleichzeitig nimmt Paragraf 4 Absatz 5 bestimmte Prüfungen nach Artikel 5 und Artikel 26 der europäischen KI-Verordnung aus ihrem Aufgabenbereich aus.

    Europarechtlich ist die Konstruktion nicht beliebig. Artikel 70 der KI-Verordnung verlangt unabhängige, unparteiische und ausreichend ausgestattete nationale Behörden. Für besonders sensible Hochrisiko-Systeme stellt Artikel 74 Absatz 8 zusätzliche Anforderungen an die Unabhängigkeit der zuständigen Stelle.

    Der niedersächsische Datenschutzbeauftragte Denis Lehmkemper hat am 20. August öffentlich vor einer Schwächung der Datenschutzaufsicht gewarnt. Er hält insbesondere bei Schulen, Polizei und anderer Landesverwaltung eine Aufsicht in Niedersachsen für sachlich und verfassungsrechtlich geboten und stellt die europarechtliche Tragfähigkeit der Bundeslösung infrage.

    Diese Kritik ist ernst zu nehmen. Sie ist aber eine fachpolitische und rechtliche Position, kein Gerichtsurteil. Es ist derzeit nicht belegt, dass die Kammer rechtswidrig konstruiert wurde. Ebenso wenig ist wenige Wochen nach Inkrafttreten belegt, dass sie praktisch unabhängig und ausreichend ausgestattet arbeitet.

    Der zentrale Beschwerdeweg: sinnvoll, aber noch unbewiesen

    Paragraf 8 KI-MIG schafft eine zentrale Beschwerdestelle bei der Bundesnetzagentur. Sie soll Eingaben an die zuständige Marktüberwachungsbehörde oder an eine zuständige Grundrechtsbehörde weiterleiten und die beschwerdeführende Person darüber informieren. Das Gesetz verlangt ein zugängliches, barrierefreies und nutzerfreundliches Beschwerdemanagement. Geht eine Beschwerde bei einer unzuständigen Marktüberwachungsbehörde ein, soll auch sie zur Bundesnetzagentur gelangen.

    Das ist bürgerfreundlicher als ein System, in dem Betroffene vor dem ersten Schreiben das gesamte deutsche Verwaltungsgefüge entschlüsseln müssen. Eine Bewerbung wurde automatisiert aussortiert, eine Leistung verweigert oder eine behördliche Entscheidung durch KI beeinflusst – dann braucht es eine erreichbare erste Adresse.

    Der zentrale Eingang ersetzt aber weder Datenschutzbeschwerden nach der DSGVO noch andere Rechtsbehelfe. Welcher Weg im Einzelfall richtig ist, hängt vom System, Betreiber, Zweck und möglichen Rechtsverstoß ab. Dieser Text ist keine Rechtsberatung.

    Der erste Praxistest ist inzwischen möglich. Die Bundesnetzagentur hat ihr KI-Beschwerdeformular freigeschaltet. Beschwerden sind kostenfrei und sollen keinen Frist- oder Formerfordernissen unterliegen. Praktisch nimmt die zentrale Stelle sie aber ausschließlich über das Onlineformular an, nicht per E-Mail. Die Behörde verspricht eine Eingangsbestätigung und Informationen über eine mögliche Weiterleitung; eine feste Bearbeitungsdauer nennt sie nicht. Für Ergänzungen gibt es ein Nachtragsformular mit Vorgangsnummer.

    Abgefragt werden unter anderem Rolle, betroffenes System, Anbieter, Zeitpunkt, vermuteter Verstoß und Anwendungsbereich. Belege können als PDF, PNG oder JPEG mit maximal 20 Megabyte je Datei hochgeladen werden. Sensible Inhalte und persönliche Gesundheitsdaten sollen ausdrücklich nicht in Upload oder Freitext landen. Diese Warnung ist vernünftig, legt aber ein praktisches Problem offen: Ausgerechnet sensible KI-Fälle lassen sich oft nicht ohne sensible Daten belegen. Hier muss die angekündigte Möglichkeit einer späteren individuellen Klärung funktionieren.

    Die ausschließliche Onlineannahme verdient ebenfalls Kontrolle. Das KI-MIG verlangt einen zugänglichen, barrierefreien und nutzerfreundlichen Beschwerdeweg. Ob ein langes Formular mit Datei- und Kategorisierungsvorgaben diesen Anspruch für alle Betroffenen erfüllt, ist noch nicht bewiesen. Der Briefkasten ist real. Seine Alltagstauglichkeit bleibt eine offene Macht- und Zugangsfrage.

    Datenschutz bleibt beteiligt – aber nicht automatisch federführend

    Paragraf 9 KI-MIG verpflichtet Marktüberwachungsbehörden, Datenschutzaufsichtsbehörden einzubeziehen, wenn deren Zuständigkeit berührt ist. Beide Seiten sollen geplante Maßnahmen und Beobachtungen austauschen. Artikel 77 der KI-Verordnung gibt Grundrechtsbehörden außerdem Zugang zu Dokumentation und die Möglichkeit, Tests durch die Marktüberwachung anzustoßen.

    Das ist mehr als ein unverbindlicher Hinweis. Es ist aber weniger als eine automatische Federführung der Datenschutzaufsicht bei jedem Hochrisiko-System. Die pauschale Behauptung einer vollständigen „Entmachtung“ wäre als Tatsachensatz deshalb zu grob.

    Die richtige Frage lautet deshalb nicht schlicht „zentral oder föderal“. Sie lautet: Welche Stelle besitzt Fachwissen, Unabhängigkeit, Ressourcen und echte Eingriffsbefugnisse – und wie arbeiten die Stellen zusammen, wenn mehrere Grundrechte und Rechtsgebiete berührt sind?

    Woran sich die Aufsicht messen lassen muss

    Das Gesetz selbst behandelt die neue Struktur nicht als endgültig bewährt. Paragraf 19 verpflichtet die Bundesregierung, die Behörden- und Kooperationsstruktur erstmals innerhalb von 18 Monaten nach Inkrafttreten zu untersuchen. Innerhalb von drei Jahren ist eine umfassende Wirksamkeitsprüfung vorgesehen. Dabei sollen unter anderem Ressourcen, Zusammenarbeit, Auswirkungen auf Unternehmen und Perspektiven der Zivilgesellschaft berücksichtigt werden. Der Bericht geht an den Bundestag.

    Diese Evaluation braucht mehr als Tätigkeitsprosa. Sinnvolle Fragen sind:

    • Wie viele Beschwerden gingen ein und wie schnell wurden sie richtig zugeordnet?
    • Wie oft verlangten Behörden Dokumentation, Tests oder Korrekturmaßnahmen?
    • Wie häufig arbeiteten Marktüberwachung und Datenschutzaufsicht konkret zusammen?
    • Konnten Betroffene Entscheidungen verstehen und Fehler korrigieren lassen?
    • Welche technische Ausstattung und welches Fachpersonal standen zur Verfügung?
    • Bekamen kleine und freie Anbieter Zugang zu nachvollziehbaren Prüfverfahren statt zu proprietären Compliance-Blackboxen?

    Nicht jede Einzelheit eines laufenden Verfahrens kann öffentlich sein. Aber eine Aufsicht, die nur ihre Organisation beschreibt und keine Wirkung nachweist, verdient kein blindes Vertrauen.

    Was Betreiber und Communities daraus lernen können

    Die staatliche Aufsicht wirkt weit entfernt vom eigenen Server. Das Grundproblem ist jedoch vertraut: Zuständigkeit ohne dokumentierten Ablauf erzeugt Chaos.

    Wer einen KI-gestützten Bot in einem Matrix-Raum betreibt, sollte mindestens festhalten, wer verantwortlich ist, welches Dienstkonto und welche Tokens genutzt werden, welche Daten verarbeitet werden, wo Logs liegen, wie ein Fehler gemeldet wird und wer das System abschalten kann. Ein gemeinsames Support-Postfach ist hilfreich. Es ersetzt aber nicht die Person, die eine Entscheidung prüfen und korrigieren darf.

    Dasselbe gilt für Backups. Ein grüner Jobstatus beweist nur, dass ein Prozess lief. Erst der Restore zeigt, ob Daten wirklich nutzbar sind. Beim KI-MIG ist der zentrale Beschwerdeeingang der erfolgreiche Backup-Job. Der Restore ist die nachweisbar geprüfte und korrigierte Fehlentscheidung.

    Digitale Souveränität verlangt deshalb auch bei Regulierung einen überprüfbaren Rückweg: erreichbare Verantwortliche, offene Prüfkriterien, dokumentierte Entscheidungen und wirksame Korrekturen. Wer nur ein Portal baut, digitalisiert sonst das alte Zuständigkeitsproblem.

    Fazit: Der Briefkasten steht, die Bewährungsprobe beginnt

    Das KI-MIG schließt eine reale Lücke. Seit dem 29. Juli gibt es eine gesetzliche Aufsichtsarchitektur, einen zentralen Kontaktpunkt und einen Beschwerdeeingang. Sonderzuständigkeiten bleiben bestehen, eine unabhängige Kammer soll sensible Hochrisiko-Systeme überwachen, und Datenschutzaufsichten behalten eigene Rechte und Beteiligungsmöglichkeiten.

    Das alles ist belegbar. Nicht belegt ist bisher, dass die Konstruktion im Alltag wirksam ist. Offen bleiben die praktische Unabhängigkeit der Kammer, die föderalen Zuständigkeiten im Detail, die Ausstattung der Behörden und die Qualität des realen Beschwerdewegs.

    Darum sollte die Debatte weder in „Bundesnetzagentur löst alles“ noch in „Datenschutzaufsicht vollständig entmachtet“ abrutschen. Der Maßstab ist konkreter: Kann ein betroffener Mensch eine Beschwerde verständlich einreichen? Wird sie schnell der richtigen Stelle zugeordnet? Kann diese Stelle prüfen, eingreifen und eine fehlerhafte Entscheidung korrigieren?

    Der Briefkasten steht. Jetzt muss Deutschland beweisen, dass dahinter unabhängige Kontrolle und keine Behörden-Rundreise wartet.

    Podcast zum Artikel

    Die ausführliche Podcastfolge mit acht Kapiteln und konkreten Server- und Community-Beispielen:

    https://podcast.darknight-coffee.org/@carrabelloy/episodes/ki-aufsicht-in-deutschland-ein-eingang-viele-behorden-und-die-machtfrage-bleibt-offen

    Quellen

    1. KI-MIG, amtliche Gesamtausgabe: https://www.gesetze-im-internet.de/ki-mig/
    2. Paragraf 2 KI-MIG – Marktüberwachungsbehörden: https://www.gesetze-im-internet.de/ki-mig/__2.html
    3. Paragraf 4 KI-MIG – unabhängige Kammer: https://www.gesetze-im-internet.de/ki-mig/__4.html
    4. Paragraf 8 KI-MIG – Beschwerden: https://www.gesetze-im-internet.de/ki-mig/__8.html
    5. Paragraf 9 KI-MIG – Zusammenarbeit mit Datenschutzaufsichten: https://www.gesetze-im-internet.de/ki-mig/__9.html
    6. Paragraf 19 KI-MIG – Evaluation: https://www.gesetze-im-internet.de/ki-mig/__19.html
    7. Bundesnetzagentur, Pressemitteilung vom 29. Juli 2026: https://www.bundesnetzagentur.de/1112336
    8. Bundesnetzagentur, Informationen zur KI-Verordnung: https://www.bundesnetzagentur.de/ki
    9. Bundesnetzagentur, zentrale KI-Beschwerdestelle und Onlineformular, geprüft am 24. August 2026: https://www.bundesnetzagentur.de/DE/Fachthemen/Digitales/KI/18_Beschwerdestelle/start.html | https://www.bundesnetzagentur.de/_tools/_forms/05_Digitalisierung/904_KI/form_03_beschwerde/node.html
    10. Europäische Kommission, AI Act Service Desk, Artikel 70, 74, 77 und 85: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-70 | https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-74 | https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-77 | https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-85
    11. Landesbeauftragter für den Datenschutz Niedersachsen, Presseinformation vom 20. August 2026: https://www.lfd.niedersachsen.de/startseite/infothek/presseinformationen/kommunalwahlen-rekord-bei-beschwerden-kunstliche-intelligenz-lfd-niedersachsen-prasentiert-tatigkeitsbericht-2025-253210.html
    12. Datenschutzkonferenz, Stellungnahme zum Durchführungsgesetz: https://www.datenschutzkonferenz-online.de/media/st/Stellungnahme_Durchfuehrungsgesetz_KI-VO.pdf
    13. Heise Online, Bericht über die niedersächsische Kritik, 20. August 2026: https://www.heise.de/news/KI-Aufsicht-Niedersachsen-warnt-vor-Entmachtung-der-Datenschutzbehoerden-11421190.html

    CTA

    Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Podcast: https://podcast.darknight-coffee.org/pages/startseite Blog: https://carrabelloy.darknight-coffee.org/blog/ Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

  • Angekündigt ist nicht gestartet: Googles Android-Register bleibt Mitte August lückenhaft

    Google will Android sicherer machen und zugleich offen halten. Das ist der Anspruch. Der überprüfbare Zwischenstand ist unbequemer: Der regionale Durchsetzungsrahmen für die Entwicklerverifizierung ist inzwischen ziemlich konkret. Der für August angekündigte öffentliche Zugang zu wichtigen Ausnahmen und Werkzeugen ist am 16. August dagegen nicht vollständig belegt.

    Das klingt zunächst nach einer gewöhnlichen Verzögerung in einer Produkteinführung. Tatsächlich berührt es die zentrale Machtfrage des neuen Systems: Wer darf künftig Software auf zertifizierten Android-Geräten normal verteilen – der Eigentümer des Geräts, das App-Projekt, ein alternativer Store oder Google als Betreiber des Registers?

    Bereits am 4. August erschienen bei Darknight-Coffee Podcast und Blog zur grundsätzlichen Kontrollarchitektur. Dieser Text ist kein Doppelartikel, sondern ein datiertes Update. Zwei Dinge haben sich präzisiert: Eine offizielle Hilfeseite nennt jetzt ausdrücklich zertifizierte Geräte ab Android 8. Gleichzeitig bleibt ein pauschaler „August-Start ist erfolgt“ zu stark.

    Der September-Rahmen ist belegt

    Google nennt den 30. September 2026 als Beginn der Durchsetzung in Brasilien, Indonesien, Singapur und Thailand. Sieben beteiligte Stores werden aufgeführt: Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Palm Store, vivo V-Appstore und Xiaomi GetApps. Die weltweite Ausweitung ist für 2027 und danach angekündigt.

    Die offizielle Android-Hilfe ordnet die Initiative zertifizierten Android-Geräten ab Android 8 zu. Auf betroffenen Geräten arbeitet laut Google der Systemdienst com.google.android.verifier. Er soll prüfen, ob eine App einem registrierten Entwickler zugeordnet ist.

    Das ist mehr als eine Regel für den Play Store. Die Registrierung verbindet Entwickleridentität, Paketname und normale Installierbarkeit. Nicht registrierte Apps sollen zwar nicht absolut uninstallierbar werden. Google nennt ADB und den Advanced Flow als Ausnahmen. Der Normalweg wird trotzdem neu geordnet: registriert und regulär auf der einen Seite, nicht registriert und nur über einen Sonderweg auf der anderen.

    Wer daraus „F-Droid wird am 30. September weltweit abgeschaltet“ macht, überzieht. Die erste Durchsetzung betrifft vier Länder, sieben beteiligte Stores und zertifizierte Geräte. Der konkrete Effekt auf Installationen und Updates muss auf realen Geräten geprüft werden. Wer dagegen behauptet, es handle sich nur um eine interne Play-Store-Regel, verharmlost die Reichweite.

    Der August-Start ist nicht vollständig nachgewiesen

    Google hatte am 15. Juli drei Bausteine für August angekündigt: Limited-Distribution-Konten, den Android Developer Console API und den Advanced Flow zum Installieren nicht registrierter Apps.

    Für Limited Distribution beschreibt die Dokumentation bereits den geplanten Ablauf. Das kostenlose Konto soll Apps an höchstens zwanzig ausdrücklich autorisierte Geräte verteilen können. Ein QR-Code oder Link stellt den Kontakt her, der Nutzer stimmt am Gerät zu, anschließend erfolgt die Registrierung über die Android Developer Console.

    Doch die offizielle Limited-Distribution-Seite erklärte beim Abruf am 16. August weiterhin, die Anmeldung zum Early Access sei geschlossen. Zugang erhalte nur eine kleine Gruppe; weitere Informationen sollten im August folgen. Das ist kein Beleg für einen allgemeinen öffentlichen Start. Es ist ein Beleg für vorhandene Dokumentation bei weiterhin begrenztem Zugang.

    Ähnlich vorsichtig muss die Console API behandelt werden. Google beschreibt, wie Paketnamen und Schlüssel aus Entwicklungsumgebungen oder CI/CD verwaltet werden sollen. Eine Status-API soll Paketnamen und Berechtigung prüfen. OAuth-Delegation soll alternativen Stores erlauben, Vorgänge im Auftrag eines Entwicklers auszuführen. Eine frei zugängliche API-Referenz, ein eindeutiger General-Availability-Vermerk und ein praktischer Test mit berechtigtem Konto wurden in der zugrunde liegenden Recherche jedoch nicht gefunden beziehungsweise nicht durchgeführt.

    Die richtige Formulierung lautet daher: Google hat Funktionen und Zeitplan weitgehend beschrieben. Ein vollständiger öffentlicher Start aller August-Bausteine ist am 16. August nicht belegt.

    Zwanzig Geräte lösen kein F-Droid-Problem

    Das kostenlose Hobbykonto ist eine echte Ausnahme. Es verzichtet nach Googles Beschreibung auf Gebühr und amtlichen Ausweis. Für eine Lerngruppe, eine Familie oder einen kleinen Testkreis kann das nützlich sein.

    Es ist aber kein Ersatz für freie öffentliche Verteilung. Eine Matrix-Community mit achtzehn Moderatoren, zwei Ersatztelefonen und einem neuen Helfer überschreitet die Grenze bereits. Ein öffentliches F-Droid-Repository kennt seine künftigen Nutzer nicht einzeln und kann sie nicht vorab auf eine Gästeliste setzen. Eine Community-App für Backup-Status, Token-Widerruf oder .well-known-Prüfungen wird nicht unsicherer, nur weil ein einundzwanzigstes Gerät sie benötigt.

    Die Grenze zeigt, welches Modell Google normalisiert: Der Entwickler verwaltet autorisierte Empfänger in einer zentralen Infrastruktur. Freie Verteilung funktioniert anders. Das Projekt stellt Quellcode, Buildinformationen, Signatur und Paket bereit; Nutzer entscheiden selbst, ob sie diesem Vertriebsweg vertrauen.

    Eigene Bewertung: Limited Distribution ist besser als ein vollständiger Ausschluss kleiner Entwickler. Als Antwort auf die Kritik an der Plattformmacht reicht sie nicht. Zwanzig genehmigte Geräte sind ein Testkreis, keine offene Infrastruktur.

    Der Advanced Flow ist Schutz und Abstufung zugleich

    Google beschreibt für erfahrene Nutzer einen einmaligen Freischaltweg: Entwicklermodus aktivieren, bestätigen, dass keine telefonische oder andere Anleitung durch Dritte erfolgt, Gerät neu starten, erneut authentifizieren, einen Tag warten und die Ausnahme anschließend für sieben Tage oder unbefristet aktivieren.

    Die Schutzlogik ist plausibel. Scam-Coaching lebt von Zeitdruck und Fernanleitung. Neustart und Wartefrist können einen laufenden Betrugsversuch unterbrechen. Wer das leugnet, stellt eine politische Zuspitzung über die technische Realität.

    Die andere Hälfte der Realität lautet: Dieselbe Hürde trifft bewusst gewählte freie Software aus einer bekannten Quelle. Der Ablauf unterscheidet nicht zuerst zwischen einer APK aus einem anonymen Chat und dem dokumentierten Build einer Community. Er unterscheidet nach Registerstatus. Damit wird unabhängige Software vom normalen Eigentümerentscheid zum besonders behandelten Ausnahmefall.

    Eigene Bewertung: Warnungen, Signaturhinweise und Schutz vor erkennbarer Fernsteuerung sind richtig. Eine pauschale Hürde aus Entwicklermodus, Neustart und Wartefrist macht den Konzernregistereintrag aber zum Privileg des bequemen Weges. Freiheit bleibt formal erhalten und wird praktisch herabgestuft.

    Paketnamen sind die eigentliche Machtstelle

    Für Google Play hat Google Regeln zur Registrierung von Paketnamen veröffentlicht. Der Schlüssel mit mehr als fünfzig Prozent der bekannten Installationen soll priorisiert werden. Ohne Mehrheitsinhaber können Schlüssel mit mindestens fünfzig Installationen berechtigt sein. Unterhalb der Schwelle gilt zunächst „first come, first served“; weitere Schlüssel benötigen einen Antrag.

    Für freie Software ist das keine bloße Verwaltungsfrage. Reguläre F-Droid-Pakete werden häufig aus geprüftem Quellcode neu gebaut und mit einem F-Droid-Schlüssel signiert. Bei reproduzierbaren Builds kann F-Droid den eigenen Nachbau mit einer upstream-signierten APK vergleichen und anschließend das Original verteilen. Nicht jede App und Version ist jedoch reproduzierbar.

    Damit können Upstream, F-Droid und weitere Repositories technisch legitime, aber unterschiedlich signierte Pakete derselben freien Software anbieten. Ein zentrales Register muss entscheiden, welcher Schlüssel welchem Paketnamen zugeordnet wird. F-Droid erklärt, es könne Entwickler weder zur Google-Registrierung zwingen noch deren Paketnamen stellvertretend beanspruchen.

    F-Droids Warnung, das System könne den Store „wie wir ihn heute kennen“ beenden, ist eine Interessenposition des betroffenen Projekts. Sie ist keine eingetretene Tatsache. Die strukturelle Kollision ist trotzdem real: Ein dezentrales Build- und Vertriebsmodell trifft auf eine zentrale Namens- und Identitätsordnung.

    Identität ist keine Codeprüfung

    Googles stärkstes Gegenargument darf nicht unterschlagen werden. Wiederkehrende Betrüger können unter wechselnden Namen Apps verbreiten. Eine überprüfte Identität erhöht ihre Kosten. Smartphones werden außerdem von Menschen genutzt, die keine APK-Signaturen oder Buildketten beurteilen können.

    Eine Identität beantwortet aber nur einen Teil der Sicherheitsfrage. Sie beweist nicht, dass das Binärpaket aus dem veröffentlichten Quellcode entstand. Sie verhindert keine kompromittierte Bibliothek und kein übernommenes Entwicklerkonto. Auch F-Droids Modell garantiert keinen fehlerfreien Code und keinen reproduzierbaren Build für jede App. Sicherheit braucht mehrere Ebenen: Signaturen, nachvollziehbare Builds, transparente Berechtigungen, schnelle Updates, verständliche Warnungen und belastbare Verantwortlichkeiten.

    Eigene Bewertung: Google verbindet eine sinnvolle Rechenschaftsfunktion mit einer Infrastruktur für Marktzugang. Das kann Betrug erschweren und zugleich Abhängigkeit erzeugen. Der erste Effekt macht den zweiten nicht unsichtbar.

    Was Betreiber jetzt tun sollten

    Freie Projekte und Communities müssen nicht in Panik geraten. Sie sollten ihren Bestand erfassen:

    • Welche Paketnamen werden verteilt?
    • Wer kontrolliert die Signaturschlüssel?
    • Welche APKs stammen vom Upstream, welche aus F-Droid oder eigenem Build?
    • Welche Geräte sind zertifiziert und laufen mit Android 8 oder neuer?
    • Reicht ein Rahmen von zwanzig Geräten einschließlich Ersatz- und Testgeräten wirklich aus?

    Ein Update- und Restore-Test auf einem Ersatzgerät ist wertvoller als zehn Vermutungen. Prüfsummen, Schlüssel-Fingerprints und Verantwortlichkeiten gehören in die Betriebsdokumentation. Für interne Apps braucht es einen Rückweg, falls Registrierung, API oder Store nicht erreichbar sind.

    Vor allem braucht es sprachliche Disziplin. Bis ein allgemeiner Zugang, eine eindeutige API-Freigabe oder reale Feldtests vorliegen, müssen offene Punkte offen bleiben. Kritik an Plattformmacht wird nicht schwächer, wenn sie Unsicherheit benennt. Sie wird glaubwürdiger.

    Fazit

    Der September-Termin ist real. Die Geräteklasse ab Android 8 ist jetzt offiziell benannt. Die geplante Verknüpfung von Entwickleridentität, Paketname und normaler Installierbarkeit ist keine Erfindung von Kritikern.

    Ebenso real ist die Lücke im August: Die öffentliche Limited-Distribution-Seite zeigt weiterhin geschlossenen Early Access. Die Console API ist beschrieben, aber ihre allgemeine Produktivverfügbarkeit nicht eindeutig belegt. Deshalb darf eine Ankündigung nicht als vollzogener Start verkauft werden.

    Google verbietet freie Android-Software nicht vollständig. Google macht die eigene Registrierung jedoch zum Normalweg und verschiebt freie Verteilung in einen Ausnahmeweg. Das ist die belegbare Linie – ohne Panik, aber auch ohne Weichspüler.

    Eigene Schlussbewertung: Ein Smartphone gehört seinem Käufer nur dann praktisch, wenn dieser einen unabhängigen, verständlichen und dauerhaften Weg zur Installation signierter Software besitzt. Sicherheit darf diesen Weg mit Informationen schützen. Sie darf ihn nicht in eine widerrufliche Konzern-Ausnahme verwandeln.

    Quellen

    Alle Webquellen wurden für die zugrunde liegende Recherche am 16. August 2026 zwischen 05:01 und 05:08 UTC abgerufen.

    1. Google, Android Developers Blog, „Building a safer ecosystem together“, aktualisiert am 15. Juli 2026

      2. https://android-developers.googleblog.com/2026/06/android-developer-verification.html

    2. Google, Android Developers, „Android developer verification – Guides“

      3. https://developer.android.com/developer-verification/guides?hl=en

    3. Google, Android Developers, „Register for limited distribution on Android devices“

      4. https://developer.android.com/developer-verification/guides/limited-distribution?hl=en

    4. Google, Android Developers, „Register on Android Developer Console“

      5. https://developer.android.com/developer-verification/guides/android-developer-console?hl=en

    5. Google, Android Developers Blog, „Balancing openness and choice with safety“, März 2026

      6. https://android-developers.googleblog.com/2026/03/android-developer-verification.html

    6. Google, Android Help, „Learn about Android developer verification“

      7. https://support.google.com/android/answer/17065026

    7. Google, Play Console Help, „Registering Play package names“

      8. https://support.google.com/googleplay/android-developer/answer/16984799

    8. F-Droid, „F-Droid and Google’s Developer Registration Decree“, 29. September 2025

      9. https://f-droid.org/2025/09/29/google-developer-registration-decree.html

    9. F-Droid, „Reproducible Builds“

      10. https://f-droid.org/en/docs/Reproducible_Builds/

    CTA

    Diskussion: https://treff.darknight-coffee.eu/@carrabelloy Podcast: https://podcast.darknight-coffee.org/pages/startseite Blog: https://carrabelloy.darknight-coffee.org/blog/

    Wenn dir das Projekt hilft: Spendenlinks sind im Blog.

    Freigabevermerk

    • Freigabe erforderlich: ja.
    • Veröffentlichung erfolgt: nein.
    • Kein Posting-, Upload- oder Veröffentlichungsskript ausgeführt.

  • Der Server antwortet, aber der Chat steht: Die Lehre aus Synapse 1.159.0

    Nginx meldet keinen Fehler. Synapse läuft. Der Healthcheck ist grün. Der Client erhält sogar 200 OK. Trotzdem erscheinen keine neuen Nachrichten. Genau diese Art von unsichtbarem Stillstand steckt hinter einem technisch unscheinbaren Fix in Synapse 1.159.0.

    Das stabile Release vom 18. August 2026 korrigiert die fehlende Replikation des Stroms quarantined_media, wenn ein Worker als Writer für Änderungen an Medienquarantänen eingesetzt wurde. In einer passenden Mehrprozess-Konfiguration konnte daraus mehr werden als ein Moderationsproblem: Allgemeine /sync-Anfragen konnten wiederholt leer zurückkommen und praktisch unbegrenzt festhängen.

    Das ist kein belegter Totalausfall von Matrix. Es ist keine veröffentlichte Sicherheitslücke und kein Nachweis, dass jede Synapse-Installation betroffen war. Der Fall ist trotzdem wichtig, weil er die schwache Stelle vieler Betriebsmodelle offenlegt: Wir messen, ob ein Prozess lebt. Wir messen zu selten, ob die eigentliche Nutzerfunktion noch vorankommt.

    Was 1.159.0 nachweislich behebt

    GitHub weist Synapse 1.159.0 als stabiles, nicht vorveröffentlichtes Release aus. Der annotierte Tag ist gültig signiert. Laut Changelog wurde der quarantined_media-Replikationsstrom nicht gesendet, wenn der konfigurierte Writer für quarantined_media_changes ein Worker statt des Hauptprozesses war.

    Pull Request 20085 beschreibt die Ursache: Bei Einführung des Stroms fehlte seine Registrierung in ReplicationCommandHandler._streams_to_replicate. Der betroffene Worker verschickte daher keine RDATA– oder POSITION-Nachrichten für diesen Strom. Der Fix trägt den Strom nach, erweitert die Konfigurationsvalidierung, präzisiert die Routing-Dokumentation und ergänzt einen Mehrprozess-Test.

    Das Changelog ordnet den Grundfehler Synapse 1.152.0 zu. Pull Request 19764 nahm den Quarantänestrom später in den allgemeinen StreamToken auf; das Changelog führt diese Änderung unter 1.154.0rc1. Die belastbare Versionsaussage lautet deshalb: Der fehlende Replikationspfad bestand laut Projekt ab 1.152.0. Die konkret dokumentierte Wirkung auf allgemeine Sync-Warteprüfungen war ab der in 1.154.0 enthaltenen Token-Änderung möglich. Behoben ist die Kette in 1.159.0.

    Daraus folgt ausdrücklich nicht, dass jede Installation von 1.152.0 bis 1.158.0 sichtbar betroffen war. Die Fehlerwirkung verlangte eine bestimmte Worker-Topologie und Writer-Zuordnung.

    Wie ein gültiger Token „aus der Zukunft“ kam

    Ein Matrix-Client erhält bei /sync einen Token, der den Fortschritt verschiedener interner Ströme bündelt. Kennt Worker A beim Quarantänestrom beispielsweise Position 42, kann er dem Client einen entsprechenden Token geben.

    Die nächste Anfrage landet durch die Lastverteilung bei Worker B. Dieser kennt wegen des fehlenden Replikationspfads nur Position 41. Für B liegt der Client-Token in der Zukunft. Synapse wartet mit wait_for_stream_token(...) darauf, dass B den fehlenden Stand erreicht.

    Doch genau das kann nicht passieren, wenn B die nötige Replikationsnachricht nie erhält. Nach einem internen Timeout von etwa zehn Sekunden liefert der Worker eine leere, formal erfolgreiche Antwort. Gerät der Client erneut an einen zurückliegenden Worker, wiederholt sich das Spiel.

    Issue 20080 dokumentiert dieses Verhalten auf matrix.org: identische Sync-Tokens, leere Antworten und auffällige Zehn-Sekunden-Rückläufe. Ein Clientneustart mit frischem Sync konnte vorübergehend helfen. Das war ein Workaround, kein Server-Fix.

    Ebenso wichtig ist die Grenze: Die geprüften Quellen belegen keinen dauerhaften Nachrichtenverlust. Sie belegen ausbleibenden Sync-Fortschritt und verspätete Anzeige.

    Warum eine Medienfunktion den ganzen Chat bremsen konnte

    Synapse versteht Medienquarantäne nicht als Löschen. Die Admin-Dokumentation beschreibt eine Markierung, durch die Medien für Nutzer unzugänglich werden; Datei und Vorschaubilder bleiben erhalten. Die API für Quarantäneänderungen arbeitet zudem ausdrücklich nach dem Best-effort-Prinzip.

    Das sichtbare Symptom des Fehlers war trotzdem nicht „ein Bild lässt sich noch öffnen“, sondern „der Chat zeigt nichts Neues“. Ursache ist die gemeinsame Token-Struktur. Sobald der Quarantänestrom in den allgemeinen Fortschrittstoken eingebunden war, mussten alle Sync-Worker einen konsistenten Stand dieses Stroms kennen.

    Ein fachlich kleiner Nebenstrom wurde damit Teil einer zentralen Wahrheitsprüfung. Das ist keine Besonderheit freier Software und kein Argument gegen Skalierung. Es ist eine typische Eigenschaft verteilter Systeme: Die Datenbank kann richtig sein, während einzelne Prozesse unterschiedliche Wirklichkeiten sehen.

    Synapse 1.159.0 präzisiert außerdem das Routing. Quarantäne-Endpunkte müssen direkt zu einem passenden Writer geleitet werden, der zugleich das Medien-Repository ausführen kann. Wer Nginx nur auf Erreichbarkeit prüft, prüft diese fachliche Zuordnung nicht.

    200 OK ist kein Funktionsnachweis

    Klassisches Monitoring sieht in diesem Fall leicht gesund aus. Prozess läuft, Port offen, TLS gültig, Redis verbunden, Nginx erreicht das Backend. Der Nutzer erlebt trotzdem einen festgefahrenen Messenger.

    Für einen Matrix-Homeserver braucht es deshalb mehrere Prüfebenen:

    1. DNS, TLS und .well-known bestätigen Erreichbarkeit und korrekte Serverzuordnung.
    2. Healthchecks bestätigen, dass Prozesse grundsätzlich antworten.
    3. Funktionale Tests bestätigen Login, Raumbeitritt, lokale und föderierte Nachrichten, verschlüsselte Kommunikation und Medienzugriff.
    4. Sync-Tests prüfen, ob next_batch-Tokens fortschreiten und neue Ereignisse auch über wiederholte Worker-Wechsel eintreffen.
    5. Bei Mehrprozess-Betrieb müssen Replikationsstände und Timeouts sichtbar werden.

    Die letzten beiden Punkte sind die Lehre aus diesem Vorfall. „Der Server antwortet“ ist eine Transportaussage. „Die Community kann kommunizieren“ ist eine Funktionsaussage.

    Was Betreiber kontrolliert tun können

    Zuerst muss die reale Lage festgestellt werden: Welche Synapse-Version läuft? Gibt es mehrere Worker? Ist stream_writers.quarantined_media_changes konfiguriert? Welche Prozesse bedienen /sync, welche die Quarantäne-Endpunkte? Eine Einzelprozess-Instanz ist durch die beschriebene Worker-Differenz nicht als betroffen belegt.

    Vor einem Update gehört der Rückweg auf den Tisch. Zu einem vollständigen Synapse-Backup zählen mindestens PostgreSQL-Datenbank, Medien, Konfiguration und Signierschlüssel. Eine Sicherung ist erst belastbar, wenn der Wiederherstellungsweg bekannt und getestet ist.

    Nach dem Update beginnt die Abnahme. Ein kontrolliertes Testkonto sollte neue Ereignisse in einem privaten Raum empfangen, wiederholte Sync-Anfragen sollten voranschreiten, und bei vorhandener Worker-Lastverteilung darf der Zustand nicht von einem einzelnen Prozess abhängen. Medienzugriff und Quarantänepfad müssen getrennt geprüft werden. Reale Access Tokens, Raum-IDs und interne Konfigurationen gehören nicht in öffentliche Fehlerberichte.

    Gegenposition: Für kleine Selfhoster nur ein Großserverproblem?

    Die Gegenposition ist berechtigt. Der dokumentierte Fehler traf eine skalierte Mehrprozess-Konfiguration auf matrix.org. Kleine Server mit einem einzelnen Synapse-Prozess sollten daraus keinen künstlichen Notfall ableiten. Der Fix war bereits im Release Candidate enthalten und ist jetzt stabil veröffentlicht.

    Die Abgrenzung ändert aber nichts an der allgemeinen Betriebslehre. Gerade kleine Community-Projekte können sich keine stundenlangen grünen Scheinausfälle leisten. Sie brauchen nicht zwingend dieselbe Metriklandschaft wie matrix.org. Sie brauchen aber einen einfachen funktionalen Test, der zeigt, ob neue Nachrichten tatsächlich ankommen.

    Bewertung: Souveränität braucht beobachtbare Wirklichkeit

    Meine redaktionelle Bewertung: Freier Quellcode ist in diesem Fall ein handfester Vorteil. Fehlerbericht, Maintainer-Erklärung, Patch, Commit und Test sind öffentlich nachvollziehbar. Bei einer geschlossenen Plattform bliebe Nutzern häufig nur die Meldung „Es gibt Probleme“.

    Doch Offenheit allein betreibt keinen Server. Digitale Souveränität entsteht erst, wenn eine Community Versionen kennt, Topologien dokumentiert, Backups wiederherstellen kann und echte Nutzerwege überwacht. Wer nur CPU, RAM und HTTP-Status misst, besitzt Infrastruktur, aber keine belastbare Aussage über deren Zweck.

    Das Synapse-Projekt arbeitet bereits an besserer Sichtbarkeit. Pull Request 20095 soll Timeouts von wait_for_stream_token zählen. Pull Request 20097 soll pro Prozess die Position von ID-Generatoren ausgeben. Beide waren am Morgen des 19. August 2026 noch offen und nicht Teil des stabilen Tags 1.159.0. Der Fix ist veröffentlicht; die verbesserte Früherkennung ist noch Arbeit.

    Fazit

    Synapse 1.159.0 behebt einen eng konfigurationsabhängigen, aber real dokumentierten Worker-Replikationsfehler. Seine Wirkung zeigt, warum ein grünes Dashboard täuschen kann: Der Server antwortet, während der Chat praktisch steht.

    Die richtige Reaktion ist keine pauschale Alarmmeldung. Sie ist eine saubere Prüfkette: Version und Topologie feststellen, Writer-Routing verstehen, vollständigen Rückweg sichern, kontrolliert aktualisieren und Kommunikation statt bloßer Erreichbarkeit testen.

    Vor einer Veröffentlichung müssen der aktuelle stabile Synapse-Stand sowie die Pull Requests 20095 und 20097 erneut geprüft werden. Eine lokale Betroffenheit von Darknight-Coffee wurde nicht untersucht und wird nicht behauptet.

    Quellen

    1. Synapse Release v1.159.0: https://github.com/element-hq/synapse/releases/tag/v1.159.0
    2. Synapse Changelog release-v1.159: https://github.com/element-hq/synapse/blob/release-v1.159/CHANGES.md
    3. Pull Request 20085, Ursache und Fix: https://github.com/element-hq/synapse/pull/20085
    4. Dateien und Mehrprozess-Test zu PR 20085: https://api.github.com/repos/element-hq/synapse/pulls/20085/files
    5. Fix-Commit: https://github.com/element-hq/synapse/commit/62a4bc46203880dd5034483b0e84156d03a3a8c6
    6. Issue 20080, dokumentierter /sync-Stillstand: https://github.com/element-hq/synapse/issues/20080
    7. Pull Request 19558, Einführung des Quarantäneänderungsstroms: https://github.com/element-hq/synapse/pull/19558
    8. Pull Request 19764, Aufnahme in StreamToken: https://github.com/element-hq/synapse/pull/19764
    9. Synapse Media Admin API: https://element-hq.github.io/synapse/latest/admin_api/media_admin_api.html
    10. Synapse Worker-Dokumentation: https://element-hq.github.io/synapse/latest/workers.html
    11. This Week in Matrix, 14. August 2026: https://matrix.org/blog/2026/08/14/this-week-in-matrix-2026-08-14/#synapse-website
    12. Offener Pull Request 20095: https://github.com/element-hq/synapse/pull/20095
    13. Offener Pull Request 20097: https://github.com/element-hq/synapse/pull/20097

    CTA

    Wie stellt ihr fest, ob euer Matrix-Server nicht nur erreichbar ist, sondern wirklich synchronisiert? Diskussion: https://treff.darknight-coffee.eu/@carrabelloy

    Podcast: https://podcast.darknight-coffee.org/pages/startseite

    Blog: https://carrabelloy.darknight-coffee.org/blog/

    Wenn dir das Projekt hilft: Spendenlinks sind im Blog.