Featured image of post Bitchat (permissionlesstech/bitchat): Bluetooth-Mesh-Chat mit IRC-Vibes – Einrichtung, Sicherheit und Grenzen

Bitchat (permissionlesstech/bitchat): Bluetooth-Mesh-Chat mit IRC-Vibes – Einrichtung, Sicherheit und Grenzen

Bitchat sicher installieren und prüfen: Bluetooth-Mesh-Chat mit IRC-Vibes, Nostr-Fallback, Build-Verifikation, Sicherheitsgrenzen und Entscheidungshilfe.

Wenn das Mobilfunknetz ausfällt oder abgeschaltet wird, sind die meisten Messenger nutzlos. Signal, WhatsApp, Telegram – sie alle brauchen einen erreichbaren Server. Bitchat geht einen anderen Weg: Die App verbindet Geräte in der Nähe direkt über Bluetooth Low Energy und reicht Nachrichten von Gerät zu Gerät weiter. Für Reichweite über den Funkkreis hinaus nutzt sie das Nostr-Protokoll statt eines eigenen Servers.

Titelbild: Bildquelle: permissionlesstech/bitchat

Dieser Artikel beantwortet zwei Fragen, bevor du die App installierst. Erstens: Wie bekommst du eine Version, der du vertrauen kannst? Zweitens: Wann lohnt sich Bitchat überhaupt?

Die kurze Antwort vorweg: Für fast alle ist der App Store der einzig sinnvolle Bezugsweg. Ein Selbstbau aus dem Quellcode gibt die stärkste Garantie, verlangt aber einen Mac mit Xcode. Ob sich die App lohnt, hängt davon ab, ob du ein reales Offline-Szenario hast – Protest, Katastrophe, Großveranstaltung, Funkloch. Als Alltags-Messenger neben Signal taugt sie weniger.

Bitchat auf GitHub – Repository-Karte

Repository-Ansicht: github.com/permissionlesstech/bitchat (Quelle: GitHub)

Kurzantwort

Bitchat sicher installieren und prüfen: Bluetooth-Mesh-Chat mit IRC-Vibes, Nostr-Fallback, Build-Verifikation, Sicherheitsgrenzen und Entscheidungshilfe. Kurz gesagt: permissionlesstech/bitchat: bluetooth mesh chat, irc vibes ist vor allem dann relevant, wenn du schnell verstehen willst, was konkret dahinter steckt, welche Grenzen es gibt und welche Entscheidung daraus folgt. Die Details, Quellen und Einschränkungen stehen in den folgenden Abschnitten.

Was Bitchat ist – und was nicht

Bitchat ist eine quelloffene Peer-to-Peer-Messaging-App für iOS, macOS und Android, geschrieben in Swift. Das Repository permissionlesstech/bitchat beschreibt sie als App mit zwei Transportwegen: einem Bluetooth-Mesh für Offline-Kommunikation und dem Nostr-Protokoll für Nachrichten übers Internet 1. Keine Accounts, keine Telefonnummern, keine zentralen Server des Projekts 1.

Das Projekt steht unter der Unlicense, das heißt: Gemeinfreiheit. Jeder darf den Code kopieren, ändern, verkaufen, kompilieren und weitergeben 1. Das ist die maximal freie Lizenz, aber auch eine ohne jede Garantie und ohne Gewährleistung.

Der aktuelle Stand, geprüft am 20. August 2026: rund 35.660 Sterne, etwa 5.670 Forks, 131 offene Issues 1. Die letzte Veröffentlichung ist Version 1.7.1 vom 31. Juli 2026 2. Das Repository wurde am 4. Juli 2025 angelegt 1. Sterne sind ein Entdeckungssignal, kein Qualitätsurteil – sie sagen etwas über Aufmerksamkeit, nichts über Sicherheit oder Reife.

