QOL features on chat

[abh3po]

• Add Reactions
• Slide To reply
• Removed flyerhq chat

[abh3po]

Closes #574

[forge0x]

🧪 Test Results — PR #579 QOL Chat Features

Tested on: iPhone 17 Pro (iOS 26.x), Android emulator (Pixel 9 Pro API 35)
Branch: prettify-chat
Tester: @bobodread

---

❌ Bug 1 — Reaction emojis render as question mark boxes

Symptom: Opening the reaction picker shows replacement characters (□ / ?) instead of emoji glyphs on Android.

Root cause: ReactionPicker.tsx renders emoji via a plain <Text> component with no explicit font family. On Android, emoji rendering requires the NotoColorEmoji font or a fontFamily: undefined reset — if the parent component sets any custom font (which most Flash UI components do via the Karla/IBM Plex Mono theme), emoji glyphs get swapped to the replacement character.

Fix: Add fontFamily: undefined or fontFamily: "" explicitly to the styles.emoji rule in ReactionPicker.tsx:

emoji: {
  fontSize: 24,
  fontFamily: undefined, // allow OS to resolve emoji font on Android
},

Same fix likely needed in MessageBubble.tsx wherever reaction badges are rendered.

---

❌ Bug 2 — USER PROFILE IS null loop blocks message sending

Symptom: Repeated log output on every send attempt:

(NOBRIDGE) LOG  USER PROFILE IS null
(NOBRIDGE) LOG  USER PROFILE IS null
(NOBRIDGE) LOG  USER PROFILE IS null
... (repeats continuously)

Messages cannot be sent.

Root cause: chatContext.tsx → initializeChat() has a retry cap of 3 attempts (if (count >= 3) return). If the signer or user profile isn't available within 1.5s of the chat screen mounting, the context gives up and leaves userPublicKey / userProfileEvent as null. Downstream code in messages.tsx or SupportGroupChat.tsx guards on userProfileEvent before sending and logs the null warning in a tight loop.

Fix: The retry cap needs to be higher, use a longer backoff, or — better — listen reactively to the signer becoming available rather than polling with setTimeout. Consider subscribing to an auth state observable instead of retrying a fixed number of times.

---

❌ Bug 3 — Malformed Nostr filter causes relay rejections

Symptom:

(NOBRIDGE) DEBUG  NOTICE from wss://relay.damus.io/: ERROR: bad req: provided filter is not an object
(NOBRIDGE) DEBUG  NOTICE from wss://relay.primal.net/: ERROR: bad req: provided filter is not an object

Root cause: This is a downstream consequence of Bug 2. fetchGiftWrapsForPublicKey() in nostr.ts is called with pubkey = null (because userPublicKey is null), producing a filter:

{ "kinds": [1059], "#p": [null], "limit": 150 }

Relays correctly reject [null] as an invalid filter value.

Also noted: nostr.ts line 23 has a typo in publicRelays:

"wss//nos.lol",  // ← missing colon, should be wss://nos.lol

This will silently fail to connect to that relay on every subscription.

Fix: Guard fetchGiftWrapsForPublicKey with a null check before calling, and fix the URL typo.

---

✅ What worked

• Chat screen loads without crashing
• Slide-to-reply UI gesture is present
• New MessageBubble component renders message content correctly
• GroupInfoModal opens

---

Verdict: 3 bugs need fixing before merge. Bugs 2 + 3 are related (fix the profile null → relay errors go away). Bug 1 is independent and straightforward.

[forge0x]

📹 Additional bugs from screen recordings

❌ Bug 4 — Bitcoin balance shows ⚠️ warning icon next to "B0" on home screen

Symptom: Home screen displays a warning/error icon (⚠️) next to the Bitcoin balance, showing "B0" — suggesting the balance failed to load or is in an error state.

Likely cause: The Breez SDK wallet state is not initialized or the balance query returned an error/null. The warning icon suggests a balance fetch failure that isn't being handled gracefully — showing an error indicator instead of a loading state or cached value.

Expected behavior: Either show the last known balance, a loading spinner, or no icon — not a warning icon that implies something is broken.

---

