Nimmermehr!

GegenĂŒberstellung: Yggdrasil vs. chatmail.at

Frage: Wovon macht Yggdrasil unabhÀngig?

Aspekt Yggdrasil-Projekt chatmail.at
Netzinfrastruktur Eigenes Overlay-Netz (IPv6, Peer-to-Peer) Klassisches Internet (DNS, SMTP/IMAP)
Zugang Direkt ĂŒber Peers (keine zentrale Instanz nötig) Zugang ĂŒber bereitgestellte Server
DNS-AbhÀngigkeit Nicht erforderlich (optional nutzbar) Zentrale Rolle (Domain-basiert)
Providerbindung Keine feste Bindung an Anbieter AbhÀngigkeit von chatmail-Servern
Adressierung Kryptografische SchlĂŒssel (Public Keys) E-Mail-Adressen (benutzerfreundlich, aber zentral vergeben)
Transportkontrolle Nutzer kontrolliert eigene Peers und Verbindungen Transport ĂŒber fremde Infrastruktur
Zensurresistenz Hoch (dezentrale Struktur, keine zentrale Abschaltstelle) Mittel (Server können blockiert/abgeschaltet werden)
Vertrauensmodell „Trust the network graph“ (Vertrauen verteilt) „Trust the provider“ (Vertrauen zentralisiert)
Walled Garden Risiko Gering (offenes Protokoll, eigene Infrastruktur möglich) Erhöht (Alternative zu Big Tech, aber dennoch Plattform)
Skalierung Organisch durch Peering Durch ServerkapazitÀten des Anbieters
Offline-/Mesh-FÀhigkeit Möglich (lokale Netze, direkte Verbindungen) Nicht vorgesehen
IdentitĂ€t An SchlĂŒssel gebunden (selbst erzeugt) An Adresse/Provider gebunden
InteroperabilitÀt Protokollbasiert, offen erweiterbar E-Mail-kompatibel, aber serverzentriert

Kurzform (infologisch verdichtet)


Fazit

Yggdrasil macht unabhÀngig von:

chatmail.at reduziert zwar AbhĂ€ngigkeiten von großen Plattformen,
ersetzt sie aber durch eine eigene, kleinere zentrale Struktur.

👉 Infologisch:
Yggdrasil verschiebt das System von „Wer betreibt den Dienst?“
zu „Wer ist Teil des Netzes?“


GegenĂŒberstellung: Yggdrasil vs. chatmail.at

Erweiterung: Energie- & Umweltaspekte

Aspekt Yggdrasil-Projekt chatmail.at
Energieverbrauch (Struktur) Dezentral verteilt auf viele Knoten (Edge-GerĂ€te, Heimserver, MobilgerĂ€te) Zentral gebĂŒndelt in Rechenzentren
Energieeffizienz (pro Nachricht) Variabel – ineffizient bei kleinen Netzen, effizient bei lokaler NĂ€he (Mesh) Meist optimiert durch professionelle Infrastruktur
AbwĂ€rme / RestwĂ€rme Entsteht verteilt (z. B. Heimrouter, GerĂ€te) – potenziell lokal nutzbar Konzentriert in Rechenzentren – industrielle KĂŒhlung notwendig
Netzlast / Routing KĂŒrzere Wege möglich (lokale Peers), keine globalen Backbones nötig AbhĂ€ngig von globalem Internet-Routing
Resilienz bei Energiekrisen Hoch – kann auf Inselnetzen / lokalen Strukturen weiterlaufen Geringer – abhĂ€ngig von durchgehender Infrastruktur
Hardware-Anforderungen Kann auf bestehender Hardware laufen (Router, VPS, Smartphones) Benötigt dedizierte Server-Infrastruktur
Skalierung & Energie Wachstum = mehr Teilnehmer = mehr verteilte Last Wachstum = grĂ¶ĂŸere/mehr Rechenzentren
Umweltbelastung (Systemisch) Diffus, schwer messbar, potenziell ressourcenschonend durch Mitnutzung Klar messbar, aber konzentriert (Strom, KĂŒhlung, Bau von Rechenzentren)
Green-IT-Potenzial Hoch (lokale Nutzung, erneuerbare Eigenversorgung möglich) AbhĂ€ngig vom Anbieter (z. B. Ökostrom-Rechenzentren)
Single Point of Failure (Energie) Kein zentraler Ausfallpunkt Rechenzentrum als kritischer Punkt
„Digitaler Fußabdruck“ Fragmentiert – eher „NebengerĂ€usch“ bestehender Systeme Sichtbar – dedizierte Infrastruktur mit klarer Bilanz

ErgÀnzende Betrachtung


Infologische Kurzform


Fazit (erweitert)

Yggdrasil macht zusÀtzlich unabhÀngig von:


 erkauft sich das jedoch durch:

👉 Infologisch:
Nicht nur Information, auch Energie wird vom Dienst zurĂŒck in die Struktur verlagert.


GegenĂŒberstellung: KomplexitĂ€t

Yggdrasil (Stammhub/Wurzelhub/tyr.wf) vs. Chatmail-Relay


