GitHub - jackjackbits/bitchat: bluetooth mesh chat, IRC vibes

A secure, decentralized, peer-to-peer messaging app that works over Bluetooth mesh networks. No internet required, no servers, no phone numbers - just pure encrypted communication.

Summary

bitchat

A secure, decentralized, peer-to-peer messaging app that works over Bluetooth mesh networks. No internet required, no servers, no phone numbers - just pure encrypted communication.

License

This project is released into the public domain. See the LICENSE file for details.

Features

  • Decentralized Mesh Network: Automatic peer discovery and multi-hop message relay over Bluetooth LE
  • End-to-End Encryption: X25519 key exchange + AES-256-GCM for private messages
  • Channel-Based Chats: Topic-based group messaging with optional password protection
  • Store & Forward: Messages cached for offline peers and delivered when they reconnect
  • Privacy First: No accounts, no phone numbers, no persistent identifiers
  • IRC-Style Commands: Familiar /join, /msg, /who style interface
  • Message Retention: Optional channel-wide message saving controlled by channel owners
  • Universal App: Native support for iOS and macOS
  • Cover Traffic: Timing obfuscation and dummy messages for enhanced privacy
  • Emergency Wipe: Triple-tap to instantly clear all data
  • Performance Optimizations: LZ4 message compression, adaptive battery modes, and optimized networking

Setup

Option 1: Using XcodeGen (Recommended)

  1. Install XcodeGen if you haven’t already:

brew install xcodegen

  1. Generate the Xcode project:

cd bitchat xcodegen generate

  1. Open the generated project:

open bitchat.xcodeproj

Option 2: Using Swift Package Manager

  1. Open the project in Xcode:

cd bitchat open Package.swift

  1. Select your target device and run

Option 3: Manual Xcode Project

  1. Open Xcode and create a new iOS/macOS App
  2. Copy all Swift files from the bitchat directory into your project
  3. Update Info.plist with Bluetooth permissions
  4. Set deployment target to iOS 16.0 / macOS 13.0

Usage

Basic Commands

  • /j #channel - Join or create a channel
  • /m @name message - Send a private message
  • /w - List online users
  • /channels - Show all discovered channels
  • /block @name - Block a peer from messaging you
  • /block - List all blocked peers
  • /unblock @name - Unblock a peer
  • /clear - Clear chat messages
  • /pass [password] - Set/change channel password (owner only)
  • /transfer @name - Transfer channel ownership
  • /save - Toggle message retention for channel (owner only)

Getting Started

  1. Launch bitchat on your device
  2. Set your nickname (or use the auto-generated one)
  3. You’ll automatically connect to nearby peers
  4. Join a channel with /j #general or start chatting in public
  5. Messages relay through the mesh network to reach distant peers

Channel Features

  • Password Protection: Channel owners can set passwords with /pass
  • Message Retention: Owners can enable mandatory message saving with /save
  • @ Mentions: Use @nickname to mention users (with autocomplete)
  • Ownership Transfer: Pass control to trusted users with /transfer

Security & Privacy

Encryption

  • Private Messages: X25519 key exchange + AES-256-GCM encryption
  • Channel Messages: Argon2id password derivation + AES-256-GCM
  • Digital Signatures: Ed25519 for message authenticity
  • Forward Secrecy: New key pairs generated each session

Privacy Features

  • No Registration: No accounts, emails, or phone numbers required
  • Ephemeral by Default: Messages exist only in device memory
  • Cover Traffic: Random delays and dummy messages prevent traffic analysis
  • Emergency Wipe: Triple-tap logo to instantly clear all data
  • Local-First: Works completely offline, no servers involved

Performance & Efficiency

Message Compression

  • LZ4 Compression: Automatic compression for messages >100 bytes
  • 30-70% bandwidth savings on typical text messages
  • Smart compression: Skips already-compressed data

Battery Optimization

  • Adaptive Power Modes: Automatically adjusts based on battery level
    • Performance mode: Full features when charging or >60% battery
    • Balanced mode: Default operation (30-60% battery)
    • Power saver: Reduced scanning when <30% battery
    • Ultra-low power: Emergency mode when <10% battery
  • Background efficiency: Automatic power saving when app backgrounded
  • Configurable scanning: Duty cycle adapts to battery state

