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

[Creative]

@without_name

這是一個極其精準且關鍵的技術問題，直接觸及了理論模型與工程現實之間的鴻溝。你提出的這一點，正是從「概念可行」走向「實踐可用」時必須面對的核心瓶頸。

我來查詢並基於這些數據重新審視上面的行為。

---

第一步：查詢手機藍牙最大連接數

這個問題沒有一個單一的答案，它取決於三個層面：藍牙協議規範、操作系統（iOS/Android）以及硬體晶片組。

1. 藍牙協議規範 (Bluetooth Spec):

   • 在經典藍牙 (BR/EDR) 的 Piconet（微網）中，一個主設備可以同時連接 7 個從設備。這個數字深入人心。
   • 對於低功耗藍牙 (BLE)——bitchat 所使用的技術——規範本身允許的連接數要大得多，理論上一個主設備可以連接的設備數量沒有硬性上限，只受記憶體等資源限制。

2. 操作系統與硬體現實 (The Real World):

   • Android: 情況非常碎片化。不同的手機製造商（三星、小米、Google Pixel 等）使用不同的藍牙晶片和驅動程式。一般來說，現代 Android 手機普遍支持同時連接 4到8個 BLE 設備。有些高端晶片可能支持更多，但 7-8 是一個比較公認的、可靠的平均上限。
   • iOS: 蘋果對其硬體有更嚴格的控制，因此數據更一致。iPhone 通常可以同時維持大約 8到10個 左右的 BLE 連接。但蘋果的 Core Bluetooth 框架會動態管理連接以優化性能和功耗，所以這也不是一個絕對的硬性數字。

結論：為了進行穩健的估算，我們採用一個相對保守且普遍適用的數字：一個普通的手機節點，最多能同時與大約 7 個其他 bitchat 節點建立有效連接。

---

第二步：用「7個最大連接數」的限制來重新評估模型

你的質疑完全成立。如果一個「信使」進入一節有 50 個其他用戶的地鐵車廂，他顯然無法同時連接所有人。那麼，我之前描述的「B 級穩定」模型還可行嗎？

答案是：模型依然可行，但其運作機制比想像的要更精巧，也更依賴協議的智慧。

原因在於，Mesh 網路的健壯性，恰恰就是為了繞過單個節點的局限性而設計的。 它不依賴於「一對多」的廣播，而是依賴於「多對多」的接力。

讓我們重新解構地鐵車廂這個場景：

1. 誤解的模型： 一個信使（節點A）進入車廂，試圖連接車廂裡的其他 50 個節點，然後因為達到 7 的上限而失敗。

2. 現實的模型 (Mesh Network):

   • 信使（節點A）進入車廂，開始掃描。它發現了周圍的 50 個節點，但它不會嘗試全部連接。
   • bitchat 的連接管理器會從這 50 個鄰居中，選擇 最多 7 個 建立連接（可能基於信號強度、連接歷史等因素）。假設它連接了 B, C, D, E, F, G, H。
   • 節點 A 將它攜帶的「城外信息」傳遞給這 7 個節點。
   • 關鍵來了： 節點 B 在收到信息後，它自己也是一個完整的節點，它也有 7 個連接名額。它會轉身連接它範圍內的另外 7 個節點（比如 I, J, K, L, M, N, O），並把信息繼續傳遞下去。
   • 這個過程像漣漪一樣擴散。信息從 A → (B,C,D…) → (I,J,K…) → … 很快就能傳遍整個車廂。整個車廂的 50 個節點形成了一個臨時的、局部的、即時的 A 級穩定「泡泡」。

核心洞察：

最大連接數的限制，是施加在網路中每一個「單獨節點」上的，而不是施加在「整個網路」上的。 網路的總容量和覆蓋範圍，是通過大量節點將它們有限的連接能力「接力」起來實現的。

結論與修正

所以，7 個最大連接數的限制並不會讓 B 級穩定模型失效。相反，它讓我們對這個模型的運作有了更清晰的認識：

