bitchat terminal!

[jackjackbits]

https://x.com/shilohsecurity/status/1944639798775271752
https://github.com/ShilohEye/bitchat-terminal

[ingFavot]

Egregius Jack, first of all, sincere congratulations on your persistence and on the noble goal of turning BitChat from a “week-end project” into a concrete, production-ready service: bringing order to the natural disorder of a multihop mesh is a fascinating challenge.
Back in 2015—in Italy and with zero budget—we built the pioneering project NextVoix. Very soon we had to face the same dilemma: should we publish the entire routing framework, or keep a hardened core (firmware + key-schedule) and expose only open APIs? After many long nights we realised that security is not just cryptography, but also the size of the observation surface.

Threat model – ad-hoc mesh between devices

• Traffic correlation & fingerprinting** – an attacker controlling several hops (or armed with good BLE/Wi-Fi sniffers) can correlate packet size + timing to recover sender/receiver pairs, even with Noise E2E, especially when the full source code is public.
• RF side-channels** – BLE advertising frames and Wi-Fi Direct beacons leak Access Address, capability sets and RSSI, enabling node fingerprinting even with MAC randomisation.
• Active multi-channel MitM** – an adversary can replay or mutate encrypted frames before upper layers notice.
• Edge-case Noise pitfalls** – nonce wrap or error handling bugs may lead to key/nonce reuse or DoS.
• Store-and-forward poisoning** – a malicious relay can drop, reorder or inject ciphertext to distort conversation graphs.
  (…and those are only the most obvious vectors.)

Why consider “open APIs • secure core”

• Fully open code speeds audits, but also hands attackers a perfect blueprint; in a mesh the weakest link is often the node doing the routing. :contentReference[oaicite:6]{index=6}
• A signed, closed core slows reverse-engineering (diffing binaries ≠ diffing Git commits).
• Public APIs stay free, extensible and third-party-testable without exposing the key-schedule or RF handling.
  In the year '15/16 we think to adopted this hybrid approach with NextVoix; the videos on the site still show the results. With today’s AI tooling we can push much further—yet Bitcoin or other crypto integration will make operational privacy even more critical, as scams evolve just as fast as code.
  Thank you for reigniting the discussion; the surge of interest proves how alive the need for free and truly private communication on a self-owned network still is, especially for safety and disaster scenarios. Go BitChat!
  regards and full support,
  Roberto

[DolphinOutlaw69]

AI slop reply.

[cmosetick]

https://x.com/shilohsecurity/status/1944639798775271752
https://github.com/ShilohEye/bitchat-terminal

@jackjackbits Thanks for mentioning that terminal project.

I just tested and commented on the Dockerfile PR 2 from that GH repo on a Intel-64 Linux system.

Looks good to me right now, for anyone that wants to merge that PR:

• Add Dockerfile and instructions for running bitchat-terminal with Docker ShilohEye/bitchat-terminal#2 (comment)

• https://x.com/cmosetick/status/1945789848578625888