Network Efficiency

  • Optimized Bloom filters: Faster duplicate detection with less memory
  • Message aggregation: Batches small messages to reduce transmissions
  • Adaptive connection limits: Adjusts peer connections based on power mode

Technical Architecture

Binary Protocol

bitchat uses an efficient binary protocol optimized for Bluetooth LE:

  • Compact packet format with 1-byte type field
  • TTL-based message routing (max 7 hops)
  • Automatic fragmentation for large messages
  • Message deduplication via unique IDs

Mesh Networking

  • Each device acts as both client and peripheral
  • Automatic peer discovery and connection management
  • Store-and-forward for offline message delivery
  • Adaptive duty cycling for battery optimization

For detailed protocol documentation, see the Technical Whitepaper.

Building for Production

  1. Set your development team in project settings
  2. Configure code signing
  3. Archive and distribute through App Store or TestFlight

Android Compatibility

The protocol is designed to be platform-agnostic. An Android client can be built using:

  • Bluetooth LE APIs
  • Same packet structure and encryption
  • Compatible service/characteristic UUIDs

你知道這意味著什麼吧:)

@Creative
介紹下學校中該軟件的使用場景:)

Last edited by @suen 2025-07-08T09:17:15Z

1 Like

好的,收到!這東西的潛力可大了,尤其是在特定環境下。

@Creative 這就來為你描繪一下 bitchat 在校園裡的各種「花式」玩法和實用場景:


當然知道,這簡直是為特定場景量身打造的神器啊!它創造了一個獨立於學校 Wi-Fi 和電信商訊號的「資訊氣泡」,在需要離線、私密、即時溝通的場合,潛力無窮。

以下是幾個典型的校園使用場景:

場景一:大型活動與戶外教學(運動會、校慶、園遊會、校外參訪)

  • 痛點: 這種場合人山人海,學校 Wi-Fi 必定癱瘓,手機訊號也可能因為基地台超載而塞車。工作人員(老師、學生志工)之間很難即時聯絡。
  • bitchat 方案:
    • 建立工作頻道: 建立一個像 /j #運動會工作組 的頻道,所有工作人員加入。
    • 即時調度: 「三號帳篷的水沒了,快送一箱過來」、「醫護站需要支援」、「某某班的接力賽選手請準備」… 這些短訊息可以透過藍牙 Mesh 網路快速傳遞,不受網路影響。
    • Store & Forward 特性: 即使某位志工暫時跑出了一點通訊範圍,等他再次靠近人群時,之前發給他的訊息也能自動收到,確保訊息不漏接。

場景二:網路訊號死角(地下室社團辦公室、圖書館角落、舊大樓教室)

  • 痛點: 學校總有些地方 Wi-Fi 如同虛設,手機也沒訊號。想在這些地方跟同學討論事情,只能靠吼。
  • bitchat 方案:
    • 建立臨時討論區: 在訊號不好的地下室琴房或社辦,可以快速建立一個臨時頻道,例如 /j #吉他社,方便社員間的溝通。
    • 課堂即時反饋: 在某些收不到訊號的大型階梯教室,老師可以讓大家加入一個課堂頻道,學生有問題可以直接在上面發問,避免打斷課程,也解決了後排同學不敢舉手的問題。

場景三:小組討論與私密空間(圖書館、咖啡廳)

  • 痛點: 小組做報告時,總不能在安靜的圖書館裡一直講話。用 LINE 或其他通訊軟體又很容易被網路上的其他訊息分心。
  • bitchat 方案:
    • 建立加密頻道: 小組可以建立一個密碼保護的頻道 /j #期末報告,然後用 /pass [密碼] 來加密。
    • 專注討論: 因為完全離線,大家可以專心在報告內容上,不會被網路花花世界打擾。所有討論都是點對點加密,保障了小組的智慧財產(和吐槽)。
    • IRC-Style 指令: 對於資工相關科系的學生來說,這種 IRC 風格的指令根本是信仰加成,用起來格外親切。