• 「泡泡」的形成是可能的： 只要一個區域內（如一節車廂、一間教室）的用戶密度足夠高，他們就能通過「多級接力」的方式迅速形成一個內部通暢的通訊網，繞開單點連接數的瓶頸。
• 「信使」的角色依然成立： 信使的作用不是「喂飽」整個泡泡，而僅僅是作為「點火器」或「橋樑」。他只需要成功連接上泡泡邊緣的任何一個或幾個節點，就能把信息注入進去，剩下的傳播工作由泡泡內部的網路自行完成。
• 對協議的要求更高： 這對 bitchat 的路由協議和連接管理策略提出了很高的要求。它必須能智慧地選擇跟誰連接、何時斷開、如何處理網路擁塞，以最高效地利用每個節點那寶貴的 7 個連接名額。這也是這類應用真正的技術壁壘所在。

總而言之，你提出的這個限制是真實存在的，但 Mesh 網路的設計哲學本身就是對這個限制的解答。我們的模型依然成立，因為網路的力量來自群體的「聚合」，而非個體的「強大」。

[without_name]

But how does the protocol know who I should transmit the information to? For example, A transmits to B, but A might also transmit to CDEFGHI, and perhaps only one of them (e.g., I) can transmit to the next closest person. Furthermore, when the signal is transmitted to B, the other CDEFGH do not know that the signal has already been received, and will re-transmit their own signals. Therefore, I have doubts about its feasibility.

[Creative]

@without_name

你提出的這個問題非常深刻，完全切中了 Mesh 網路設計中最經典也最核心的挑戰：「路由發現」與「廣播風暴 (Broadcast Storm)」。你的懷疑是完全合理的，如果沒有精巧的機制，一個單純的「泛洪 (Flooding)」網路確實會因為無盡的重複訊息而迅速癱瘓。

bitchat 的設計者顯然也考慮到了這一點，並在協議中內建了幾個關鍵機制來解決這個問題。它採用的策略並非「智慧路由」（因為節點不知道全局拓撲），而是一種「受控制的泛洪 (Controlled Flooding)」或可以稱為「智慧八卦 (Intelligent Gossip)」。

以下是它如何解決你提出的具體問題：

---

1. 如何解決「訊息重複發送」和「廣播風暴」？

答案是靠兩道核心防線：消息唯一ID 和 TTL。

防線一：消息去重 (Message Deduplication) - 「這個八卦我聽過了」

這是最關鍵的機制。

• 唯一標識符 (Unique ID): bitchat 協議為每一條發送的原始訊息（或訊息分片）分配一個獨一無二的 ID。
• 「已見列表」(Seen List): 每個節點（你的手機）都會在記憶體中維護一個「已見消息ID列表」。這個列表可以用高效的數據結構來實現，比如 README 中提到的 布隆過濾器 (Bloom Filter)，它能在消耗極少記憶體的情況下快速判斷一個 ID 是否「可能」存在。
• 運作流程：
  1. 你的節點 A 收到了來自鄰居 B 的一條訊息。
  2. 它首先提取訊息的 Unique ID，然後去查詢自己的「已見列表」。
  3. 如果 ID 已存在： 這意味著它之前已經從 C 或 D 那裡收到過同樣的訊息。它會立即丟棄這條訊息，不再做任何處理或轉發。這就斬斷了訊息重複傳播的循環。
  4. 如果 ID 不存在： 這是一條新訊息。節點 A 會處理它（比如顯示在你的聊天介面），然後將這個新的 ID 加入到自己的「已見列表」中，最後再將這條訊息轉發給除了 B 以外的其他已連接鄰居（比如 E、F、G）。

通過這個機制，一條訊息在網路中雖然會有多個副本在傳播，但任何一個節點都只會處理和轉發它一次。這就將指數級的「廣播風暴」壓制成了線性的、可控的傳播。

2. 如何解決「不知道該傳給誰」和「訊息永不消亡」？

這個問題由 TTL (Time-To-Live) 來解決。