⚠️ Bug 5 (possible regression) — "No Nostr Profile Found" on Social Settings screen

Symptom: Social Settings screen shows "No Nostr Profile Found" with a "Generate Profile" button, even after logging in.

Context: This may be expected behavior for a fresh test account with no Nostr profile. However, if existing users are seeing this after the flyerhq → new chat library migration, it could indicate the Nostr profile loading/caching logic was broken during the refactor.

Needs verification: Confirm whether this appears for accounts that previously had a Nostr profile. If yes, regression in chatContext.tsx → refreshUserProfile() or profile cache key handling.

[islandbitcoin]

🐛 Regression — Nostr profile setup loading screen broken in this PR

What main shows (correct behavior)

When opening Chat for the first time (no Nostr keys), main correctly shows the NostrSettingsScreen — "No Nostr Profile Found" with a button that updates through progress steps:

• "Updating profile..."
• "Uploading profile picture..."
• "Generating profile picture..."

What PR #579 shows (regression)

A bare, unstyled text fallback:

Loading your nostr keys...

NIP17Chat.tsx line 327 — never navigates to NostrSettingsScreen.

What the new design should show

The step-by-step progress checklist screen with the warning triangle icon, "Nostr Key Not Found on Device" heading, and a checklist of steps (Creating profile → Generating images → Uploading → Publishing to relays).

Root Cause

NIP17Chat.tsx has the bare text fallback that was never wired up to NostrSettingsScreen. This PR does not fix it but also does not fix the progression to the desired new design.

Required fix before merge

In NIP17Chat.tsx, when nostr keys are not present, navigate to or render NostrSettingsScreen (at minimum restoring main behavior). Ideally update to the new checklist design.

[islandbitcoin]

🐛 Tracking: Nostr setup loading screen not shown (blocking)

Acknowledged the bug reported by @islandbitcoin above.

Root cause: NIP17Chat.tsx line 327 renders a bare <Text>Loading your nostr keys...</Text> fallback when nostr keys aren't present, instead of navigating to the properly designed NostrSettingsScreen (already registered in root-navigator.tsx:333).

Fix: Replace the bare text fallback in NIP17Chat.tsx with navigation to NostrSettingsScreen when nostr keys are not loaded. This ensures new users see the full key setup flow (progress checklist, profile creation, relay publishing) instead of unstyled text.

Will address before merge. — Vandana (Flash Dev Agent)

[forge0x]

Bug confirmed: bare text fallback when no Nostr keys on device

Tracking the issue flagged by @islandbitcoin. Exact fix below.

Root cause: In NIP17Chat.tsx, the render fallback renders bare unstyled text when userPublicKey is null (no keys on device). New users entering Chat hit this instead of the proper Nostr key setup flow.

Fix: In initialize(), replace setShowImportModal(true) with navigation.navigate('NostrSettingsScreen') when no secret key is found. Apply the same change in useFocusEffect / checkSecretKey.

Also replace the bare <Text>Loading your nostr keys...</Text> JSX fallback with an <ActivityIndicator /> for the brief moment before navigation fires.

NostrSettingsScreen is already registered in root-navigator.tsx and RootNavigator is already typed as StackNavigationProp<RootStackParamList> in the component — minimal change needed.

[islandbitcoin]

Conditionally approved ✅

Ran through the full QA test script (fresh install, profile generation, contacts, messaging, reactions, slide-to-reply) on both iOS simulator and Android emulator.

What's working:

• ✅ Reactions (thumbs up and emoji) send and display correctly
• ✅ Slide-to-reply renders quoted message context correctly on both platforms
• ✅ flyerhq dependency removed cleanly, custom GroupMessage type works
• ✅ Tab bar correctly hides when inside a message thread
• ✅ Kind 7 reactions no longer appear as phantom conversations in the chat list
• ✅ Delivery status modal shows per-relay results

One finding (pre-existing, not caused by this PR):
Intermittent "Missed a note" during slide-to-reply test — caused by gift wrap subscription reconnect gap with no since backfill. Tracked separately in #592, assigned to @abh3po.

Approval is conditional on #592 being addressed in a follow-up.

[islandbitcoin]

Conditionally approved with #592 as a follow up