mirror of
https://github.com/permissionlesstech/bitchat.git
synced 2026-10-18 07:33:46 +00:00
2d652fa77f
The vendored arti is built with `default-features = false` and `["tokio", "rustls"]` — no `pt-client`, no `bridge-client` — and `arti-bitchat/src/lib.rs` bootstraps stock config with no bridge lines. docs/TOR-INTEGRATION.md has said so since the integration landed. Nothing in the app says it. The settings toggle reads "sends internet traffic through tor, so relay operators see tor's address instead of yours [...] recommended: on", and the only caption underneath appears when tor is *off*. So the screen is candid about the cost of switching tor off and silent about the cost of leaving it on: a direct connection to the public tor network is recognisable as tor to anyone inspecting the traffic. Where using tor is itself the risk — the case that motivates bridges existing at all — "recommended: on" is advice the app cannot back up, and the person acting on it has no way to know. Add the missing half as a caption shown while tor is on, in the app's own voice and in all 30 catalog locales. Deliberately not red: this is a standing limitation of the feature as shipped, not a fault condition. This does not close #1549. Real circumvention needs the pluggable- transport features enabled, bridge configuration plumbed through an FFI that currently exports seven functions and none of them take config, and the xcframework rebuilt under the pinned toolchain with a provenance manifest update — a build-side change this cannot substitute for. It closes the disclosure gap in the meantime, which is the part that costs nothing to fix and that someone in Iran or China needs today. Refs #1549