mirror of
https://github.com/permissionlesstech/bitchat-android.git
synced 2026-09-19 04:59:59 +00:00
d637b5bc1b
Both of @Chessing234's follow-ups, and both were right. The sheet kept saying "verified". I gated the glyph and the tint and argued the word should stay because the key genuinely is verified. That status sits directly beside `displayName`, so it is not a claim about a bare key — it is a claim about THIS NAME, and that claim is false. And it is the screen someone opens *because* a seal vanished from a row, so the one surface they consult to resolve the doubt was reassuring them. `buildStatusInfo`'s text now demotes with the glyph, and so does `SecurityVerificationActions` — which was a SECOND seal in the same sheet, green `Icons.Filled.Verified` with `fingerprint_verified_label`, that the first revision never gated at all. No new string is needed, which was the objection I had to fixing this: an established session falls through to "encrypted" with a padlock, true and silent about identity, and the not-verified block below already names the current nickname in `fingerprint_not_verified_message_fmt` and offers to verify it. That offer is the recovery — re-verifying re-pins the baseline to the name on screen — and the stored verification is untouched underneath. The consequence, said out loud: a renamed peer's sheet now offers "verify" rather than "remove verification", so unverify is one re-verification away instead of immediately to hand. Better than a green checkmark beside a name nobody verified, but a real change to the affordance. `isNoisePublicKeyVerified(..., renderedName = null)` fail-opened, so any future caller that simply omitted the name would have reinstated the rename attack, silently and without touching that file. The default is gone on both the ChatViewModel and the handler; the single caller already passes the name. 15 binding cases still green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bitchat for Android
A decentralized peer-to-peer messaging app with dual transport architecture: local Bluetooth mesh networks for offline communication and internet-based Nostr protocol for global reach. No accounts, no phone numbers, no central servers.
This is the Android implementation of bitchat, fully protocol-compatible with the iOS version for cross-platform mesh communication.
See it in action
| Offline mesh conversation | Geohash globe picker |
|---|---|
 |
 |
License
This project is released into the public domain. See the LICENSE file for details.
Features
- Dual Transport Architecture: Bluetooth LE mesh for offline messaging, Nostr relays for internet-based messaging
- Location-Based Channels: Geographic chat rooms using geohash coordinates over Nostr relays
- Intelligent Message Routing: Automatically chooses the best transport, with queuing and retry when a peer is unreachable
- End-to-End Encryption: Noise Protocol (XX pattern, X25519 + ChaCha20-Poly1305) for private messages over the mesh
- Decentralized Mesh Network: Automatic peer discovery and multi-hop relay over Bluetooth LE (max 7 hops)
- Wi-Fi Aware Transport: Higher-bandwidth local mesh on supported devices
- Channel Chats: Topic-based group messaging with optional password protection (Argon2id + AES-256-GCM)
- IRC-Style Commands: Familiar
/join,/msg,/whostyle interface - Tor Support: Built-in Tor (Arti) for private internet connectivity
- Emergency Wipe: Triple-tap to instantly clear all data
- Cross-Platform: Binary protocol compatible with bitchat on iOS and macOS
Technical Architecture
Bluetooth Mesh Network (Offline)
- Direct peer-to-peer within Bluetooth range, multi-hop relay through nearby devices
- Noise Protocol sessions with forward secrecy; peer identities derived from static keys
- Compact binary packet format with fragmentation, TTL routing, and deduplication
- Adaptive duty cycling and connection limits for battery efficiency
- Foreground service keeps the mesh alive within Android background execution limits
Nostr Protocol (Internet)
- Global reach via public relays, geohash-based location channels
- Private messages fall back to Nostr for mutual favorites when the mesh is unavailable
- Ephemeral keys per geohash area
Android Stack
- Kotlin, Jetpack Compose (Material 3), MVVM
- Coroutines and Flow for all networking and state
- Core components:
MeshForegroundService(persistent connectivity),BluetoothMeshService/WifiAwareMeshService(transports),UnifiedMeshService(transport selection),NoiseSessionManager(encryption sessions),MessageRouter(mesh/Nostr routing with outbox retry)
Building
Requires Android Studio and the Android SDK (API 26+).
git clone https://github.com/permissionlesstech/bitchat-android.git
cd bitchat-android
./gradlew assembleDebug
Install on a connected device:
adb install -r app/build/outputs/apk/debug/app-debug.apk
The app requests Bluetooth, location (required for BLE scanning), and notification permissions at runtime.
Release APKs and the Android App Bundle can be rebuilt byte-for-byte in the pinned Linux container. Maintainers should follow the Android release guide. See Reproducible builds for the build trust model and public GitHub/Google Play verification procedures.
Testing
# Unit tests
./gradlew test
# Lint
./gradlew lint
# Instrumented tests (requires a device or emulator)
./gradlew connectedAndroidTest
Note that BLE mesh behavior is difficult to emulate; protocol and session logic is covered by unit tests, while radio-level behavior needs real devices.