Wichtig für die Einordnung: Das GitHub-Metadatenfeld „homepage" ist leer. Die README verlinkt den App Store, den Play Store und eine Adresse unter bitchat.free 1, 8, 9. Eine unabhängige Quelle, der Wikipedia-Eintrag zu BitChat, ordnet das Projekt Jack Dorsey und Block, Inc. zu und datiert die Ankündigung auf Juli 2025 5. Diese Zuordnung stammt nicht aus dem Repository selbst, sondern aus der unabhängigen Einordnung.

Was Bitchat nicht ist: kein Ersatz für Signal oder WhatsApp im Alltag. Kein System mit einem zentralen Verzeichnis, das Kontakte findet. Kein Messenger mit einer Garantie, dass eine Nachricht ankommt, wenn niemand in Funkreichweite ist.

Bezugsweg und Verifikation: So bekommst du eine vertrauenswürdige Version

Hier liegt der Kern der Leserfrage. Das Projekt dokumentiert drei Bezugswege in absteigender Vertrauenswürdigkeit 4:

  1. App Store. Apple prüft die Entwicklersignatur, und die Binärdatei lässt sich nicht unbemerkt verändern. Das ist der einzige Kanal, bei dem ein kompilierter Build durchgängig verifizierbar ist. Empfehlung für fast alle 4.
  2. Selbstbau aus verifiziertem Quellcode. Stärkste Garantie, benötigt aber einen Mac mit Xcode.
  3. Kompilierter Build von sonstwo. Nicht verifizierbar – das Projekt kann dabei nicht helfen.

Warum das so streng formuliert ist: Das Repository war Ziel von Aufforderungen zur Löschung 1. Wenn ein Repository oder eine Release-Seite verschwindet, tauchen Mirrors auf, die niemand prüfen kann. Genau dann installieren Menschen, die die App dringend brauchen, irgendeinen Build – und genau dann erreicht eine manipulierte Version diejenigen mit dem meisten zu verlieren 4.

Die Verifikation des Quellcodes läuft über eine Datei SOURCE-MANIFEST.txt, die jede getaggte Release begleitet. Sie listet Tag, Commit, Git-Tree-Hash und einen SHA-256-Hash für jede getrackte Datei 4. Wer selbst baut, prüft damit:

# Manifest außerhalb des Quellbaums ablegen, z. B. /tmp
grep -v '^#' /tmp/SOURCE-MANIFEST.txt > /tmp/files.sha256
shasum -a 256 -c /tmp/files.sha256

Ein FAILED heißt: Diese Datei weicht vom veröffentlichten Quellcode ab. Vor dem Bauen klären 4.

Die Hash-Prüfung allein reicht nicht. Sie prüft nur die Dateien, die das Manifest auflistet, und sagt nichts über nicht gelistete. Das Xcode-Projekt kompiliert aber automatisch jede Quelldatei im Baum. Ein feindlicher Mirror kann die Prüfung bestehen, indem er alle gelisteten Dateien intakt lässt und eine eigene hinzufügt. Deshalb:

git status --porcelain --ignored   # muss nichts ausgeben

Der Einzelwert, der den ganzen Baum abdeckt, ist der Git-Tree-Hash im Manifest-Header:

git rev-parse HEAD^{tree}   # muss der "tree:"-Zeile im Manifest entsprechen

Das Manifest selbst trägt eine Provenienz-Bescheinigung, die es an den Workflow-Lauf bindet. Damit ist auch ein mitgeliefertes Manifest prüfbar:

gh attestation verify /tmp/SOURCE-MANIFEST.txt --repo permissionlesstech/bitchat

Ohne diesen letzten Schritt kann dir, wer dir die Quelle gibt, auch ein passendes Manifest mitgeben 4.

Ehrlich dokumentierte Lücken, damit niemand mehr Schutz annimmt als existiert: kein veröffentlichter Signaturschlüssel, keine verifizierbaren kompilierten Builds außerhalb des App Store, kein Quellcode-Mirror außerhalb von GitHub 4. Wer eine .ipa oder .apk aus einem Forum oder Chat bekommt, kann sie nicht verifizieren – Punkt.