場景四:緊急情況下的生命線(地震、火災、停電)

  • 痛點: 發生緊急狀況時,電力和通訊網路往往是第一個中斷的。這時如何確認人員安全、傳遞指令就成了大問題。
  • bitchat 方案:
    • 建立緊急頻道: 老師可以快速建立班級頻道,如 /j #三年二班緊急頻道,讓學生報平安。
    • 去中心化優勢: 只要大家的手機還有電,藍牙還能用,這個通訊網路就能運作。每個人都是一個節點,訊息可以「跳」過好幾個人傳到遠處的老師或同學那裡。
    • 緊急清除功能: 如果手機有遺失或被搶奪的風險,連續點擊三次可以清除所有資料,確保敏感對話不外洩。

一把雙面刃…(嘿嘿)

當然,我們都知道,學生們的創造力是無限的…

  • 課堂傳情: 上課時,前後座的同學可以透過 /m @同學A [訊息] 來進行「數位化的傳紙條」,而且還是加密的。
  • 考試「協作」: 在考場這種訊號被屏蔽、網路被阻斷的環境下…它的潛力嘛…你懂的。這絕對是它最「危險」但也最無法忽視的一個場景。(當然,我們強烈不建議這麼做!)

總結來說,bitchat 提供了一種韌性極強的通訊方式,它的價值在於獨立於基礎設施。在校園這種人員密集、場景多變、偶爾網路不給力的環境中,它既可以是提高效率的工具,也可以是保障安全的備案,更可能是學生發揮「小聰明」的溫床。

2 Likes

Screenshot 2025-07-08 at 03.15.28

2 Likes

安卓來了

2 Likes

A clean, white chat application interface named 'bitchat' displays a conversation in green text between '@suen' and '@INI', with a 'YOUR NETWORK' sidebar showing '@INI' as a connected person. (Captioned by AI)
Android has been updated, and we can see each other now…

1 Like

Why the strong push for this?
Because there’s no middleman! :slight_smile:

The reason the internet is inherently insecure at its foundation is that the connection between points is essentially based on carriers… Almost every link can be compromised.
This application… without Wi-Fi, and even after removing the SIM card, by turning on Bluetooth, you can exchange messages within a limited physical range…

Oh, applications of this type weren’t new before, but the one who cooked up this code this time… is Jack Dorsey, who previously cooked up Twitter…

3 Likes
1 Like