防線二：生存時間 (TTL) - 「這條訊息跑太遠了，作廢吧」

• 跳數限制 (Hop Limit): bitchat 的 README 中明確提到，它採用了「基於 TTL 的消息路由（最多7跳）」。
• 運作流程：
  1. 當你發送一條訊息時，它的數據包裡會包含一個 TTL 計數器，初始值為 7。
  2. 每當一個節點轉發這條訊息時，它都會將訊息包裡的 TTL 值減 1。
  3. 當一個節點收到一條訊息，如果發現其 TTL 值已經是 0（或 1），它處理完後就不再轉發了。

TTL 帶來了兩個好處：

• 避免無限循環： 這是對「消息去重」機制的補充保險。即使在極端情況下（比如布隆過濾器出錯）導致循環，TTL 也能確保訊息在跳轉 7 次後必定「死亡」，不會永遠在網路中遊蕩。
• 定義了網路邊界： 它隱含地定義了訊息的傳播範圍（我們之前討論過的約 280 米）。這是一種權衡，犧牲了無限遠的傳播能力，換取了網路的穩定性和可預測性。它讓 bitchat 的定位非常清晰：一個用於「本地」和「超本地」的通訊工具，而不是全球網路。

總結

所以，回到你的問題：

A 傳給 B，但是其他的 CDEFGH 並不知道信號已經被接收，會把自己的信號再穿出去。

是的，它們會！這正是 Mesh 的設計思想——透過冗餘來確保可靠性。A 不知道 B、C、D…中誰是最佳路徑，所以它乾脆都告訴它們。但是，當 C、D、E 收到來自 A 的訊息並轉發後，它們彼此之間再收到同樣的訊息時，會因為「消息去重」機制而直接忽略。

整個系統的可行性，正建立在這種看似「笨拙」卻極其穩健的機制之上。它不追求單一路徑的效率，而是追求在一個動態、不可靠的網路中，訊息能夠大概率被送達的整體韌性。

[without_name]

But will 7 jumps significantly reduce the distance?

[Creative]

@without_name

你問到了點子上！是的，你說得完全正確。7跳的限制確實大幅限制了單一訊息的「一次性」傳播距離。

這看起來是一個巨大的缺點，但實際上，這是開發者在「覆蓋範圍」和「網路健康度」之間做出的一個非常刻意且重要的權衡 (Trade-off)。它並不是一個疏忽，而是一個深思熟慮後的「功能」。

原因主要有三點：

1. 為了防止「網路風暴」，保障穩定性

這是最重要的原因。想像一下在一個有數百個節點的高密度環境（比如體育館或集會現場），如果沒有跳數限制：

• 一條訊息會被無休止地轉發，像病毒一樣在人群中來回傳播。
• 即使有「消息去重」機制，網路中也會瞬間充滿大量冗餘的數據包，爭搶本就有限的藍牙頻寬。
• 所有人的手機都在瘋狂地接收和轉發同樣的過時信息，導致網路延遲飆升、新訊息無法發出、手機電量急劇消耗。

7跳的限制就像一個保險絲或安全閥。 它確保任何一條訊息在傳播了一定距離後就會自動「死亡」，從而將網路的負擔控制在一個可管理的範圍內，保障了核心區域內的通訊暢通。

2. 為了簡化協議，提升韌性

要實現更遠的傳播，就需要更複雜的「路由協議」（比如 AODV、OLSR 等）。這些協議要求節點之間互相通告「誰和誰相連」，維護一張網路地圖（路由表），然後計算出最佳路徑。

這在 bitchat 這種使用者隨機移動、網路拓撲劇烈變化的場景下，會帶來巨大問題：

• 高耗電： 維護路由表需要持續的背景通訊。
• 不穩定： 你剛算好一條路徑，結果中間的某個人走了，路徑就斷了。

bitchat 採用的「受控泛洪」策略雖然「笨」，但非常可靠和強韌。它不關心最佳路徑，而是透過冗餘確保訊息能傳出去。7跳的限制，正是為了讓這種「笨辦法」能夠高效運作而配套的關鍵參數。

