0. Preface

Before filing this, I searched open and closed issues for these topics and didn't find existing reports covering the same combination. Apologies if any of this overlaps with something already tracked, feel free to close/merge if so. Thanks for the work in this release. The UI/UX is a lot better than earlier versions. Thanks in particular for the reworked geohash map, now a native animated 3D globe. Good addition, easier to use than the old flat view.

1. Environment

App: BitChat Android 2.0.1 Device: OnePlus Nord 5 OS: Android 16, OxygenOS 16

2. Issues

2.1 Geochat participant counter is unreliable Symptom: Displayed participant count for a geochat is inconsistent. Often shows "1" or no count at all, regardless of actual chat activity. The counter also changes on its own, without any visible connection/disconnection event tied to it. Assumption, not confirmed: could be a stale/cached subscription count from the relay, or a race condition between the UI layer and the peer-list update. No logcat to back this up yet, can provide if useful.

2.2 Notes on a geohash are not persisted Symptom: Notes attached to a specific geohash don't save. Not visible on the next visit to that geohash, at least on the originating device. Assumption, not confirmed: persisting a note might require acknowledgment/replication from more than one relay or device (not just a local write, but confirmation the note propagated beyond the originating device) before it counts as saved. If that's the intended design, it isn't communicated to the user anywhere right now, no in-app message, no docs, so from the user side it just looks broken. If this assumption is wrong and it's a plain persistence bug, disregard the caveat.

2.3 Suggestion: Tor routing should default to off, with support for user-configured bridges Context: in countries where Tor is blocked at the network/ISP level, Tor routing enabled by default can block the app from connecting at all, with no indication to the user why. Suggestion: Ship with Tor routing disabled by default (opt-in, not opt-out). Add a settings option for user-configured Tor bridges, so users who need Tor in a restrictive network can supply their own bridge lines and get it working, instead of being stuck with a default relay set that doesn't connect. This is a feature request more than a bug, including it here since it's tied to real-world usability of Tor routing as currently shipped.

2.4 Channels still leak content into the Mesh chat category Symptom: Channel chats aren't isolated from the Mesh chat category. Messages sent/received in a channel also show up under Mesh instead of staying scoped to the channel. Looks like channels and Mesh might be sharing a message stream or UI binding somewhere instead of being kept separate.

2.5 Relay send/sync logging is duplicated into the Mesh chat feed Symptom: Logging output for outgoing message delivery and relay sync shows up directly inside the Mesh chat feed, alongside actual chat content. Question: is this intentional (verbose/debug logging on by default in this build, or left on by accident), or a bug? If intentional, might be worth gating behind a debug flag instead of showing to all users by default, since it clutters the chat feed with non-chat content.

3. Closing

Thanks for reading through this, and for the continued work on the project. Can provide logcat output, screen recordings, or repro steps for any of the above if it helps.