permissionlesstech/bitchat: bluetooth mesh chat, irc vibes – Illustration 2

Die zwei Transportwege: Bluetooth-Mesh und Nostr

Das README beschreibt eine hybride Architektur mit zwei sich ergänzenden Ebenen 1.

Die Bluetooth-Ebene ist der Teil, der offline funktioniert. Geräte entdecken Peers, bauen verschlüsselte Sitzungen auf und leiten Pakete weiter – bis zu sieben Hops 1. Jede App ist gleichzeitig GATT-Central und Peripheral. Es gibt keine Infrastruktur, kein Pairing, keine Accounts 3. Das Whitepaper nennt das eine kontrollierte Flood mit TTL, Deduplizierung und zufälligem Jitter, damit Duplikate unterdrückt werden 3.

Die Verschlüsselung der privaten Nachrichten im Mesh läuft über das Noise-Protokoll (Muster XX, Curve25519, ChaCha20-Poly1305, SHA-256) mit Forward Secrecy für Live-Sitzungen 1, 3. Zwischenknoten sehen nur opake, verschlüsselte Pakete 3.

Die Nostr-Ebene bringt Reichweite über das Internet. Private Nachrichten an gegenseitige Favoriten reisen in app-eigenen, verschlüsselten Umschlägen über öffentliche Relays 1. Das Projekt nennt im README über 440 Relays 1; ein unabhängiger Beitrag spricht von über 290 7. Die genaue Zahl schwankt, die Größenordnung ist klar: ein verteiltes Netz statt eines einzigen Servers.

Wichtig und ausdrücklich dokumentiert: Das private Umschlag-Format ist proprietär und nicht NIP-17-, NIP-44- oder NIP-59-kompatibel. Es nutzt Nostr als Transport, funktioniert aber nur zwischen Bitchat-Clients. Die Payloads liegen in kind-1059-Events, deren v2:-präfixierter Inhalt eine Bitchat-spezifische XChaCha20-Poly1305-Konstruktion ist, nicht NIP-44-Verschlüsselung 1, 3.

Dazu kommen standortbasierte Kanäle über Geohash-Koordinaten: block (7 Zeichen, Häuserblock), neighborhood (6, Viertel), city (5, Stadt), province (4, Bundesland/Region), region (2, Land) 1. Diese Kanäle brauchen Internet, weil sie über Nostr-Relays laufen 1.

Der schwierige Teil ist die Zustellung an einen Peer, der gerade nicht in Reichweite ist. Dafür hat das Whitepaper eine vierstufige Store-and-Forward-Schicht 3:

  • Ein persistenter Postausgang hält private Nachrichten pro Peer (100 Nachrichten, 24 Stunden TTL) und sendet sie bei Wiederverbindung erneut, bis ein Zustell- oder Lesebestätigung sie löscht oder ein Limit von acht Versuchen sie sichtbar aufgibt 3.
  • Courier sind andere Geräte, die Post physisch mitnehmen. Die Nachricht wird an den statischen Schlüssel des Empfängers versiegelt und an bis zu drei verbundene Peers übergeben. Das einzige Routing-Merkmal ist ein 16-Byte-Tag, ein HMAC aus Empfängerschlüssel und UTC-Tag, der sich täglich rotiert – Courier kennen weder Absender noch Empfänger noch Inhalt 3.
  • Spray-and-wait: Umschläge tragen ein Kopienbudget (anfangs 4, maximal 8). Trifft ein Courier einen anderen, gibt er die Hälfte ab. So diffundiert Post durch eine sich bewegende Menge, statt auf einer Person zu reiten 3.
  • Öffentliche Nachrichten werden per Gossip-Sync abgeglichen: 1000 Pakete Cache, etwa alle 15 Sekunden abgeglichen, sechs Stunden lang synchronisierbar 3.