1. Technische KomplexitÀt

Aspekt Yggdrasil + Stammhub/Wurzelhub + tyr.wf Chatmail-Relay
Netzwerkmodell Overlay (IPv6, P2P, eigene Topologie) Klassisches Internet (SMTP/IMAP)
Setup Aufbau eigener Peering-Struktur, Routinglogik, ggf. DNS-Integration (tyr.wf) Installation + Konfiguration eines Mailservers/Relays
Adresslogik Public Keys, optionale Mapping-Layer (DNS, Deeplinks) E-Mail-Adressen, direkt nutzbar
Komponenten Yggdrasil-Daemon, Peers, ggf. Proxy, DNS, Resolver, Tyr-Integration Mail Transfer Agent (Postfix/Exim), ggf. IMAP/SMTP
Fehlersuche Komplex (Overlay, Peering, Erreichbarkeit, NodeInfo) Etabliert (Logs, SMTP-Statuscodes)
Reifegrad Tooling Experimentell / fragmentiert Hoch (Jahrzehnte gewachsen)
Integration (Apps) Muss aktiv gebaut/angepasst werden (z. B. Tyr) Standardisiert (E-Mail funktioniert sofort)

👉 Kurz:
Yggdrasil = Netz bauen
Chatmail = Dienst betreiben


2. Administrative KomplexitÀt

Aspekt Yggdrasil-System Chatmail-Relay
Betriebsmodell Dezentral, selbstorganisiert Zentral, serverbasiert
Wartung Peers pflegen, Topologie beobachten, Updates koordinieren Updates, Spamfilter, Zustellbarkeit
Monitoring Kaum standardisiert Gut etabliert (Mailqueues, Logs, Blacklists)
Skalierung Organisch (mehr Peers) Linear (mehr Last → mehr Serverleistung)
Onboarding Nutzer ErklĂ€rungsbedĂŒrftig (Keys, Peers, Tools) Einfach (E-Mail-Adresse reicht)
Supportaufwand Hoch (ErklÀrungen, individuelle Setups) Mittel (bekannte Probleme)

👉 Kurz:
Yggdrasil = Beziehungsarbeit
Chatmail = Betriebsarbeit


3. Rechtliche KomplexitÀt

Aspekt Yggdrasil-System Chatmail-Relay
Betreiberrolle Unklar / verteilt (wer ist „Provider“?) Klar definiert (Mailserver-Betreiber)
Haftung Diffus (Transit vs. Teilnahme) Konkret (Provider haftet fĂŒr Betrieb)
Datenschutz (DSGVO) Schwer greifbar (keine zentrale Stelle) Klar geregelt (Verarbeitung durch Betreiber)
Missbrauch (Spam etc.) Schwer kontrollierbar Erwartet und reguliert (Spamfilter, Abuse-Handling)
Regulatorische AngriffsflÀche Gering (keine zentrale Instanz) Hoch (Server identifizierbar)
Impressumspflicht etc. KontextabhÀngig, oft umgehbar durch DezentralitÀt In der Regel erforderlich

👉 Kurz:
Yggdrasil = Grauzone / Struktur ohne klare Adresse
Chatmail = klassischer Telemediendienst


4. Meta-Betrachtung

Dimension Yggdrasil Chatmail
KomplexitÀtstyp Strukturell (Architektur, Topologie) Operativ (Betrieb, Regeln)
Kontrolle Hoch (eigene Infrastruktur) Mittel (abhĂ€ngig von Internet-Ökosystem)
Vorhersehbarkeit Niedrig Hoch
Robustheit gegen Eingriffe Hoch Mittel

Infologische Verdichtung


Fazit

👉 Entscheidender Unterschied:
Yggdrasil verschiebt KomplexitÀt vom Betrieb in die Architektur.


GegenĂŒberstellung: Resilienz

Yggdrasil (Stammhub/Wurzelhub/tyr.wf) vs. Chatmail-Relay


1. Technische Resilienz

Aspekt Yggdrasil-System Chatmail-Relay
NetzausfÀlle Teilweise kompensierbar (alternative Peers, Mesh) Kritisch (Server/Provider-Ausfall = Dienst weg)
Routing Dynamisch ĂŒber Netzgraph (Selbstheilung möglich) Statisch ĂŒber Internet-Infrastruktur
Single Point of Failure Kaum vorhanden (außer eigene zentrale Hubs) Vorhanden (Server, DNS, Provider)
Partitionierung (Netztrennung) Kann lokal weiter funktionieren (Inselnetze) Kommunikation bricht ab
Fallback-FÀhigkeit Hoch (Peer-Wechsel, lokale Verbindungen) Gering (abhÀngig von externen Diensten)

👉 Kurz:
Yggdrasil = Netz stirbt langsam
Chatmail = Dienst fÀllt plötzlich


2. Betriebliche Resilienz

Aspekt Yggdrasil-System Chatmail-Relay
Ausfall einzelner Knoten Unkritisch (Netz bleibt funktionsfÀhig) Kann kritisch sein (je nach Architektur)
Lastverteilung Implizit verteilt Muss aktiv organisiert werden
Wiederanlauf Organisch (Peers verbinden sich neu) Administrativ (Server neu starten, Queues bearbeiten)
AbhÀngigkeit von Admins Geringer (Selbstorganisation) Höher (Betrieb erfordert Eingriffe)

