Question 1

Why do only about half of Android DMs arrive on iOS after the iOS app restarts?

Accepted Answer

This is a timestamp lookback mismatch. Android randomizes NIP-17 seal and gift-wrap `created_at` values up to 48 hours in the past (`randomizeTimestampUpToPast = 172800` in `NostrCrypto.kt`), while iOS subscribes with a `since` value only 24 hours back (`nostrDMSubscribeLookbackSeconds = 86400` in `TransportConfig.swift`). Relays omit gift wraps older than the subscription's `since`, so a freshly launched iOS app receives roughly 50% of Android DMs; restarting resets the boundary and missed messages are not fetched later.

Preferred fix: change iOS to `nostrDMSubscribeLookbackSeconds = 172800`, recreate DM subscriptions, and ideally persist the last sync position or run a catch-up query on launch. Immediate Android-side compatibility workaround: reduce the randomization default from `172800` to `86400` seconds, though this weakens the NIP-17 timing obfuscation. Delivery acks, read receipts, and favorite notifications use the same envelope path and are affected too.

Also use relays that allow kind 1059 gift wraps, such as relay.damus.io, relay.primal.net, or offchain.pub; nostr21.com blocks kind 1059 and cannot deliver these DMs.

Question 2

How to fix unsigned Nostr geohash events (kind 20000/20001) being accepted and allowing pubkey impersonation?

Accepted Answer

Verify every incoming geohash event before processing or rendering it. In `GeohashMessageHandler.onEvent()` (`app/src/main/java/com/bitchat/android/nostr/GeohashMessageHandler.kt:44`), call `event.isValidSignature()` before caching nicknames, updating presence, or calling `messageManager.addChannelMessage()`. Add the same check to `NostrClient.handleGeohashMessage()` and `LocationNotesManager.handleEvent()`. Drop or reject the event if verification fails. Do not rely on PoW checks; PoW difficulty does not validate the Schnorr signature or event ID. Example guard: `if (!event.isValidSignature()) return`.

```kotlin
override fun onEvent(event: NostrEvent) {
    if (!event.isValidSignature()) {
        return // Drop forged or tampered event
    }
    // Existing geohash processing
}
```

This prevents a malicious or compromised relay from injecting kind 20000/20001 events with an arbitrary `pubkey`, nickname, sender ID, or content.

Question 3

How do I prevent Android Recents screenshots from retaining sensitive chat content after Panic Mode?

Accepted Answer

Set `FLAG_SECURE` on the main window so Android does not create App Switcher/Recents snapshots. In `MainActivity.kt`, add the flag in `onCreate` before `setContentView`:

```kotlin
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    window.addFlags(WindowManager.LayoutParams.FLAG_SECURE)
    setContentView(R.layout.activity_main)
}
```

Import `android.view.WindowManager` if needed. This also blocks ordinary user screenshots. If only chat or sensitive screens should be protected, add the flag when those screens are shown and remove it with `window.clearFlags(WindowManager.LayoutParams.FLAG_SECURE)` elsewhere. Clearing existing system snapshot caches from Panic Mode is generally not reliable without root access.

Question 4

How do I fix Nostr user blocking not working in geohash chatrooms?

Accepted Answer

Upgrade to the release that includes the fix for issue #641. The bug occurred because incoming Nostr public keys were compared against the block list with case-sensitive matching. Normalize public keys to lowercase before the block-list check, for example: `const normalizedPubkey = pubkey.toLowerCase();`. As a workaround, ensure both incoming keys and stored block-list entries are converted to lowercase before comparison.

bitchat-android

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects