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)
Yggdrasil: Infrastruktur wird besessen
chatmail.at: Infrastruktur wird benutzt
Yggdrasil: Netzwerk ist Beziehung
chatmail.at: Netzwerk ist Dienstleistung
Yggdrasil: Freiheit durch KomplexitÀt
chatmail.at: Einfachheit durch Delegation
Fazit
Yggdrasil macht unabhÀngig von:
- zentralen Serverbetreibern
- DNS als zwingender Vermittlungsinstanz
- klassischen Internet-Routingstrukturen
- Plattformlogiken (âAccount bei Xâ)
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
Yggdrasil verschiebt Energie von âZentrumâ zu âPeripherieâ
â viele kleine WĂ€rmequellen statt weniger groĂerchatmail.at bĂŒndelt Energie in optimierten Clustern
â effizient, aber abhĂ€ngig von StabilitĂ€t und Versorgung
Infologische Kurzform
Yggdrasil: RestwÀrme wird verteilt gedacht
chatmail.at: RestwÀrme wird zentral verwaltet
Yggdrasil: Energie folgt Beziehung
chatmail.at: Energie folgt Infrastruktur
Fazit (erweitert)
Yggdrasil macht zusÀtzlich unabhÀngig von:
- groĂskaliger Rechenzentrumsinfrastruktur
- zentralisierten EnergieabhÀngigkeiten
- globalen Transportwegen fĂŒr Daten
⊠erkauft sich das jedoch durch:
- höhere KomplexitÀt
- schwerer kalkulierbare Effizienz
đ 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
Yggdrasil: KomplexitÀt wird vorverlagert
Chatmail: KomplexitÀt wird delegiert
Yggdrasil: Du verstehst das System oder es funktioniert nicht
Chatmail: Du verstehst das System nicht und es funktioniert trotzdem
Fazit
Technisch:
Yggdrasil ist deutlich komplexer (Netzwerkebene), Chatmail einfacher (Applikationsebene)Administrativ:
Yggdrasil erfordert kontinuierliche Strukturpflege, Chatmail klassischen BetriebRechtlich:
Yggdrasil entzieht sich teilweise klarer Einordnung, Chatmail ist vollstÀndig reguliert
đ 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
Yggdrasil: Resilienz entsteht durch Verflechtung
Chatmail: Resilienz entsteht durch Kontrolle
Yggdrasil: Ausfall wird verteilt
Chatmail: Ausfall wird sichtbar
Fazit
Yggdrasil ist hoch resilient gegenĂŒber:
- Infrastrukturstörungen
- politischen Eingriffen
- Netzfragmentierung
⊠aber abhÀngig von:
- funktionierender Peer-Struktur
- ausreichender NetzgröĂe
- VerstÀndnis der Betreiber
Chatmail-Relay ist resilient innerhalb:
- stabiler Infrastruktur
- klarer Betriebsprozesse
⊠aber anfĂ€llig fĂŒr:
- zentrale AusfÀlle
- regulatorische Eingriffe
- ProviderabhÀngigkeit
đ 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
Single Relay:
â ein Punkt, ein RisikoMultirelay:
â mehr Punkte, weniger Risiko pro PunktYggdrasil:
â kein Punkt, nur Beziehungen
6. Fazit
Ja â Multirelaying erhöht die Resilienz spĂŒrbar, aber:
- es ist ein evolutionÀrer Schritt, kein Systemwechsel
- es verschiebt das System von
âzentralâ â âredundant zentralâ - es erreicht nicht die strukturelle Resilienz von Yggdrasil
đ Entscheidender Satz:
Multirelay verteilt Server â Yggdrasil ersetzt sie.
Kurzform
- chatmail 2.48: besseres Ăberleben im bestehenden System
- Yggdrasil: anderes System des Ăberlebens