Feature: Reply to previous messages in AntStation chat

[SheferKagan]

Summary

Add Slack-like “reply to message” support in AntStation desktop chats.

Users should be able to reply to a specific previous message, whether it was sent by the user or by the assistant/peer. The reply relationship should be visible in the chat UI and should help the peer understand which previous message the user is responding to.

Motivation

Long AntStation conversations can contain multiple topics, corrections, and follow-ups. Today, users can only continue the linear chat, which can make it unclear which previous message they are responding to.

A reply feature makes conversations easier to follow and provides more precise context for the AI peer.

User Story

As an AntStation user, I want to reply to a specific previous message in a chat, so that both I and the AI peer understand exactly which message my response refers to.

Proposed Behavior

Reply target

Users can reply to:

• previous user messages
• previous assistant / peer messages

Selecting a message to reply to

Initial direction:

• Each message should expose a reply action.
• Current preferred option: hover button on each message, shown as a small reply icon.

This is still subject to product review.

Composer reply mode

After selecting a message to reply to, the composer enters reply mode.

The composer should show a compact preview of the message being replied to, likely including:

• sender identity, e.g. You, Assistant, or peer/model name
• short excerpt of the original message
• cancel action to clear the reply target before sending

Sending a reply

When the user sends the message, AntStation should store/render the new message as a reply to the selected previous message.

The sent message should visibly show that it was a reply.

Example concept:

Replying to Assistant:
“Here is the function you asked about...”

I think this function should also handle empty input.

Jump to original message

Clicking the reply reference should scroll or jump to the original message in the chat.

Suggested behavior:

• scroll to the original message
• optionally highlight it briefly

If the original message is unavailable, the UI should show a graceful fallback.

Example fallback options:

• show stored excerpt only
• show “Original message unavailable”
• disable jump behavior

Peer Context Behavior

The reply relationship should affect what the peer receives, so the peer understands that the new user message is responding to a specific previous message.

Open decision:

• Whether to send the full replied-to message
• Or only a short excerpt
• Or send metadata/reference plus excerpt

Current tentative direction:

• send a short excerpt only

This should be confirmed before implementation.

Persistence

Reply metadata should be persisted with the chat message so that after reload:

• the reply relationship is still visible
• the reply preview/reference can be rendered
• the app can jump to the original message when possible

Possible stored fields:

• replyToMessageId
• replyToRole
• replyToSenderLabel
• replyToExcerpt
• optional timestamp/model/peer metadata

Exact schema is TBD.

Acceptance Criteria

• User can reply to a previous user message.
• User can reply to a previous assistant/peer message.
• Reply action is available on chat messages.
• Composer shows a “replying to” preview before sending.
• User can cancel reply mode before sending.
• Sent message visibly displays the message it replied to.
• Clicking the reply reference scrolls/jumps to the original message when available.
• Reply relationship is persisted and survives reload.
• Reply context is included in what the peer receives.
• If the original message cannot be found, the UI handles it gracefully.

Out of Scope for Initial Version

• Full threaded conversations
• Nested thread UI
• Separate thread panel
• Complex file/image preview handling
• Message deletion behavior beyond graceful fallback

Open Questions — Needs Discussion

Need product/boss confirmation before implementation:

1. Should the reply action be only a hover icon, or also available from a message menu/right-click menu?
2. Should the peer receive only a short excerpt, the full original message, or structured metadata?
3. Should the sent reply preview show sender only, sender + timestamp, or sender + model/peer name?
4. Should clicking the reply reference only scroll, or also briefly highlight the original message?
5. How should replies to very long messages be previewed: one-line truncate, two-line truncate, or expandable?
6. Should replies to code blocks/files/images have special preview behavior, or plain text only for v1?