In einer Zeit, in der digitale Kommunikation zunehmend von zentralisierten Plattformen dominiert wird, wächst das Bedürfnis nach Alternativen. Überwachung, Zensur, Plattformabhängigkeit und Metadaten-Exzesse haben das Vertrauen in klassische Messenger nachhaltig beschädigt.
Mit BitChat präsentiert Jack Dorsey einen radikalen Gegenentwurf: einen vollständig dezentralen, serverlosen Messenger, der ausschließlich über Bluetooth Low Energy (BLE) Mesh-Netzwerke kommuniziert. Keine Server, keine Telefonnummern, keine Accounts – nur Geräte, die miteinander sprechen.
Die technische Architektur ist konsequent und bemerkenswert ehrlich. Doch genau diese Ehrlichkeit führt zu einer unbequemen Frage:
Kann ein solches System jemals die kritische Masse erreichen, um über eine Nische hinaus relevant zu werden?
Für wen ist dieser Artikel?
Dieser Beitrag richtet sich an Leser:innen, die tiefer als Marketing-Narrative blicken wollen:
- Architekt:innen und Entwickler:innen, die sich für dezentrale Protokolle, Mesh-Netze und DTN-Konzepte interessieren
- Security- und Infrastruktur-Expert:innen, die Privacy-, Threat-Model- und Funkaspekte bewerten möchten
- Politisch oder zivilgesellschaftlich motivierte Nutzer:innen, die zensurresistente Kommunikation realistisch einordnen wollen
Vorkenntnisse in Netzwerktechnik sind hilfreich, aber nicht zwingend erforderlich.
Die Architektur der Zensurresistenz: konsequent dezentral
BitChat wurde nicht als „WhatsApp ohne Internet“ konzipiert, sondern als bewusst topologie-agnostisches System. Zensurresistenz entsteht hier nicht primär durch Verschlüsselung, sondern durch Architektur.
Echte Topologie-Agnostik
Das System nutzt automatische Peer-Discovery über BLE-Beacons. Es gibt:
- keine festen Rollen
- keine zentralen Knoten
- keine stabilen Adressen
Jeder Teilnehmer ist gleichzeitig Client und Relay. Routing-Entscheidungen erfolgen dynamisch und ausschließlich auf Basis lokaler Informationen, etwa:
- Signalstärke (RSSI)
- kürzlich gesehene Peers
- lokale Relay-Historie
Das Ergebnis ist eine strukturelle Nicht-Adressierbarkeit. Nicht, weil Inhalte verschlüsselt sind – sondern weil es keine feste Netzstruktur gibt, die man adressieren oder abschalten könnte.
Kryptografie und Privacy-by-Design
BitChat setzt auf das Noise Protocol Framework
mit dem XX-Handshake-Muster. Konkret kommt
Noise_XX_25519_ChaChaPoly_SHA256 zum Einsatz, was eine
gegenseitig authentifizierte Ende-zu-Ende-Verschlüsselung
ermöglicht.
Doch BitChat bleibt nicht bei klassischer E2E-Verschlüsselung stehen. Zusätzlich werden gezielt Mechanismen eingesetzt, die Traffic-Analyse erschweren:
-
Ephemere IDs
Keine langfristigen Geräteidentitäten, keine stabilen Profile. -
Timing-Randomization
Zufällige Sendeverzögerungen (ca. 50–500 ms), um Kommunikationsmuster zu verschleiern. -
Cover-Traffic
Regelmäßige Dummy-Nachrichten (ca. alle 30–120 Sekunden), um echten Traffic zu tarnen.
Privacy ist hier kein Feature, sondern eine Systemeigenschaft.
Reichweite: Warum 7 Hops keine Welt retten
Die größte Stärke von BitChat ist zugleich seine größte Schwäche: die vollständige Abhängigkeit von BLE-Mesh. Die Offline-Fähigkeit ist lokal und zeitlich begrenzt.
Das Protokoll definiert eine Time-to-Live (TTL) von maximal 7 Hops. Bei einer typischen BLE-Reichweite von etwa 25–30 Metern pro Hop ergibt sich unter statischen Idealbedingungen eine theoretische Multi-Hop-Ausdehnung von rund 200 Metern. Höhere Reichweitenangaben, wie sie in Teilen der Berichterstattung oder im Marketing (z. B. „100 m pro Hop“) auftauchen, basieren in der Regel auf Laborbedingungen oder optimalen Sichtlinien und sind für reale, bewegte Szenarien nur eingeschränkt belastbar.
Wichtig ist dabei: Diese Zahl beschreibt keine Funkreichweite im klassischen Sinn, sondern eine Momentaufnahme.
Sie setzt voraus, dass:
- eine zusammenhängende Kette von Geräten existiert
- diese Kette während der Weiterleitung stabil bleibt
- die Nachricht alle Relays erreicht, bevor Bewegung, Abschattung oder OS-Eingriffe den Pfad unterbrechen
Diese Annahmen sind in realen Szenarien selten erfüllt.
Nachrichten werden per Store-and-Forward zwischengespeichert:
- normale Nachrichten: ca. 12 Stunden
- danach: Verfall
Eine garantierte Zustellung gibt es nicht. Es existieren keine Zustell- oder Lesebestätigungen, da ein Rückkanal (ACK) bewusst fehlt. Die Zustellung ist probabilistisch – BitChat arbeitet strikt nach dem Best-Effort-Prinzip.
Bewegung, Bramble-Protokoll und DTN-Parallelen
Das Verhalten von BitChat in bewegten Szenarien weist klare Parallelen zu Delay-Tolerant-Networking (DTN)-Ansätzen auf, wie sie etwa im Bramble-Protokoll genutzt werden. Kommunikation erfolgt opportunistisch über Store-and-Forward, ohne stabile Routen oder garantierte Zustellung.
Die Effekte lassen sich auf wenige Kernaussagen verdichten:
- Reichweite: Erhöht sich langfristig durch Bewegung und opportunistische Kontakte.
- Latenz: Steigt stark, da Nachrichten über Zeit „mitgetragen“ werden.
- Zustellwahrscheinlichkeit: Bleibt unsicher, da Hop-Ketten instabiler werden.
BitChat verhält sich damit faktisch wie ein lokales DTN – mit allen bekannten Trade-offs dieses Modells.
Bewegung verändert das Bild – aber nicht zum Besseren im klassischen Sinne. Wenn sich Geräte bewegen und Nachrichten mitnehmen, kann sich die geografische Verbreitung über Zeit deutlich über die statischen ~200 Meter hinaus ausdehnen. Das ist jedoch kein klassischer Netzwerkeffekt, sondern ein Delay-Tolerant-Networking-Effekt:
- Reichweite steigt
- Zeit bis zur Zustellung steigt deutlich
- Zustellwahrscheinlichkeit bleibt unsicher
Gleichzeitig macht Bewegung kurzfristige Multi-Hop-Ketten instabiler. Für schnelle Weiterleitung braucht es ausreichend Überlappungszeit zwischen Peers – genau diese geht bei Bewegung verloren.
BitChat wird dadurch nicht „weiter“, sondern langsamer und unsicherer.
Message Fragmentation und Payload-Grenzen
Ein oft unterschätzter Aspekt von BLE-Mesh-Systemen ist die begrenzte Payload-Größe. Bluetooth Low Energy erlaubt nur sehr kleine Nutzdaten pro Paket, weshalb BitChat Nachrichten intern fragmentiert.
Größere Inhalte werden in mehrere Fragmente aufgeteilt, die jeweils separat übertragen und weitergeleitet werden müssen. Diese Message Fragmentation erhöht die notwendige Airtime pro Nachricht erheblich und verstärkt bei steigender Knotendichte genau jene Effekte, die BLE-Mesh-Systeme ausbremsen:
- Kollisionen
- Paketverluste
- Wiederholungen
Fragmentierung ist damit kein Implementierungsdetail, sondern ein zentraler Verstärker des Skalierungsproblems.
Battery Optimization als systemischer Engpass
Bluetooth Low Energy (BLE) gilt gemeinhin als energiesparend. Diese Aussage stimmt jedoch nur unter der Annahme kurzer, seltener Übertragungen. In einem Mesh-System wie BitChat übernehmen Geräte zusätzlich die Rolle von Relays, was permanentes Scannen, Advertisen und Weiterleiten erfordert.
Die notwendige Battery Optimization zwingt das System zu aggressivem Duty-Cycling, insbesondere bei niedrigen Akkuständen. Mobile Betriebssysteme verschärfen diese Effekte zusätzlich durch Hintergrundbeschränkungen und Prozess-Terminierung.
Energie ist damit kein Randthema, sondern ein weiterer limitierender Faktor für Reichweite, Stabilität und Netzwerkkontinuität.
Der Flaschenhals Bluetooth Low Energy
Das Skalierungsproblem von BitChat ist kein Designfehler. Es ist Physik.
Bluetooth Low Energy (BLE) nutzt nur wenige Advertising-Kanäle mit stark begrenzter Bandbreite (effektiv etwa 1–3 Mbps, geteilt). Mit steigender Knotendichte kommt es zwangsläufig zu:
- Kollisionen
- Paketverlusten
- steigenden Latenzen
Praktische Tests zeigen: Bereits ab etwa 50 Nodes in engem Raum bricht der nutzbare Durchsatz deutlich ein. Das System skaliert nicht elegant – es degradiert langsam.
Oder anders gesagt: Das Mesh beginnt, hauptsächlich mit sich selbst zu reden.
Soziale Realität: Warum Mesh im Alltag scheitert
An diesem Punkt kollidiert Technik mit Realität.
Ich habe selbst an einem vergleichbaren dezentralen Mesh-Projekt gearbeitet – und bin an genau dieser Stelle ausgestiegen. Nicht, weil das System nicht funktionierte, sondern weil es zu gut funktionierte, um seine eigenen Grenzen zu verbergen.
Ein dezentraler Messenger ist nur so nützlich wie die Dichte seines Netzwerks. Wenn Reichweite auf wenige hundert Meter begrenzt ist und Zustellung probabilistisch bleibt, entsteht eine massive Diskrepanz zur Erwartungshaltung moderner Nutzer:
- sofortige Zustellung
- sichtbares Feedback
- Verlässlichkeit
Diese mentale Lücke führt zu geringer Nutzung. Geringe Nutzung führt zu geringer Netzwerkausdehnung. Und das wiederum reduziert den Nutzen weiter.
Ein klassischer Teufelskreis, an dem viele Mesh-Projekte scheitern.
Panic Mode, Vertrauen und das Fehlen von ACKs
Einige Mesh-Messenger – und auch BitChat konzeptionell – diskutieren einen sogenannten Panic Mode. Gemeint ist ein Betriebszustand, in dem Privacy-Mechanismen wie Cover-Traffic, Timing-Randomization oder eine aggressive ID-Rotation priorisiert werden, etwa in akuten Bedrohungsszenarien.
Ein solcher Panic Mode erhöht die Anonymität, verschärft jedoch die bestehenden Trade-offs: noch höhere Latenzen, geringere Zustellwahrscheinlichkeit und weiter steigender Energieverbrauch.
BitChat verzichtet bewusst auf Zustell- oder Lesebestätigungen. Aus technischer Sicht ist das konsequent: In einem anonymen, dynamischen Mesh ohne stabile Identitäten, feste Routen oder verlässlichen Rückkanal wären ACKs selbst unsicher, angreifbar und privacy-schädlich.
Das Problem ist jedoch weniger technischer als psychologischer und organisatorischer Natur.
In der alltäglichen Nutzung wird Kommunikation implizit als verlässlicher Träger von Verantwortung verstanden. Wer eine Nachricht sendet, geht davon aus, dass sie den Empfänger erreicht hat – oder zumindest, dass ein Scheitern erkennbar wäre. Dieses mentale Modell ist tief verankert und folgt der Logik klassischer, verbindungsorientierter Systeme.
Ein Protokoll ohne ACKs kann diese Erwartung nicht erfüllen. Es kann Informationen verbreiten, aber keine Gewissheit erzeugen. Ob eine Nachricht angekommen ist, bleibt offen – selbst dann, wenn sie faktisch zugestellt wurde.
Ohne Zustellbestätigung gibt es keine belastbare Grundlage, Verantwortung über Kommunikation zu delegieren. Damit bricht BitChat bewusst mit der aus klassischen Messengern bekannten „Häkchenkultur“, in der Sichtbarkeit und Bestätigung ein zentrales Vertrauenssignal darstellen.
Broadcast vs. gezielte Empfängeradressierung
Für das Verständnis von BitChat ist eine Unterscheidung zentral, die in klassischen Messengern kaum sichtbar ist: Transport und Lesbarkeit sind entkoppelt.
BitChat kennt auf Transporteebene ausschließlich ein Verhalten: Flooding. Jede Nachricht – unabhängig davon, ob sie öffentlich oder privat ist – wird an alle erreichbaren Peers verteilt und von diesen weitergeleitet.
Der Unterschied liegt nicht im Transport, sondern ausschließlich in der kryptografischen Adressierung:
Öffentliche Nachrichten / Channels
Diese Nachrichten sind nicht Ende-zu-Ende-verschlüsselt für einzelne Empfänger. Jeder Peer, der sie empfängt, kann sie auch lesen. Sie entsprechen funktional einem lokalen Broadcast – vergleichbar mit einer Durchsage, einem Aushang oder einem Zuruf.
Private / direkte Nachrichten
Auch diese Nachrichten werden an alle Peers verteilt. Der Inhalt ist jedoch Ende-zu-Ende-verschlüsselt und kann ausschließlich vom adressierten Empfänger entschlüsselt werden. Alle anderen Knoten sehen lediglich verschlüsselten Payload und fungieren als Transport-Relays.
Damit gilt: In BitChat wird jede Nachricht an alle verteilt – der Unterschied ist nur, wer sie lesen kann.
Diese Architektur erklärt, warum BitChat einerseits sehr gut für lokale Broadcast- und Informationsszenarien geeignet ist, andererseits aber keine gezielte, verlässliche Zustellung im klassischen Sinne bieten kann.
Das System eignet sich für Hinweise, Statusmeldungen oder situative Koordination – nicht jedoch für Absprachen, auf deren Empfang sich Menschen verlassen müssen.
BitChat macht diesen Trade-off bewusst und ehrlich. Doch genau diese Ehrlichkeit begrenzt seine Einsatzmöglichkeiten stärker als jede technische Kennzahl.
Pro- und Kontra-Analyse von BitChat
| Kriterium | Bewertung | Kernaussage |
|---|---|---|
| Architektur | Sehr gut | Zensurresistent, keine Server, keine zentrale Kontrolle |
| Privacy | Sehr gut | Ephemere IDs, Cover-Traffic, Noise-Protokoll |
| Reichweite | Begrenzt | Max. 7 Hops, lokal und situationsabhängig |
| Zustellgarantie | Nicht vorhanden | Reines Best-Effort, keine ACKs |
| Skalierung | Schwach | BLE bricht bei hoher Dichte physikalisch ein |
| Reifegrad | Experimentell | Starkes Design, kaum formale Security Audits |
| UX | Sperrig | Keine Häkchen, wenig Feedback, hohe Unsicherheit |
Threat Model: Staatlicher Gegner, offene Kanäle und reale Risiken
Ein realistisches Einsatzszenario für BitChat in repressiven Staaten (z. B. bei Protesten) erfordert ein klares Threat Model. Entscheidend ist die Unterscheidung zwischen Zensurresistenz und Geheimhaltung.
Öffentliche Kanäle sind bewusst öffentlich
Öffentliche BitChat-Channels sind funktional lokaler Broadcast. Es gibt keine Zugriffskontrolle und keine inhaltliche Verschlüsselung pro Empfänger. Daraus folgt zwingend:
- Man kann nicht bestimmen, wer liest.
- Staatliche Akteure können ohne Hürden mitlesen, indem sie eigene Geräte im Gebiet betreiben.
- Privacy-Mechanismen (Cover-Traffic, Timing-Randomization, ephemere IDs) schützen Muster, nicht den Inhalt öffentlicher Nachrichten.
Öffentliche Nutzung entspricht Aushängen, Durchsagen oder Zurufen – nicht konspirativer Gruppenkommunikation.
Lokalisierung und Ursprungskorrelation
In Gebieten mit hoher staatlicher Präsenz sind statistische Lokalisierungen prinzipiell möglich. Mit ausreichend vielen kontrollierten Geräten lassen sich u. a. korrelieren:
- Zeitpunkt des erstmaligen Auftauchens einer Nachricht
- beobachteter Hop-Count
- Signalstärke (RSSI)
- räumliche Verteilung der Erstempfänger
Die geringe Reichweite einzelner Hops erleichtert diese Korrelation. Ergebnis ist keine exakte Ortung, aber eine wahrscheinliche Ursprungszone. Cover-Traffic reduziert die Genauigkeit, verhindert sie jedoch nicht zuverlässig.
Was BitChat in solchen Szenarien leisten kann – und was nicht
Geeignet:
- situative Hinweise („Sperre hier“, „Tränengas dort“)
- Lagebilder in Echtzeit
- Alarmierung und Informationsverteilung ohne Internet/Mobilfunk
Ungeeignet:
- geheime Planung und Koordination
- Treffpunkte mit Uhrzeiten
- Rollen, Strukturen, Verantwortlichkeiten
- jede Kommunikation, die Vertraulichkeit oder Verlässlichkeit voraussetzt
Kurz gesagt: BitChat schützt die Existenz der Kommunikation, nicht ihre Geheimhaltung.
Fazit: Die wahre Nische
BitChat positioniert sich selbst explizit für Szenarien wie Events, Proteste, Katastrophenfälle und andere Situationen mit lokaler Dichte und fehlender Infrastruktur. Diese offizielle Zielsetzung deckt sich auffällig gut mit den technischen Eigenschaften des Systems – und bestätigt damit indirekt die hier gezogene Grenze zwischen Nische und Massenmarkt.
BitChat ist kein Ersatz für WhatsApp, Signal oder Telegram. Und das will es im Kern auch nicht sein.
Seine Stärke liegt in klar umrissenen Szenarien:
- Lokale Offline-Kommunikation – Events, Camps, Katastrophengebiete
- Ausfall- und Krisenszenarien – wenn Internet oder Mobilfunk nicht verfügbar sind
- Proteste und Aktivismus – physische Nähe, Anonymität, Zensurresistenz
Für den Massenmarkt ist BitChat ungeeignet – nicht wegen schlechter Technik, sondern wegen ehrlicher Technik. Die physikalischen Grenzen von BLE und die bewusste Abkehr von Zustellgarantien lassen sich nicht wegoptimieren.
Hybridansätze, etwa über optionale Brücken zu dezentralen Protokollen wie Nostr oder theoretisch auch Tor-Integration, können die Reichweite erhöhen und globale Kommunikation ermöglichen. Sie verschieben jedoch lediglich die Trade-offs: mehr Reichweite und Erreichbarkeit auf Kosten von Physik-Ehrlichkeit, zusätzlicher Komplexität und neuen Metadatenrisiken. Insbesondere Tor-ähnliche Integrationen verändern das Bedrohungsmodell fundamental und entfernen das System von seinem ursprünglichen Offline-Charakter.
Das eigentliche Hindernis ist nicht die Technologie. Es ist die Erwartungshaltung.