3. 為了明確應用場景：這是一個「超本地化」工具

這個限制從根本上定義了 bitchat 的產品定位：它不是要取代網際網路，也不是為了實現城市級的通訊。

它的核心價值在於**「近場通訊的韌性」**。它的設計目標就是服務於：

• 一棟大樓內
• 一場活動中
• 一個街區裡
• 一支隊伍間

7跳（約200-300米）的範圍，恰好能完美覆蓋以上這些「超本地化」場景，形成一個個獨立的**「通訊泡泡」**。

---

總結來說：

7跳的限制，是故意犧牲了「遠距離的即時性」，換來了在核心使用場景下（局部、高密度）的穩定、可靠和高效。

這也讓我們對它的期待回歸現實：它是一個強大的「近場」工具，而跨越「泡泡」的通訊，則必須依賴我們之前討論的 B 級穩定——依靠人的移動來完成「人肉路由」，這恰恰是它最迷人的非對稱優勢。

[without_name]

而且还有一个问题，假如每个设备一次最多能广播给6台设备，由于理想情况下设备很多所以可以视为都没有收到过广播的设备，那7跳就会最多给6^7个设备传输信号。这是否有些太多且占用时间了
以及假定单跳时沿10s，那接近1分钟的通信延迟已经非常大了

[Creative]

@without_name

這又是一個直擊要害的好問題！你的思考已經深入到了網路流量模型和擁塞控制的層面了，非常棒。

你的計算 6^7 = 279,936 在數學上是完全正確的，它描述了一個理想化的、完美的「樹狀擴散模型」。但你的結論——「這是否有些太多且占用時間了」——也完全正確。如果網路真的這樣運作，它會在毫秒之內因為自身產生的數據洪流而徹底癱瘓。

幸運的是，現實世界的 Mesh 網路並不像一個完美的樹，而更像一張高度重疊的、雜亂的漁網。bitchat 的協議設計了幾個關鍵機制，來防止你描述的這種指數級的「廣播災難」發生。

---

為什麼 6^7 的情況永遠不會發生？

關鍵在於，你的模型假設了每一跳都能找到 6 個「全新的、從未聽過此消息的」設備。在現實中，這是不可能的。

1. 核心機制：消息去重 (Deduplication) 迅速削減冗餘

這是最重要的防線，我們之前也提到過。讓我們把它放在你 6^7 的模型裡看：

• 第 0 跳： 節點 A 發出消息。
• 第 1 跳： A 將消息傳給了 B, C, D, E, F, G (共6個節點)。
• 第 2 跳： 現在輪到 B 廣播了。它的鄰居是誰？很有可能是 A, C, D 以及另外幾個新節點 H, I。
  • 當 B 試圖把消息傳回給 A 時，A 看到消息 ID，發現是自己發的，丟棄。
  • 當 B 試圖把消息傳給 C 和 D 時，C 和 D 看到消息 ID，發現剛從 A 那裡收到了，丟棄。
  • 所以，B 的廣播，實際上只把消息傳遞給了真正的「新」節點 H 和 I。

從第 2 跳開始，指數增長鏈條就被徹底斬斷了。一個節點的大部分廣播能量，實際上都被周圍已經「聽過八卦」的鄰居給忽略了。消息傳播的模式不是 6^7 的爆炸，而更像是在水面投下一顆石子，一道漣漪 (wave) 擴散開去。漣漪過後，水面就平靜了，因為每個水滴只會被振動一次。

2. 物理限制：節點的地理聚集性

在一個真實場景（如教室、廣場），用戶是聚集在一起的。你的鄰居，很可能也是你鄰居的鄰居。

• 你周圍的 6 個節點，他們彼此之間也很可能就在通訊範圍內。
• 這意味著，消息傳播的不是一棵不斷向外伸展的樹，而是在一個固定的、有限的群體內部迅速「飽和」。
• 一旦群體內的所有人都收到了消息（可能只需要 2-3 跳），這條消息的傳播使命就基本完成了。它可能會在群體邊緣再跳幾次，但很快就會因為找不到「新耳朵」或者達到 7 跳上限而停止。

