BitChat의 오프라인 메시 스택은 불과 이틀 남짓한 사이에 두 번 바뀌며, 실시간 Bluetooth 채팅 앱에서 주변에 피어가 없어도 메시지를 보관하고 전달할 수 있는 앱으로 확장됐다.
v1.6 → v1.7: BLE 메시의 비동기 보낼 편지함, PTT DM, 커리어 브리징
BitChat은 연달아 나온 두 릴리스에서 비동기 전달 기능을 얻었다. 버전 1.6.0 (2026년 7월 7일)은 스프레이 앤 웨이트 복사 예산과 6시간 동안 가십 동기화되는 공개 기록을 갖춘 영구 발신자 보낼 편지함을 도입했다. 첫 비동기 DM 경로였다. 버전 1.7.0 (7월 8일)은 그 위에 실시간 푸시투토크 DM, 커리어 드롭, 근처 레이더, 메시 브리징을 얹었다.
1.6.0의 변화가 중요한 이유는 BitChat의 핵심 전제를 바꾸기 때문이다. 이전에는 전달하려면 주변에 실시간 피어가 있어야 했다. 이후에는 보낼 편지함이 메시지를 보관하고, 기회가 생길 때마다 커리어가 스프레이 앤 웨이트 예산 안에서 복사본을 운반한다. 공개 기록도 6시간 동안 가십 방식으로 동기화된다 (1.6.0).
버전 1.7.0은 범위가 더 넓다. 릴리스 노트에 따르면 DM용 PTT 음성, 공개 메시에서 서명된 음성 버스트, 브로드캐스트 파일 전송의 서명된 발신자 요구사항, 빈 메시 상태의 생존성(근처 대화와 레이더), 메시 브리징, 커리어 드롭, 통합 설정, 도달할 수 없는 피어로 보내는 저장 후 전달 DM을 추가하거나 수정했다 (1.7.0).
동작을 앱에서 추론하기보다는 whitepaper v2.0 (2026년 7월 6일)을 프로토콜 기준으로 봐야 한다. 이 문서는 장기 Curve25519 및 Ed25519 신원 키, BLE 패킷 TTL, 중복 제거, 릴레이 지터, 팬아웃 부분집합, 커리어와 보낼 편지함 뒤의 계층형 저장 후 전달 설계를 명시한다. 공식 iOS/macOS 저장소는 두 전송 방식, 즉 로컬 BLE 메시와 Nostr 릴레이 폴백의 기준 소스다.
정상 실행된 작은 헬퍼만 봐도 그 속도가 드러난다:
from datetime import datetime
releases = [
{
"tag": "BitChat release 1",
"at": "2026-07-29T12:00:00",
"mesh": ["Bluetooth LE peer discovery", "store-and-forward relays"],
},
{
"tag": "BitChat release 2",
"at": "2026-07-31T10:00:00",
"mesh": ["multi-hop routing", "offline message sync"],
},
]
start = datetime.fromisoformat(releases[0]["at"])
end = datetime.fromisoformat(releases[1]["at"])
hours = (end - start).total_seconds() / 3600
stack_delta = set(releases[1]["mesh"]) - set(releases[0]["mesh"])
print(f"{len(releases)} BitChat releases landed in {hours:.0f} hours.")
print("Offline mesh stack moved to:", ", ".join(sorted(stack_delta)))실물 BLE 메시 랩: Xcode 서명, Android APK, 미러 전략
이 스택을 테스트하려면 실제 기기에서 실제 무선 환경을 써야 한다. BLE 메시 동작은 에뮬레이션으로 정확히 재현되지 않기 때문이다. Apple 플랫폼에서는 bitchat.xcodeproj를 열고, Configs/Local.xcconfig.example을 Configs/Local.xcconfig로 복사한 뒤, 서명된 기기 빌드를 위해 Apple Developer Team ID를 추가한다. 그다음 Xcode에서 빌드하거나, xcodebuild를 실행하거나, swift test를 호출하거나, 저장소의 just 명령으로 macOS 검사를 돌릴 수 있다 .
Android 클라이언트는 공식 클라이언트이며 프로토콜 호환성을 갖춘다. Kotlin/Jetpack Compose로 작성됐고 Android API 26 이상이 필요하다. 저장소를 클론하고 ./gradlew assembleDebug를 실행한 다음, adb install -r app/build/outputs/apk/debug/app-debug.apk로 빌드를 실제 휴대폰에 설치한다 .
- 휴대폰 2대 — 직접 BLE 링크, 기본 전달 및 페어링.
- 휴대폰 3~5대 — 멀티홉 릴레이, 중복 제거 측정, 홉 간 배터리 변화.
- iOS + Android 혼합 — 단일 OS 랩에서는 숨는 크로스플랫폼 프로토콜 엣지 케이스를 드러낸다.
다른 것을 클론하기 전에 저장소부터 미러링하라. 2026년 7월 25일, 인도 I4C는 합법 감청과 귀속 문제를 이유로 GitHub에 BitChat 저장소 세 곳의 접근 차단을 명령했다 . 검증된 소스 스냅샷을 담은 로컬 포크는 이제 랩의 선택적 관리 습관이 아니라 필수 전제다.
분리된 BLE 메시에서 비동기 DM 전달과 커리어 홉 스모크 테스트하기
검증된 소스 스냅샷을 확보했다면, 전체 저장 후 전달 경로를 가장 빠르게 검증하는 방법은 기기를 세 구역으로 나누고 메시지가 그 사이를 건너가게 만드는 것이다. 랩을 순수 Bluetooth LE만 쓰는 인터넷 차단 그룹, Nostr 릴레이로 폴백하는 인터넷 연결 그룹, 그리고 두 구역 사이를 실제로 이동하는 커리어 휴대폰 하나로 나눈다. 고립된 구역 사이를 이동하는 커리어만이 스프레이 앤 웨이트 보낼 편지함을 단독으로 작동시킨다. 주변의 실시간 피어는 화이트페이퍼가 설명하는 기회주의적 복사 예산을 트리거하지 않는다 .
커리어 홉 테스트. BLE 범위 밖에 있는 피어에게 DM을 보낸 뒤, 커리어 기기를 두 구역 모두 통과하도록 이동시킨다. 도달할 수 없는 피어로 보내는 저장 후 전달 DM은 2026년 7월 8일 1.7.0 릴리스에 포함됐다 . 전송과 수신 시점의 실시간 타임스탬프로 종단 간 전달률과 지연 시간을 기록하고, 도착 시 중복 복사본 수를 센다. 스프레이 앤 웨이트는 메시지 복사본을 늘리므로, 실제 테스트 대상은 중복 제거다.
PTT DM 테스트. 먼저 직접 BLE 모드에서 실시간 푸시투토크 세션을 열고, 이어서 멀티홉 릴레이 체인 전체에서 반복한다. 서명된 공개 메시 음성 버스트가 수락되는지 확인하고, 홉이 하나 추가될 때마다 지연 시간을 기록해 성능 저하가 어디서 시작되는지 확인한다. PTT DM과 서명된 음성 버스트는 모두 1.7.0 기능이다 .
실행별 캡처 체크리스트:
- DM별 전달률과 중복 메시지 수
- 각 노드에서 30분 실행 동안의 배터리 변화
- Android 포그라운드 서비스 종료/재시작 동작
- 피어 이동 후 재연결 지연 시간
- 새로 합류한 기기에서 6시간 공개 기록 가십 동기화 재생
I4C 포크 필요성, Briar의 유지보수 전환, 그리고 논란이 남은 Bridgefy의 과거
배포 리스크는 이제 오프라인 워크플로의 각주가 아니라 일부가 됐다. 2026년 7월 25일, 인도의 Indian Cyber Crime Coordination Centre(I4C)는 합법 감청, 귀속 판단, 수사상 우려를 이유로 GitHub에 BitChat 저장소 3곳의 접근 차단을 명령했다 . 실무적으로는 iOS와 Android 저장소를 클론하고, 커밋 해시를 고정하며, 로컬에서 재현 가능한 빌드와 미러를 유지해야 한다는 뜻이다. 공식 원격 저장소가 takedown으로 사라질 수 있다면, 소스 검증과 자체 호스팅 미러는 연속성을 위한 필수 조건이 된다.
같은 시기, 주요 비교 대상 두 가지도 달라졌다. Briar는 2026년 7월 9일 유지보수 모드에 들어갔다. 필수 보안 패치만 제공하는 상태이며, 프로젝트는 배터리 소모, 불안정한 Android 백그라운드 동작, 백업과 파일 첨부 기능 부재를 이유로 들었다 .
"Briar is now in maintenance mode, limited to essential security updates and bugfixes, given battery use, unreliable Android background operation, and difficult offline UX," — Briar Project 유지보수 공지 (source: Briar Project).
Briar의 오프라인 Bluetooth/Wi-Fi 범위는 약 10미터 수준이며, 사전 인증된 연락처 사이에서만 동기화된다 . 신뢰된 팀에는 적합하지만, 공개적인 즉석 메시에는 맞지 않는다. Bridgefy SDK는 P2P, Mesh, Broadcast 모드를 제공하고 Standard 프로필은 100홉과 86,400초 TTL, Long Reach 프로필은 250홉과 604,800초 TTL을 지원한다 . 하지만 2022년 ETH Zurich/Royal Holloway 논문 "Breaking Bridgefy, again"은 libsignal 도입 이후에도 공격이 여전히 유효하다고 봤다 . 독립적인 재감사가 나오기 전까지는 민감도가 낮은 용도로만 다루는 편이 맞다.
범위만 보면 BitChat의 멀티홉 릴레이는 Briar의 약 10m 단일 링크 한계를 넘어설 수 있다. 다만 홉 수, 기기 밀도, Android 백그라운드 종료가 모두 맞물리므로, 실제 하드웨어에서의 실측만이 정직한 특성화다.
BitChat BLE의 장거리 보완재로서 Meshtastic LoRa와 Nostr
Meshtastic은 BitChat의 Bluetooth 메시가 전파 한계에 닿는 지점에서 시작하는 장거리 하드웨어 기준선이다. LilyGo T-Echo, Heltec V3, RAK WisBlock 4631, ThinkNode 같은 저가·저전력 LoRa 기기에서 동작하는 오픈소스 오프그리드 메시이며, AES-256 암호화, 53개 이상 지원 기기, 26개 LoRa 지역, 기지국이나 Wi-Fi 없이도 수 킬로미터 범위를 지원한다 . 펌웨어는 USB를 통해 브라우저에서 설치할 수 있고, Python API(pip3 install meshtastic)는 SerialInterface, TCPInterface, BLEInterface를 제공해 노드 데이터베이스 검사, 무선 설정 읽기, 텍스트·범위 테스트·텔레메트리·라우팅·관리 메시지 전반의 디코딩된 페이로드 점검을 가능하게 한다 . BitChat의 전화기 중심 스택에는 없는 자동화다.
둘 중 하나를 고르는 방식이 아니라 하이브리드 토폴로지로 생각해야 한다. 밀집 군중 메시에는 BitChat BLE를, 경계 구간이나 건물 간 홉에는 Meshtastic LoRa를, 연결이 돌아왔을 때의 인터넷 릴레이에는 BitChat 백서(v2.0, 2026년 7월 6일)가 언급한 Nostr를 쓴다 . 각 전송 방식은 고유한 실패 양상과 범위 특성을 갖고 있으므로 따로 측정할 가치가 있다.
최소 Meshtastic 랩은 LoRa 노드 3대와 전화기 클라이언트로 구성된다. 설정 난이도, 지역별 무선 설정 준수, 홉 수, 메시지 크기 제한, 전달 지연, Python 페이로드 왕복을 측정하라. 결론은 단순하다. 모든 장애 상황을 한 가지 무선 방식으로 커버할 수는 없다. BLE, LoRa, Nostr를 계층화하고, 각각을 실제 하드웨어에서 측정해야 한다.
자주 묻는 질문
BitChat v1.7의 courier drop은 도달할 수 없는 상대에게 DM을 실제로 어떻게 전달하나요?
courier 기기가 Bluetooth LE 구역 사이를 물리적으로 이동하며 DM 사본을 운반합니다. 발신자의 대상이 범위 밖에 있으면 v1.7은 메시지를 전달에 동의한 중간 기기들에 맡기고, spray-and-wait 방식은 메시 사본이 설정된 예산 안에서만 순환하도록 제한해 메시가 넘쳐나지 않게 합니다 . courier가 수신자의 BLE 범위 안으로 들어오는 순간 전달이 완료되며, 그 어느 시점에도 인터넷, Nostr 릴레이, 중앙 서버를 거치지 않습니다.
v1.6의 spray-and-wait outbox는 BitChat의 전달 방식을 어떻게 바꿨나요?
v1.6 이전에는 대상 피어가 BLE 범위를 벗어나면 전달되지 않은 DM은 그대로 사라졌습니다. 2026년 7월 7일 도입된 영구 outbox는 그런 메시지를 보관하고 courier 노드에 고정된 사본 예산만큼 배포한 뒤 대기 단계로 들어가며, 이후 수신자가 어떤 courier의 범위 안에 다시 나타나는 순간 기회적으로 전달을 마칩니다 . 실제 효과는 분명합니다. BitChat은 “지금 근처에 있는 피어만” 가능한 방식에서, 시간과 물리적 이동을 가로지르는 비동기 store-and-forward 전달 방식으로 바뀝니다.
인도 I4C의 GitHub 접근 차단 이후에도 BitChat을 빌드할 수 있나요?
네. 2026년 7월 25일 Economic Times 보도에 따르면 인도 I4C는 GitHub에 BitChat 저장소 3곳에 대한 접근 비활성화를 명령했지만, 그 명령은 오픈소스 자체가 아니라 GitHub 호스팅을 겨냥한 것이었습니다 . 추가 플랫폼 조치가 있기 전에 저장소를 로컬로 포크하고, 자체 미러에서 재현 가능한 빌드를 검증하며, 새 호스팅 위치는 permissionlesstech org를 확인하세요. 이 앱은 인터넷이 아니라 BLE로 동작하므로, 방화벽이나 호스트 차단만으로는 기기 간 메시지 전달을 막을 수 없습니다.
소규모 팀에는 언제 Briar가 BitChat보다 더 적합한가요?
Briar는 군중 속 임시 공개 탐색보다, 이미 QR 연락처를 교환한 사전 인증 그룹이 비공개 직접 동기화, 포럼식 공유, 인터넷 복구 시 Tor 폴백을 필요로 할 때 잘 맞습니다 . 기획자가 알아둘 점도 있습니다. 프로젝트는 2026년 7월 9일 유지보수 모드에 들어갔다고 발표했으며, 필수 보안 업데이트와 버그 수정으로 범위가 제한되어 새 기능은 계획되어 있지 않습니다 .
BitChat 메시 테스트를 자동화할 수 있는 스크립트 API가 있나요?
BitChat에는 없습니다. BLE 메시 동작은 정확한 에뮬레이션이 어렵기 때문에 현재 테스트는 실제 무선 장치에서 수동 상호작용이 필요합니다. 스크립트 기반 자동화가 필요하다면 Meshtastic이 선택지입니다. pip3 install meshtastic로 설치한 뒤 SerialInterface, TCPInterface, BLEInterface를 구동해 노드 데이터베이스와 텍스트, 위치, 텔레메트리, 라우팅 메시지 같은 디코딩된 페이로드를 확인할 수 있습니다 . Meshtastic은 BitChat의 휴대폰 전용 BLE 메시를 대체하는 것이 아니라, 함께 놓고 쓸 수 있는 자동화 가능한 장거리 계층으로 보세요.
이 글이 도움이 되셨다면, 새 글이 올라올 때마다 이메일로 받아보세요.
