`quoted` reply renders an empty, non-tappable quote card (`QuotedMessage` hardcoded to empty)

Start in pkg/sendMessage/service/send_service.go, where the 20 message types construct ContextInfo with an empty QuotedMessage, and trace the data.Quoted request shape. Compare the two proposed approaches—accepting quoted content or looking it up by StanzaID—and confirm the reproduced text and media cases. Done means WhatsApp receives quoted content and the reply card displays and navigates to the original.

Summary

quoted replies are accepted and produce a ContextInfo, but the resulting message renders in WhatsApp as an empty, inert quote card: it shows no preview of the quoted message, and tapping it does not navigate to the original.

The cause is that QuotedMessage is hardcoded to an empty conversation, so the payload never carries the quoted content that WhatsApp clients need in order to render — and navigate — the reply card.

Issue #27 was closed as implemented, and the linkage (StanzaID / Participant) does work. This report is about the remaining half: the quote card has no content and no behavior.

Where

pkg/sendMessage/service/send_service.go — 20 occurrences on main (v0.7.2), one per message type:

MessageContextInfo: &waE2E.ContextInfo{
    StanzaID:      proto.String(data.Quoted.MessageID),
    Participant:   proto.String(data.Quoted.Participant),
    QuotedMessage: &waE2E.Message{Conversation: proto.String("")},
},

data.Quoted exposes only MessageID and Participant, so there is currently no way for a client to supply the quoted content.

Reproduce

# 1. anchor
curl -X POST "$BASE/send/text" -H "apikey: $KEY" -H 'Content-Type: application/json' \
  -d '{"number":"1203630000000@g.us","text":"Original message"}'
# -> data.Info.ID = 3EB0FAED5F6492D35F7A7B

# 2. reply quoting it
curl -X POST "$BASE/send/text" -H "apikey: $KEY" -H 'Content-Type: application/json' \
  -d '{"number":"1203630000000@g.us","text":"Reply","quoted":{"messageId":"3EB0FAED5F6492D35F7A7B","participant":"5511999999999:3@s.whatsapp.net"}}'

Response is 200, and MessageContextInfo comes back as:

{"stanzaID":"3EB0FAED5F6492D35F7A7B","participant":"5511999999999:3@s.whatsapp.net","quotedMessage":{"conversation":""}}

On the device, the reply shows a quote card with only the author label and no text, and tapping it does nothing.

What I ruled out

Tested against a live instance (v0.7.x, group chat, sender is group admin):

• Payload shape. Seven variants all produced quotedMessage.conversation: "" — {messageId}, {messageId, participant}, {key:{id}, message:{conversation}} (the Evolution API v2 shape, which is ignored entirely: stanzaID comes back empty), plus quoted.text, quoted.conversation, quoted.quotedMessage, and a top-level contextInfo.
• Message ID format. Tried quoting an anchor sent with a client-supplied id (a UUID) and one with a server-generated 3EB0... ID. Neither renders content, and neither navigates on tap — so this is not an ID-format problem.
• Message type. Same behavior on /send/text and /send/media.

Expected

ContextInfo.QuotedMessage should carry the quoted message's content so clients can render the preview and make the card tappable. Two possible directions:

1. Accept the quoted content in the request, e.g. an optional quoted.text (or the v2-compatible quoted.message.conversation), and use it instead of the empty literal.
2. Look the message up in the instance's message store by StanzaID and populate it server-side.

Option 1 is the smaller change and keeps the caller in control; option 2 is closer to how Evolution API v2 behaves for clients that only have the message ID.

Environment

• Evolution Go, self-hosted, v0.7.x
• Group chat (@g.us), instance is group admin
• Both /send/text and /send/media