fix(chat): publish kind 9 quote after room content creation for cross-client interoperability #187

2026-04-10T17:48:19Z

userAdityaa commented

2026-04-10 17:48:19 +00:00

Problem

Flotilla chat has been loading threads/goals/classifieds and other content kinds directly in the chat timeline. This works in Flotilla, but many Nostr clients only render kind 9 as chat messages.

Result: content created from chat could be missing in other clients’ chat timelines, causing broken conversation context.

Solution

For content created from chat, we now:

publish the content event (thread/goal/classified/calendar/poll)
publish a kind 9 chat message that quotes/references that new event

This preserves native content semantics while ensuring a standard chat timeline entry exists for interoperability.

Fixes #185

Behaviour after this PR

Creating thread/goal/classified/calendar/poll from chat creates the content event first, then creates one kind 9 chat message that quotes it.
The modal now closes as soon as publish is queued (history.back was moved before waiting on relay confirmation), so creation feels instant instead of waiting for network/auth round trips.
Relay confirmation and quote publish checks still run in the background, and errors are still surfaced via toast.
Chat timelines now prioritize standard chat messages (kind 9) plus membership system events, which avoids duplicate timeline entries from showing both the content event and the quote message.

### Problem Flotilla chat has been loading threads/goals/classifieds and other content kinds directly in the chat timeline. This works in Flotilla, but many Nostr clients only render kind 9 as chat messages. **Result:** content created from chat could be missing in other clients’ chat timelines, causing broken conversation context. ### Solution For content created from chat, we now: 1. publish the content event (thread/goal/classified/calendar/poll) 2. publish a kind 9 chat message that quotes/references that new event This preserves native content semantics while ensuring a standard chat timeline entry exists for interoperability. Fixes #185 ### Behaviour after this PR * Creating thread/goal/classified/calendar/poll from chat creates the content event first, then creates one kind 9 chat message that quotes it. * The modal now closes as soon as publish is queued (`history.back` was moved before waiting on relay confirmation), so creation feels instant instead of waiting for network/auth round trips. * Relay confirmation and quote publish checks still run in the background, and errors are still surfaced via toast. * Chat timelines now prioritize standard chat messages (kind 9) plus membership system events, which avoids duplicate timeline entries from showing both the content event and the quote message.

userAdityaa commented

2026-04-10 17:51:06 +00:00

@hodlbod, this PR is ready for review!

There are better solutions than just moving history.back()
for example, using a loader or background queue for publishing. This is a quick improvement, but open to your thoughts on a more better approach.

(and) Should I split this into 2–3 smaller commits, or keep it as a single atomic commit for now?

@hodlbod, this PR is ready for review! There are better solutions than just moving `history.back()` for example, using a loader or background queue for publishing. This is a quick improvement, but open to your thoughts on a more better approach. (and) Should I split this into 2–3 smaller commits, or keep it as a single atomic commit for now?

hodlbod commented

2026-04-10 17:57:53 +00:00

This looks good, except for the history.back stuff. We should wait for the calendar/thread/goal thunk to finish publishing before closing the modal so that if there is an error it's shown in context. A spinner is actually a nice reassurance that something is happening, and if we keep the modal open the error is actionable — the user has control over deciding what to fix or whether to try.

Once the main content event is published we can close the modal and not wait for the message error. The user is already on the chat page, so if the message has an error it will already be shown inline, so there's no need to show the toast. This will clean things up nicely.

This looks good, except for the history.back stuff. We should wait for the calendar/thread/goal thunk to finish publishing before closing the modal so that if there is an error it's shown in context. A spinner is actually a nice reassurance that something is happening, and if we keep the modal open the error is actionable — the user has control over deciding what to fix or whether to try. Once the main content event is published we can close the modal and not wait for the message error. The user is already on the chat page, so if the message has an error it will already be shown inline, so there's no need to show the toast. This will clean things up nicely.

👍 1

hodlbod commented

2026-04-10 17:59:47 +00:00

BTW, once you're finished with this, please go ahead and focus on Caravel, that's my top priority right now.

userAdityaa commented

2026-04-10 18:01:28 +00:00

BTW, once you're finished with this, please go ahead and focus on Caravel, that's my top priority right now.

Yeah, this will be my last one for a few days, I’ll be fully focusing on Caravel.

> BTW, once you're finished with this, please go ahead and focus on Caravel, that's my top priority right now. Yeah, this will be my last one for a few days, I’ll be fully focusing on Caravel.

👍 1

userAdityaa added 1 commit 2026-04-10 18:32:30 +00:00

fix(chat): publish kind 9 quote after room content creation for cross-client interoperability c397ee38bb

userAdityaa force-pushed chat-interoperability from 172befcf57 to c397ee38bb

2026-04-10 18:32:30 +00:00

Compare

hodlbod commented

2026-04-10 18:33:16 +00:00

One follow-up on this — we should remove MESSAGE_KINDS entirely and use MESSAGE where relevant. This will slim down sync and notifications in particular.

👍 1

userAdityaa added 1 commit 2026-04-10 18:43:06 +00:00

chore: remove MESSAGE_KINDS, use MESSAGE fd1b12b14a

userAdityaa commented

2026-04-10 18:43:11 +00:00

@hodlbod,
addressed the feedback and retained history.back as suggested. Also disabled the “Go Back” button to ensure a safer UX.

please refer to the attached video for the UI changes.

@hodlbod, addressed the feedback and retained `history.back` as suggested. Also disabled the “Go Back” button to ensure a safer UX. **please refer to the attached video for the UI changes.** <video src="attachments/4bccb5a2-a5bc-4b94-929f-54559355bf98" title="Screen Recording 2026-04-11 at 12.10.46 AM.mov" controls></video>

Screen Recording 2026-04-11 at 12.10.46 AM.mov

6.9 MiB

userAdityaa commented

2026-04-10 18:44:34 +00:00