其实不太靠谱感觉(
蓝牙的eirp法规限死了而且2.4G的ISM太乱了市区估计通信距离超不过50m,现在点也不够多
物理定律还是在那里……稳定度和传输速度只能二选一
回头招几个无线电的nigga来测试一下这玩意(

1 Like

不过感觉这个要是真能推开(跟airtag似的)感觉覆盖范围会很好
但是估计这东西推不开,运营商阻碍感觉很大,而且蓝牙似乎是有最大连接数限制,到时候真的用的人很多感觉多跳也很难(airtag也得连接上其他果子手机之后靠互联网上传我记得

1 Like

我记得公安是在用800M还是多少的集群,不过那个功率大且传输距离也远(
而且Tor不是据说还有各国搞的钓鱼转发服务器吗,感觉这个真能铺开也很容易做一堆钓鱼服务器(比如给现有基站加蓝牙模块来骗用户通过这个来跳(但是能不能解密还是另说)(但是这个不能解密感觉signal一类也没法解)

1 Like

@Creative A school covers an area of 75 mu, with a building area of 40,000 square meters. With a total of 2000+ personnel, and assuming the number of devices is consistent with the personnel, how many people need to install bitchat to ensure stable communication?

1 Like

好的,這是一個非常棒的應用題,直接切中了 bitchat 這類 Mesh 網路的實用性核心。

@suen 這個問題沒有一個絕對的數字答案,它更像是一個關於「網路密度」和「滲透理論 (Percolation Theory)」的現實模擬。我們可以分幾個層級來估算,以達到不同程度的「穩定」。

首先,我們必須定義幾個關鍵變數:

  1. 有效通訊距離: without_name 提到的非常對,藍牙的理論距離在現實中會大打折扣。在空曠地帶可能達到 50-80 米,但要穿過教學樓的鋼筋水泥牆壁,有效距離可能驟降至 10-20 米。這是我們估算時最重要的基礎。
  2. 使用者分佈: 2000+ 人員並非均勻分佈在 75 畝土地上,而是高度集中在教學樓、圖書館、宿舍、食堂等幾個核心區域。這既是優點(區域內密度高),也是挑戰(區域間可能存在通訊盲區)。
  3. 「穩定」的定義:
    • A 級穩定: 任意兩點間的訊息能「即時」或在數秒內送達。
    • B 級穩定: 訊息最終能夠送達,但可能需要幾分鐘甚至更長,依賴「儲存轉發 (Store & Forward)」機制,即靠移動中的人作為「信使」來傳遞。

估算模型

基於以上變數,我們可以推導出不同穩定度所需的安裝人數:

層級一:孤島通訊 (Island Communication) — 需要安裝率:5% ~ 10% (約 100 ~ 200 人)

  • 目標: 在單一高密度區域內(如一棟教學樓、圖書館、食堂)實現穩定通訊。
  • 分析: 在一棟樓裡,只要每個樓層、每個大教室裡有幾個用戶,他們就能形成一個局部的 Mesh 網路。100-200 人的安裝量,足以讓這些核心「島嶼」內部通訊變得非常流暢。但島嶼之間的連接會很脆弱,可能需要有人在島嶼之間移動才能傳遞訊息。
  • 結論: 這是網路能產生「初步效用」的門檻。大家可以在自己的系館或班級裡感受到它的用處。

層級二:校園漫遊 (Campus Roaming) — 需要安裝率:20% ~ 30% (約 400 ~ 600 人)

  • 目標: 實現全校範圍的 B 級穩定。訊息可以跨越建築物,在整個校園內傳播。
  • 分析: 這是網路效應的「引爆點」(Tipping Point)。當安裝人數達到這個規模,使用者密度足以在多數時間裡,於不同建築物之間形成「鏈路」。即使 A 樓和 B 樓之間沒有直接的藍牙鏈接,但總會有安裝了 App 的學生在兩樓之間的路徑上行走。依靠 Store & Forward 機制,訊息就能被這些移動節點「接力」送達。訊息延遲可能從幾十秒到幾分鐘不等,但網路基本實現了全校覆蓋。
  • 結論: 要達到您所說的「保障通信穩定」,我認為這是一個最現實、也最具代表性的目標數字。 在這個密度下,整個學校形成了一個動態的、有生命力的通訊網。

層級三:全域即時 (Fully Meshed & Real-time) — 需要安裝率:50%+ (約 1000+ 人)

  • 目標: 實現全校範圍的 A 級穩定。網路極度強韌,訊息傳遞接近即時。
  • 分析: 當超過一半的人都成為網路節點時,整個校園的藍牙 Mesh 網路密度會變得極高。任意兩點之間都可能存在多條可選路徑,網路具備了極強的容錯能力和自愈能力。即使某些節點離線,訊息也能立刻找到替代路徑。此時,通訊的體驗會非常接近於使用傳統的 IM,但它卻完全獨立於任何基礎設施。
  • 結論: 這是最理想的狀態,網路韌性最強,可以應對各種極端情況。

總結

對於「多少人安裝 bitchat 可以保障通信穩定?」這個問題,我的答案是:

最關鍵的門檻是達到 20%~30% 的安裝率,即 400 到 600 人。

一旦越過這個門檻,網路的價值將會指數級增長,從零散的「通訊孤島」質變為一個覆蓋全校的、可用的「去中心化通訊網」。這也完美地回應了 without_name 提出的關於距離和穩定度的擔憂——個體節點的不可靠,可以透過群體的密度來彌補。

1 Like

*北京市行政轄區總面積為16410平方公里,2024年年末全市常住人口2183.2万人,基於你數據中的設備數量,計算需要多少安裝數可以實現 A 級穩定

1 Like

@suen

好的,這是一個將問題從「校園級」提升到「都會級」的絕佳思考題!這能讓我們更深刻地理解藍牙 Mesh 網路的潛力與邊界。

直接回答:基於 bitchat 的現有技術架構,要在大都會如北京實現您定義的 A 級穩定(任意兩點間即時通訊)是幾乎不可能的

原因並不在於使用者數量,而在於物理定律和網路協議的雙重限制。讓我為您拆解:


1. 核心障礙:協議的「跳數限制 (Hop Limit)」

這是最根本的限制。bitchat 的技術白皮書中提到,其協議基於 TTL (Time-to-Live),最大支援 7 次跳轉

  • 單次跳轉距離: 我們用一個非常樂觀的城市環境估值,假設為 40 米
  • 最大通訊直徑: 7 跳 × 40 米/跳 = 280 米

這意味著,一個訊息最多只能傳播到約 280 米 遠的地方就會「壽終正寢」。它甚至無法穩定覆蓋一個大型購物中心,更不用說從海淀區即時傳到朝陽區了。這是架構上的天花板,再多的用戶也無法突破。

2. 物理障礙:都市的複雜性與密度不均

就算我們假設協議沒有跳數限制,要實現 A 級穩定,也需要形成一個「連續不斷的用戶之海」。

  • 面積與尺度: 北京市總面積 16,410 平方公里。這是一個巨大的尺度,中間包含了大量的「訊號真空地帶」,如山區、河流、高速公路、建築物內部(特別是地下室和高樓層)等。
  • 密度陷阱: 雖然全市常住人口 2183.2 萬,平均密度約 1330 人/平方公里,但分佈極不均勻。
    • 核心城區(如西城區): 人口密度超過 20,000 人/平方公里。
    • 遠郊區(如延慶、密雲): 人口密度可能低於 100 人/平方公里。

進行一個「理想化」的推算

現在,讓我們暫時忽略「7跳限制」,純粹從數學上計算需要多少用戶才能「鋪滿」北京,形成一個不中斷的網路。

  1. 建立連接所需密度: 為了在任何地方都能找到下一個節點,我們需要確保在一個半徑約 30-40 米的圓圈內,總有另一個使用者存在。這要求使用者密度達到一個很高的水準。一個簡化的模型估算,至少需要 每平方公里有 1000 名以上的「活躍使用者」 才能初步形成一個勉強連續的網路。

  2. 計算安裝率:

    • 在核心城區 (20,000人/km²):
      • 所需安裝率 = 1000 ÷ 20,000 = 5%
      • 這意味著在西單或國貿這樣的地方,只要有 5% 的人安裝並使用,就有可能形成一個局部的、即時的通訊孤島。
    • 在全市平均密度下 (1330人/km²):
      • 所需安裝率 = 1000 ÷ 1330 = 75%
      • 要求全市四分之三的人都安裝使用,這在現實中是不可能的。
    • 在遠郊區 (<100人/km²):
      • 安裝率需求超過 100%,物理上無法實現。

結論

bitchat 這類工具的價值模型,在都市尺度上發生了根本性的轉變:

  • 無法成為「全市通訊網」: 它無法取代傳統通訊方式,實現全城範圍的即時溝通。跳數限制和物理距離是無法逾越的鴻溝。
  • 價值回歸「超本地化通訊泡泡」: 它的真正威力在於,能在一個極小的、高密度的特定區域內,瞬間建立一個獨立、抗審查、無需網路的「通訊泡泡」。

例如:

  • 一場在天安門廣場的集會。
  • 一個在大型展覽館(如國家會議中心)內的團隊。
  • 一輛滿載乘客的地鐵車廂內。
  • 一個被物理或網路隔絕的社區。

在這些場景下,只要有幾十到幾百人安裝,就能形成一個極其有韌性的局部網路。但泡泡與泡泡之間,將是無法用「即時」訊息跨越的汪洋大海。要傳遞訊息,只能依靠 B 級穩定,即某人帶著手機從一個泡泡移動到另一個泡泡,完成「人肉Store & Forward」。

那計算 B 級穩定需要多少和分佈情況。

1 Like

好的,這是一個比計算 A 級穩定更有趣、也更貼近現實應用的問題。

@suen 對於像北京這樣的特大城市,**B 級穩定(Store & Forward 儲存轉發)的可行性,不再是一個純粹的密度問題,而是一個關於「人類流動性」和「關鍵節點滲透率」**的概率問題。

我們的目標不再是「鋪滿」整個城市,而是建立一個有效的「數位信使」網路。


B 級穩定的運作模型

  1. 通訊泡泡 (Communication Bubbles): 在人口高密度的區域(地鐵站、商圈、辦公大樓、大學城),用戶會自然形成許多個可以實現 A 級穩定(即時通訊)的「泡泡」。
  2. 移動節點 (Mobile Nodes / Couriers): 當一個安裝了 App 的用戶(信使)從 A 泡泡移動到 B 泡泡時,他們的手機就攜帶著 A 泡泡的訊息,並在進入 B 泡泡的通訊範圍後將其「釋放」出來。
  3. 穩定性的關鍵: B 級穩定性取決於**「任意兩個泡泡之間,存在信使往來的頻率和概率」**。

計算模型:分佈情況與所需數量

我們需要將北京分為三類區域來分析:

1. 核心「泡泡」區:高密度工作與生活區

  • 定義: 國貿CBD、中關村、西單、望京、金融街、各大學城等。
  • 目標: 在這些區域內部形成穩定的即時通訊網。
  • 所需安裝率: 根據之前的估算,只需要 5% 的區域內人口安裝即可。
  • 分析: 這些區域是資訊的「始發站」和「終點站」。必須先讓它們內部「活」起來,資訊才能被產生和接收。

2. 關鍵「走廊」區:主要交通動脈

  • 定義: 這是實現 B 級穩定的命脈,主要指地鐵系統主要公交線路
  • 目標: 確保有足夠多的「信使」在這些走廊上流動,連接各個「泡泡」。
  • 分析: 北京地鐵日均客流量高達千萬人次。這是一個無與倫比的「人肉傳輸帶」。
    • 場景模擬: 一條發自中關村(泡泡A)的訊息,需要被一個即將乘坐地鐵 10 號線前往國貿(泡泡B)的用戶「攜帶」。
    • 計算關鍵: 我們不需要整個車廂的人都安裝。我們只需要**「在一趟列車的有效通訊生命週期內(比如15分鐘),至少有一位信使上車或下車」**的概率足夠高。
    • 所需安裝率(在通勤者中): 我估計,只要通勤人群中有 1% - 2% 的安裝率,就能讓主要地鐵線路成為非常有效的資訊走廊。延遲時間取決於列車班次和信使密度,可能在 15 分鐘到 1 小時之間。

3. 廣泛「腹地」區:普通居住區與低密度區

  • 定義: 除了核心區和交通線之外的廣大區域。
  • 目標: 讓訊息有機會從「走廊」擴散到這些區域。
  • 分析: 這依賴於從交通節點回家的居民。只要居住區內有零星的幾個用戶,他們就能像蒲公英的種子一樣,將從「走廊」上攜帶回來的訊息在本小區內的小泡泡裡傳播開。這裡的安裝率要求可以更低,但會直接影響訊息傳遞的末端延遲。

綜合估算與結論

綜合以上分析,要實現覆蓋北京主要城區的 B 級穩定,我們需要的不是一個絕對的總人數,而是一個策略性的分佈

一個比較現實的估算是:

當全市安裝數達到 1% - 2%(約 20 萬至 40 萬人)且這些用戶主要集中在核心城區和主要交通動脈(特別是地鐵通勤族)上時,北京主要「通訊泡泡」之間的 B 級穩定 就開始具備實用價值。

分佈情況詳解:

  • 核心要求: 這 20-40 萬用戶不能是均勻分佈在 16410 平方公里上的,那樣會被稀釋得毫無意義。
  • 理想分佈: 他們應該高度集中在朝陽、海淀、西城、東城、豐台等核心城區。他們的主體是學生、科技業從業者和每日通勤的上班族
  • 效果預期:
    • 在這種分佈下,從海淀區發一條訊息到朝陽區,可能需要 30-60 分鐘。它會先在海淀區的某個泡泡裡傳播,被一位通勤者「捕獲」,隨著地鐵線路移動,最終在朝陽區的另一個泡泡裡被「釋放」。
    • 而要發往遠郊如密雲或延慶,則極度困難,可能需要數小時甚至數天的「信使接力」,成功率很低。

總結: B 級穩定將城市變為了一個基於人類活動規律的、非即時的、異步的巨大通訊網路。它不需要鋪滿每寸土地,只需要佔領關鍵的人流節點和通道。對北京而言,拿下地鐵系統的通勤人群,就等於掌握了 B 級穩定的命脈。

1 Like

Please check the maximum number of Bluetooth connections for a phone, and use the data you find to estimate if the behavior you mentioned above is feasible.

1 Like