Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

技術驗證：WebRTC 在沒有網際網路的現場傳離線包，用 QR 交換 SDP

Open
  • Is something wrong?
#553 5 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
28/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
javascript
Domain
mobile-dev, networking, testing-qa, web-dev

Research direction

Start by reading utils/qr-stream to understand the existing QR transport and run tools/test_leaks.mjs to confirm the privacy checks. Build the branch-only experiment page described in the issue, then test the stated device, browser, network, and file-size matrix while recording masked JSON measurements locally. Done means a completed matrix, conclusions against H1–H5, and a recommendation for or against a second phase.

Written by the indexing model from the issue text.

Description

enhancement

一份實驗設計，先量出可行性再決定要不要做成工具。目前不動任何已上線的東西。

背景

文件站的離線內容現在只能透過網路更新。裝置沒連過站台就完全拿不到，已經存過的裝置也要回到網路才更新得了。

不經網際網路的路盤過幾條。utils/qr-stream 每秒一到三 KB、工具上限 512 KB，傳幾 MB 的離線包不成立。隨身碟可行但需要線材與對方願意插。WebRTC 的 DataChannel 在同一個區網裡是每秒數 MB 的等級，代價是要先交換 SDP 與 ICE candidate，而那一步通常靠一台伺服器。

把那幾 KB 的交換交給現有的 QR 影格串流工具，整條路就不需要任何伺服器。這份實驗要回答的是它在真實現場的成功率。

要回答的問題

  1. 精簡後的 SDP 有多大，用現有的影格串流要幾張、幾秒
  2. 自己開熱點的情況下，5 MB 的傳輸成功率與耗時
  3. 哪些網路環境會整個失敗，失敗得快不快、訊息清不清楚
  4. 頁面完全從 Cache Storage 載入（真的斷網）時行為有沒有變
  5. iOS 加到主畫面的那種安裝形式，切到背景與鎖屏之後連線活不活得下來

判準

代號 假設 通過門檻
H1 只開 DataChannel 的 SDP 夠小 精簡後 <= 4 KB，「中」檔位 <= 15 張，握手 <= 30 秒
H2 自架熱點可用 5 MB 成功率 >= 90%（n >= 20），耗時中位數 <= 20 秒
H3 公共 Wi-Fi 會失敗 15 秒內判定失敗並給出可讀的原因
H4 離線不影響 頁面來自快取時 H2 的數字不變
H5 手機撐得住 掃完 QR 切到背景 30 秒再回來，連線存活或能自動重連

H3 預期失敗，量的是失敗的品質。轉圈三分鐘才說失敗的工具，在現場比直接說不支援更糟。

測試矩陣

維度 值
網路 自架熱點（Android 分享、iPhone 個人熱點、筆電熱點）、家用路由器、咖啡廳公共 Wi-Fi、有裝置隔離的訪客網路
裝置組合 Android 對筆電、iPhone 對筆電、Android 對 iPhone、筆電對筆電
瀏覽器 Chrome、Firefox、Safari。iOS 另外分「Safari 分頁」與「加到主畫面」
檔案大小 100 KB、1 MB、5 MB、20 MB
角色 誰當發起方對調各測一次

先跑自架熱點那一格，不通就不必往下。

量什麼

  • 握手：開始掃描到 datachannel open 的秒數、張數、重掃次數
  • 連線：getStats() 的候選類型（host、srflx、relay）與實際選中的 candidate pair
  • 傳輸：耗時、平均吞吐、SHA-256 比對，收到的檔案要跟來源逐位元組一致
  • 失敗分類：mDNS 解析不到、裝置隔離、權限被拒、SDP 掃不完、切背景斷線、其他
  • 中斷行為：傳到一半關螢幕、切換 App、走出範圍

每一次測量寫一列固定欄位的 JSON 存在本機，最後彙整成表。

實驗程式

一個不公開的實驗頁，放在分支上，不進 nav、不進 sitemap、不進預快取清單。

  • 只開 DataChannel，不要任何媒體軌，SDP 才會小
  • 不使用 STUN 與 TURN，實驗範圍限定在同一個區網
  • 等 ICE gathering 完成再產生 QR，避開 trickle 需要雙向持續通道的問題
  • 分塊 64 KB，靠 bufferedAmount 做背壓
  • 介面把每一個狀態顯示出來，失敗要說得出屬於哪一類

隱私

實驗頁不得送出任何資料，沿用 tools/test_leaks.mjs 那一組檢查。

getStats() 與 SDP 裡有本機位址與 mDNS 名稱，匯出的 JSON 要先遮罩。紀錄不寫地點也不寫參與者。實驗結束後這一頁不留在正式站上。

交付

  • 一張填滿的矩陣表，含成功率與耗時
  • 一段結論，這條路要不要併進離線內容的傳輸方式
  • 可行的話接第二階段的規格：SDP 精簡、分塊與續傳、簽章驗證擺在哪一步、介面怎麼說明失敗

不做的

  • 不做對外網路的 P2P，不碰 STUN、TURN 與 NAT 穿越
  • 不做一對多
  • 不取代 OnionShare，那是有網路時的選項

待查的技術問題

  • 只有 DataChannel 的 SDP 實際大小，以及還能刪掉哪些行
  • mDNS candidate 在各平台與各類網路的解析成功率
  • SCTP 的訊息大小上限與各瀏覽器的實作差異
  • iOS standalone 下的相機權限與背景行為
  • Firefox 與 Chrome 對 .local candidate 的處理差異

已知的外部限制

Tor Browser 把 WebRTC 整個關掉，utils/qr-stream 那一頁已經寫明這件事。公共 Wi-Fi 普遍開啟裝置隔離，而那正好是最需要這個功能的場合。

離線包本身的格式與簽章還沒開單，這一則只處理傳輸這一段。

Dominant language
JavaScript
Stars
52
Forks
7
Avg merge
1h 35m
Merged PRs (30d)
63

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from anoni-net/docs

All issues in anoni-net/docs

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.