👉 Kurz:
Yggdrasil = Resilienz durch Struktur
Chatmail = Resilienz durch Betrieb


3. Politisch / infrastrukturelle Resilienz

Aspekt Yggdrasil-System Chatmail-Relay
Zensur / Abschaltung Schwer (keine zentrale Instanz) Einfacher (Server blockierbar)
ProviderabhÀngigkeit Gering Hoch
DNS-AbhÀngigkeit Optional Kritisch
Regulatorische Eingriffe Schwer durchsetzbar Direkt durchsetzbar
NetzneutralitÀt Intrinsisch (kein zentraler Gatekeeper) Extern abhÀngig

👉 Kurz:
Yggdrasil = politisch resilient
Chatmail = regulatorisch angreifbar


4. Energie- & Krisenresilienz

Aspekt Yggdrasil-System Chatmail-Relay
StromausfÀlle lokal Teilweise kompensierbar (andere Nodes) Server-Ausfall = Dienst weg
GroßflĂ€chige AusfĂ€lle Kann fragmentiert weiterlaufen Bricht zentral zusammen
Minimalbetrieb Möglich (kleine GerÀte, lokale Netze) Nicht sinnvoll (Server erforderlich)
Autarkiepotenzial Hoch (z. B. Inselbetrieb) Gering

👉 Kurz:
Yggdrasil = ĂŒberlebt fragmentiert
Chatmail = funktioniert oder nicht


5. Grenzen der Resilienz

Aspekt Yggdrasil-System Chatmail-Relay
KomplexitÀt als Risiko Hoch (Fehlkonfiguration kann isolieren) Niedriger
AbhÀngigkeit von Einstiegspunkten (Hubs) Teilweise (Wurzel-/Stammhubs kritisch) VollstÀndig (Server zentral)
Usability als Schwachstelle Hoch (Fehler durch Nutzer) Niedriger
NetzgrĂ¶ĂŸe erforderlich Ja (Resilienz wĂ€chst mit Teilnehmerzahl) Nein

👉 Kurz:
Yggdrasil = resilient, wenn verstanden
Chatmail = resilient, wenn betrieben


Infologische Verdichtung


Fazit

👉 Entscheidender Unterschied:
Yggdrasil verteilt das Risiko – Chatmail konzentriert es.


Resilienzgewinn durch Multirelaying (DeltaChat / chatmail 2.48)

Ausgangspunkt

Multirelaying bedeutet:
Ein Client kann mehrere unabhÀngige Mailserver (Relays) parallel oder alternativ nutzen.


1. Was verbessert sich konkret?

Aspekt Vorher (Single Relay) Nachher (Multirelay)
Single Point of Failure Hoch (ein Server = Risiko) Reduziert (mehrere Server verfĂŒgbar)
Ausfallsicherheit Niedrig bis mittel Mittel bis hoch
Lastverteilung Zentral Verteilbar
ProviderabhÀngigkeit Hoch Reduziert
Zensurresistenz EingeschrÀnkt Verbesserbar (Fallback möglich)
Migration Hart (Serverwechsel nötig) Weich (Parallelbetrieb möglich)

👉 Effekt:
Chatmail bewegt sich von zentral → föderiert


2. Was bleibt bestehen?

Aspekt Bewertung
Grundarchitektur Weiterhin serverbasiert (SMTP/IMAP)
DNS-AbhÀngigkeit Bleibt bestehen
Providerrolle Bleibt zentral, nur mehrfach vorhanden
Regulatorische Angreifbarkeit Weiterhin gegeben (Server identifizierbar)
Store-and-Forward-Prinzip UnverÀndert

👉 Wichtig:
Multirelaying = Redundanz, nicht DezentralitÀt


3. Vergleich zur Yggdrasil-Resilienz

Dimension Multirelay (chatmail) Yggdrasil
Resilienztyp Redundanz Struktur
Ausfallmodell „Nimm anderen Server“ „Netz findet neuen Weg“
AbhÀngigkeit Weniger Anbieter, aber weiterhin Anbieter Keine Anbieter nötig
Netzlogik Mehrere Zentren Kein Zentrum
Grenze Wenn alle Relays weg → Ausfall Nur bei kompletter Netzfragmentierung

4. Neue Risiken durch Multirelay

Aspekt Beschreibung
KomplexitÀt steigt Sync zwischen Relays, Zustelllogik
Inkonsistenzen Nachrichten können verzögert oder doppelt auftreten
Metadaten-Spur Mehr Server = mehr Beobachtungspunkte
Trust-Modell Vertrauen verteilt sich – aber verschwindet nicht

5. Infologische Einordnung


6. Fazit

Ja — Multirelaying erhöht die Resilienz spĂŒrbar, aber:

👉 Entscheidender Satz:
Multirelay verteilt Server – Yggdrasil ersetzt sie.


Kurzform