[Feature] Native Telegram reactions for low-noise acknowledgements

[dimonb]

🎯 The Goal / Use Case

Telegram users expect lightweight acknowledgement patterns such as reacting with an emoji instead of always sending a full text reply.
For short interactions like “thanks”, “ok”, “seen”, “approved”, or simple emotional feedback, PicoClaw currently needs to send a normal message, which creates unnecessary noise in private chats, groups, and forum topics. This is especially noticeable in active Telegram threads where a reaction is a more natural response than another bot message.
The goal is to let PicoClaw use native Telegram reactions as a first-class response mode, with the option to also send a text reply when needed.

💡 Proposed Solution

Add first-class support for Telegram message reactions as a native agent capability.

The feature should allow the agent to:

• react to the current inbound Telegram message
• react to the parent / replied-to message when relevant
• react to a specific known Telegram message ID when needed
• choose between reaction only and reaction + text reply

To keep the behavior predictable and safe, allowed emojis should be controlled by config via
channels.telegram.allowed_reaction_emoji, with a sensible default allowlist.

When the agent chooses a reaction-only response, PicoClaw should suppress the final text reply so the visible result is just the emoji reaction, not a redundant extra message (it should be controlled by bot).

🛠 Potential Implementation (Optional)

A practical implementation path would be:

• add / keep a Telegram-specific reaction tool that is only available in Telegram conversations
• implement channel-level reaction sending through the Telegram Bot API setMessageReaction
• route reaction execution through the channel manager so tools do not call Telegram directly
• use existing Telegram reply context to resolve current, parent, or explicit message_id targets
• support also_reply=true for cases where the agent should both react and send text
• when also_reply=false, mark the turn as handled externally so typing / placeholder state is cleaned up without emitting an extra outbound message
• cover the behavior with tests for emoji allowlist validation, target resolution, Telegram API payload generation, and reaction-only flow suppression
• document the config in Telegram docs and optionally expose allowed_reaction_emoji in the web config UI

🚦 Impact & Roadmap Alignment

• This is a Core Feature
• This is a Nice-to-Have / Enhancement
• This aligns with the current Roadmap

[nikolasdehor]

Interesting proposal. From looking at the Telegram channel code in pkg/channels/telegram/telegram.go, the current architecture handles message sending through Send() (line 166) using telego.SendMessageParams. Adding reactions would require:

1. New tool type: A TelegramReactionTool in pkg/tools/ that wraps setMessageReaction. The tool should receive message_id (or "current"/"parent" keyword), emoji, and also_reply boolean.

2. Channel-level method: Add a React(ctx, chatID, messageID, emoji string) error method to TelegramChannel (implementing a new channels.ReactCapable interface, similar to the existing channels.TypingCapable on line 195).

3. Reply suppression: When also_reply=false, the tool result should set Silent: true in the ToolResult (like pkg/tools/result.go already supports), and the agent loop should check this before writing the outbound message to the bus.

4. Emoji allowlist: The config schema in pkg/config/config.go already has TelegramConfig — adding an AllowedReactionEmoji []string field with a default of common emojis like thumbs up, heart, fire would work well.

5. Message context resolution: The handleMessage function (line 349) already extracts message.MessageID and stores chatID — the reply-to context (message.ReplyToMessage) can provide the parent message ID.

The telego library already supports setMessageReaction via the Bot API, so no external dependency needed. The main design question is whether the reaction tool should be channel-specific (only injected when channel=telegram) or generic with channel adapters.

[dimonb]

I’m already experimenting with this in my branch, and one thing I’ve noticed is that it is hard to express, with tools alone, when the bot should stay silent and when it should also send a visible reply.

I’m also experimenting with threaded Telegram replies (reply_to_message) so the bot can reply to a specific message. These two features seem closely related, because both require the model to identify the correct target message ID and decide how the final response should be delivered.

The main problem may be timing: when the model calls a tool, it has not necessarily made the final decision yet about whether it wants to send a normal reply, react silently, or do both. That suggests these behaviors might fit better as part of the final output contract rather than as separate tools.

Instead of handling this only through tools, PicoClaw could support some structured delivery metadata in the model’s final output, for example hidden directives or structured JSON fields such as:

• reply_to_message_id
• suppress_text_reply
• emoji_reaction

This would let the model decide the delivery mode at the same time it generates the final response, which may lead to more coherent behavior than making partial decisions earlier through tool calls.

[dimonb]

@nikolasdehor As a result of my experiments over the past several days, this feature works very well.

The idea of describing a message format for the bot to allow it to participate in several conversations and use emoji reactions performs well.
1. I’ve saved all the needed information in the message history: msg_id, reply_id, author, and author_name.
2. I can mention the bot in any thread and, in this case, gather context from the thread’s messages plus several recent messages to provide more context.
3. I made compaction a bit smarter (mostly by summarizing messages).
4. I added a prompt to the model to let it know that it can add some metadata to a message to control reply_to or reactions.
The format is something like this, subject to discussion: [[reply_to:parent;react_to:current:❤️;react_to:905:🔥;text_reply=true]].
5. I also kept the reaction tool (with only the ability to add reactions) so the bot can set reactions during tool iteration. For example, you can ask the model to set a reaction when it starts a long process or provide other feedback while doing its job.
6. The implementation is quite easy.

If you think such a solution is acceptable, I can open a PR for further discussion.

[sipeed-bot]

@dimonb Hi! This Issue has had no activity for over 2 weeks, so I'm closing it for now to keep things tidy. If it's still relevant, feel free to reopen it anytime and we'll pick it back up.