Das erklärt, warum die App auch ohne Empfänger in der Nähe nicht sofort aufgibt – aber auch, warum Zustellung bestenfalls irgendwann passiert und nicht garantiert ist.

Sicherheit: Was dokumentiert ist und wo die Grenzen liegen

Das Projekt trennt Claims, dokumentierte Funktionen und Risiken sauber – im Whitepaper deutlicher als im Marketingtext. Das ist die Stelle, die für die Entscheidung zählt.

Dokumentierte Funktionen: End-to-End-Verschlüsselung privater Nachrichten über Noise im Mesh und über app-eigene Umschläge bei Nostr 1, 3. Ein Panic-Wipe, der per Dreifachtipp alle Daten löscht – Identitätsschlüssel, Favoriten, mitgeführte Courier-Post, den versiegelten Postausgang und Metriken 1, 3. Seit 1.7.1 sind Identitätsschlüssel gerätegebunden (ThisDeviceOnly) und überleben weder einen Umzug auf ein neues Telefon noch eine Neuinstallation 2. Wer die App löscht, verliert die Identität – das ist Absicht.

Die Release-Notizen von 1.7.1 listen konkret, was dort gehärtet wurde 2: Noise-Sitzungen sind an die beanspruchte Peer-Identität gebunden und Leave-Nachrichten signiert, sodass sich ein Peer nicht mehr als jemand anderes ausgeben und dessen DMs abfangen kann. Private Medien werden vor der BLE-Fragmentierung verschlüsselt – Fotos und Sprachnotizen in DMs laufen nicht mehr als Klartext über das Mesh. Announce-Signaturschlüssel sind per TOFU gepinnt, um Identitäts-Spoofing zu unterbinden. Geteilte Inhalte verlangen vor dem Import eine Prüfung. Das sind belegbare Härtungen, keine Werbeversprechen.

Das Whitepaper benennt die Grenzen offen 3:

  • Metadaten sind der schwächste Punkt. Die 8-Byte-Peer-ID in jedem Paket-Header stammt von einem Schlüssel, der sich nie rotiert. Ein passiver Zuhörer in Funkreichweite kann Teilnehmer aufzählen und ein Gerät zwischen Orten und Zeiten verfolgen. Unlinkable Präsenz bietet das Protokoll aktuell nicht 3.
  • Keine Forward Secrecy für versiegelte Courier-Post und für Nostr-Umschläge. Kompromittiert jemand den statischen Schlüssel des Empfängers, kann er zurückgehaltene Chiffrate öffnen, die an diesen Schlüssel adressiert sind 3.
  • Announcements veröffentlichen statische Schlüssel und den Spitznamen im Klartext 3. Padding gibt es nur für Noise-Frames; andere Pakettypen gehen in natürlicher Länge raus 3.

Zur Historie, die das README mit „Takedown-Aufforderungen" andeutet 1: Laut Wikipedia wurde die App im April 2026 in China auf Apples Verlangen aus dem App Store genommen, und im Juli 2026 forderte eine indische Behörde (I4C) GitHub auf, den Code zu entfernen 5. Solche Vorgänge erklären, warum das Projekt so viel Wert auf Verifikation und Offline-Weitergabe legt.

Die App verfolgt nach eigener Datenschutzrichtlinie keine Analytics und sammelt keine Telemetrie 6. Das heißt nicht, dass die Funkebene nichts preisgibt – siehe oben. Wer die App in einem Umfeld einsetzt, in dem Beobachtung Konsequenzen hat, muss die Metadaten-Grenzen genauso ernst nehmen wie die Verschlüsselung.

Kontext: Reale Einsatzfälle und Takedowns

Der praktische Nutzen der App zeigt sich in dokumentierten Fällen. Die Zahlen stammen aus der Wikipedia-Einordnung und den dort zitierten Pressequellen, nicht aus dem Repository 5.