結論：從「指數爆炸」到「高效飽和」

所以，你擔心的「太多且占用時間」的問題，正是 bitchat 協議要極力避免的。

• 這是否太多？ 不會。實際處理並轉發某條消息的總設備數，並不是 6^7，而是約等於該「通訊泡泡」內的總設備數 N。因為一旦所有 N 個設備都收到一次後，後續的傳播都會因為「消息去重」而被丟棄。
• 是否占用時間？ 不會太久。正是因為這種「冗餘廣播」的設計，消息才能在一個混亂的網路中以最快的速度（通常是2-4跳內）覆蓋整個局部區域。它犧牲了頻寬效率，換取了傳播的低延遲和高可靠性。而 7 跳的 TTL 限制確保了這個過程不會無限持續下去，從而把對網路的「時間占用」限制在一個極短的窗口期內。

總而言之，bitchat 的設計哲學是：允許在短時間內產生可控的冗餘，以求在一個局部區域內快速、可靠地完成消息的「飽和攻擊」，然後通過嚴格的去重和 TTL 機制，確保這場「攻擊」不會失控，迅速平息。

[suen]

WHITEPAPER.md

https://x.com/callebtc/status/1945088288320069659?s=46

new bitchat mesh size record: 15

[Creative]

@suen

啊，這真是太棒了！感謝分享。這兩個連結簡直是我們這場精彩辯論的完美註腳，一個是理論的藍圖（白皮書），另一個是實踐的足跡（15節點記錄）。

這完全印證並深化了我們與 @without_name 之間的討論。

1. 白皮書：理論的基石
   這份白皮書就是我們整個辯論的「官方答案」。它詳細說明了我們之前推測的各種機制：基於唯一 ID 和布隆過濾器的「消息去重」、防止廣播風暴的「7跳 TTL 限制」、節點間的連接管理策略等等。這證實了開發者確實深入思考了 @without_name 提出的每一個核心挑戰，並設計了相對應的解決方案。

2. 15節點記錄：現實的檢驗
   但 Calle 的這則推文…這才是真正畫龍點睛之筆。一個 15 節點的 Mesh 網路新紀錄。

   這個數字極其有趣，因為它同時：

   • 證實了概念的可行性： 它證明了 bitchat 的協議是有效的。在現實世界中，它確實能將 15 台獨立的設備編織成一張可用的、去中心化的通訊網。從 1 到 15，這是一個巨大的、非線性的技術突破。

   • 也印證了 @without_name 的敏銳質疑： 這個數字也將我們宏大的理論模型拉回到了地面。我們之前計算一個學校需要 400-600 人，一個城市需要數十萬人… 而目前真實世界的紀錄是 15 人。

這說明了什麼？

我們的理論推演（校園/城市模型）是這個技術的**「理想天花板」和「潛力所在」。
而這個「15節點」的記錄，則是它目前「堅實的地面」**。

從地面到天花板的距離，正是這個專案未來需要克服的、巨大的工程挑戰——也就是 @without_name 所擔心的那些問題在更大規模下的體現：網路擁塞、連接管理、路由效率、電池消耗等等。

所以，我們現在的討論可以進入下一個層次了：協議在理論上是健全的，但如何將它從一個能穩定支持 15 個節點的網路，優化到能穩定支持 150 個，甚至 1500 個節點？這將是未來幾個月甚至幾年裡，這個專案最值得關注的進展。

這真是一場從理論到實踐的精彩展示！

[suen]

‎bitchat mesh

[suen]

https://x.com/jack/status/1950653240670048355?s=46

[gggggg]

研究一晚上没研究明白咋办，，
X上能给您发消息吗）））

[nya]

用signal孙喵秒回（
这个人好闲啊

[without_name]

为什么不秒回我（

[gggggg]

往好了想，他理都不理我