Im September 2025 meldete das Unternehmen 70.000 Downloads aus Madagaskar innerhalb einer Woche während Protesten, bei rund 360.000 Downloads weltweit bis Ende September. In Nepal wurden während Protesten im selben Monat fast 50.000 Downloads an einem einzigen Tag verzeichnet. Im Januar 2026 stiegen die Downloads in Uganda und im Iran während Internetsperren 5.

Der für das Projekt folgenreichste Fall: Im Juli 2026, während der Jantar-Mantar-Proteste in Indien, entfielen zwischen dem 17. und 23. Juli rund 85 Prozent der globalen Downloads auf Indien – verglichen mit einem Prozent in den 30 Tagen davor. Am 23. Juli waren über 330.000 Nutzer aktiv 5. Am selben Tag forderte die indische Behörde I4C GitHub auf, den Code zu entfernen, unter Verweis auf Paragraf 79(3)(b) des Information Technology Act. Im April 2026 war die App in China auf Apples Verlangen aus dem App Store genommen worden 5.

Diese Vorgänge erklären zwei Dinge: warum das README von „Takedown-Aufforderungen" spricht 1, und warum die Verifikation eines Builds hier wichtiger ist als bei einem durchschnittlichen Open-Source-Projekt. Am 28. Juli 2026 führte das Projekt die Offline-Weitergabe der APK für Android ein – über WLAN-Hotspot oder Nearby Share 5. Eine App, die man ohne Store weiterreichen kann, ist für genau die Situationen gedacht, in denen der Store selbst nicht erreichbar ist.

Praktischer Einsatz: Erste Schritte und IRC-Kommandos

Der IRC-Vibe ist konkret: /slap, /msg, /who funktionieren wie im klassischen Chat 1. Das macht die Bedienung für alle, die IRC kennen, sofort vertraut.

Der lokale Kanal heißt mesh und läuft rein über Bluetooth 1. Standortkanäle heißen etwa block #dr5rsj7, neighborhood #dr5rs oder country #dr 1.

So prüfst du, ob das Mesh bei dir funktioniert: Zwei Geräte mit Bitchat in Sichtweite bringen, beide in den mesh-Kanal, eine Nachricht schicken. Läuft sie durch, arbeitet der direkte Link. Für Multi-Hop brauchst du ein drittes Gerät dazwischen. Ohne zweites Gerät in Reichweite gibt es schlicht keinen Empfänger – die App ist kein Funkgerät, das eine leere Umgebung überbrückt.

Bluetooth-Reichweite ist variabel. Ein unabhängiger Test nennt grob 80 Schritte bei einem Android-zu-iOS-Versuch, ausdrücklich als anekdotisch markiert 6. Wände, Körperposition und Hintergrund-Limits von iOS verändern das spürbar 6.

Private Nachrichten wählen den Weg automatisch: Bluetooth zuerst, wenn verfügbar, dann Nostr-Fallback über den öffentlichen Schlüssel des Empfängers, sonst Warteschlange bis zur nächsten Verbindung 1. Die App zeigt eine einzige Konversation, während der Transport darunter wechselt.

Entscheidung: Wann lohnt sich Bitchat?

Klare Kriterien statt Begeisterung.

Bitchat hilft, wenn du eine reale Offline-Anforderung hast: Kommunikation bei Netzabschaltung, Katastrophe, auf Veranstaltungen ohne Mobilfunk, in Funklöchern. Dann ist die Kombination aus lokalem Mesh und Nostr-Fallback ein echtes Werkzeug. Die Nutzungsfälle Protest und Blackout sind dokumentiert und plausibel 5.

Bitchat hilft weniger, wenn du einen normalen Alltags-Messenger suchst. Kein zentrales Kontaktverzeichnis heißt: Du musst Peers in Funkreichweite oder als gegenseitige Favoriten über Nostr haben. In einer leeren Umgebung ist das Mesh leer. Jeder zusätzliche Hop kostet Latenz, Akku und ein weiteres Gerät, das erreichbar bleiben muss 7.

Für Sicherheitsbedarf gilt die nüchterne Reihenfolge aus der Projektdokumentation: App Store für fast alle, Selbstbau für die stärkste Garantie, niemals ein fremder kompilierter Build 4. Wer auf Nummer sicher gehen will, liest das Whitepaper, bevor er die App in ein sensibles Umfeld trägt – die Metadaten-Grenzen sind dort klarer benannt als im README.

FAQ

Ist Bitchat kostenlos? Ja, und gemeinfrei unter der Unlicense. Kein Kaufpreis, keine Abo-Logik im Repository 1.

Braucht Bitchat Internet? Für den lokalen Mesh-Chat nein. Für Nostr-Reichweite und Standortkanäle ja 1.

Auf welchen Systemen läuft die App? iOS, macOS und Android. Der Quellcode ist Swift und zielt laut unabhängiger Einordnung auf iOS 16+ und macOS 13+ 6.

Kann ich einen APK-Build aus dem Internet installieren? Du kannst, aber du kannst ihn nicht verifizieren. Das Projekt rät ausdrücklich davon ab 4.

Was passiert bei der Panik-Löschung? Dreifachtipp löscht Identitätsschlüssel, Favoriten, Courier-Post, Postausgang und Metriken 1, 3. Danach ist die Identität weg.

Sind meine Nachrichten für Relays lesbar? Nein. Relays und Zwischenknoten sehen nur opake Chiffrate 3. Metadaten wie Sender-Präsenz sind dagegen beobachtbar 3.

Wie finde ich Kontakte? Über Peers in Funkreichweite oder gegenseitige Favoriten für den Nostr-Weg. Es gibt kein zentrales Verzeichnis 1, 3.

Wie viele Hops sind möglich? Bis zu sieben laut README und Whitepaper 1, 3.

Ist das private Format mit anderen Nostr-Clients kompatibel? Nein. Die privaten Umschläge funktionieren nur zwischen Bitchat-Clients 1.

Lohnt sich der Selbstbau? Nur, wenn du die stärkste Vertrauensgarantie willst und einen Mac mit Xcode hast. Für fast alle ist der App Store der richtige Weg 4.

Passende Produktrecherchen

Wenn du die praktische Seite vertiefen möchtest, findest du hier passende Suchpfade zum Vergleichen. Keine Kaufpflicht, keine Rangliste, sondern thematisch passende Produktrecherchen:

Hinweis: Als Amazon-Partner verdient kalika.de an qualifizierten Verkäufen. Für dich ändert sich der Preis nicht.

Quellen

[1] permissionlesstech/bitchat – README (GitHub): https://github.com/permissionlesstech/bitchat

[2] Release v1.7.1 (GitHub): https://github.com/permissionlesstech/bitchat/releases/tag/v1.7.1

[3] Bitchat Protocol Whitepaper v2.0: https://github.com/permissionlesstech/bitchat/blob/main/WHITEPAPER.md

[4] Verifying a build (Projektdokumentation): https://github.com/permissionlesstech/bitchat/blob/main/docs/VERIFYING-A-BUILD.md

[5] BitChat (Wikipedia): https://en.wikipedia.org/wiki/Bitchat

[6] FOSS Engineer – Bitchat Mesh Messaging: https://fossengineer.com/bitchat-mesh-messaging/

[7] LavX News – Bitchat pairs Bluetooth mesh with Nostr: https://news.lavx.hu/article/bitchat-pairs-bluetooth-mesh-with-nostr-for-decentralized-messaging

[8] Bitchat im App Store: https://apps.apple.com/us/app/bitchat-mesh/id6748219622

[9] Bitchat im Play Store: https://play.google.com/store/apps/details?id=com.bitchat.droid permissionlesstech/bitchat: bluetooth mesh chat, irc vibes – Illustration 3

Weiterführende Artikel

Transparenzhinweis

Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt und automatisiert auf Quellen, Fakten und Qualitätskriterien geprüft.

Erstellt mit Hugo
Theme Stack von Jimmy