Want to request a feature?

Create a new request and help us improve CometChat!

Remove Android Support Library Dependencies from CometChat Android SDK to Enable Jetifier Disablement

The customer would like to disable Jetifier in their Android project; however, the current CometChat Android SDK still depends on legacy Android Support libraries, which forces Jetifier to remain enabled. When attempting to manually exclude these transitive dependencies, the application crashes during SDK initialization due to the missing class android.arch.lifecycle.ProcessLifecycleOwnerInitializer. The customer noted that this dependency could be replaced with the AndroidX equivalent androidx.lifecycle.ProcessLifecycleOwnerInitializer. They are requesting that the CometChat Android SDK update its dependencies to fully adopt AndroidX and remove legacy support library references so that projects can safely disable the deprecated Jetifier option.

πŸ’‘ Feature Request

Ability to sort or group conversations by Tags (e.g., "Open" and "Closed") in the Conversations component in real time

Currently, the Conversations component does not support sorting or grouping conversations by tags (e.g., open or closed). In our use case, we want to display conversations in two sections: Open Chats and Closed Chats. As a workaround, we used two separate Conversations components, each with its own ConversationsRequestBuilder filter: readonly openConversationsRequestBuilder = new CometChat.ConversationsRequestBuilder() .setLimit(30) .setGroupTags(['open']) .withTags(true) .withUserAndGroupTags(true); readonly closedConversationsRequestBuilder = new CometChat.ConversationsRequestBuilder() .setLimit(30) .setGroupTags(['closed']) .withTags(true) .withUserAndGroupTags(true); Initially, the conversations appear correctly. However, when a new message is sent, the conversation sometimes reappears in the other Conversations component, even though it does not match the tag filter. Expected Behavior: Conversations should remain filtered according to the ConversationsRequestBuilder, even when real-time updates occur.

πŸ’‘ Feature Request

Support Reporting Frontend Action Execution Results to Agent in BYO Agent (AG-UI) Integration

Currently, in CometChat’s BYO Agent (AG-UI) integration, there is no mechanism to report the execution result of frontend-triggered actions back to the AI agent. When an agent triggers an action that is executed on the frontend (for example, schedule_appointment, chat_escalation_handoff, or other UI-driven workflows), the frontend can execute the action but cannot communicate the success or failure status back to the agent. Example Flow: User: "My app keeps crashing, please create a ticket"Agent β†’ CometChat: TOOL_CALL (create_support_ticket) CometChat β†’ Frontend: Trigger action Frontend β†’ Backend API: Create support ticket Backend: Ticket #12345 created successfully Expected behavior: The frontend should be able to report the result back to the agent (e.g., success with ticket ID or failure with an error message), allowing the agent to respond: "Your ticket #12345 was created successfully. Our support team will respond within 24 hours."

πŸ’‘ Feature Request

Add Sensitive Data Masking (Phone & Email) Support in New Moderation System

We are currently using the new Moderation system and observed that the Contact Details Filter and Email Filter only block messages when phone numbers or email addresses are detected. In the earlier Legacy Data Masking feature, there was an option to mask sensitive information (such as phone numbers and email addresses) while still allowing the message to be delivered. However, this masking capability does not appear to be available in the new Moderation system. Current Behavior: Messages containing phone numbers or email addresses are completely blocked. Expected Behavior / Requirement: The message should be delivered successfully. Sensitive information such as phone numbers and email addresses should be automatically masked instead of blocking the message. Example: Phone: 9876543210 β†’ 98XXXXXX10 Email: john.doe@gmail.com β†’ jo***@gmail.com

πŸ’‘ Feature Request

Include detailed violation β€œReasons” in moderation_engine_blocked Webhook Payload

Description: Moderation is functioning correctly, and the CometChat Dashboard displays comprehensive Violation Details β†’ Reasons whenever a message is blocked. However, the moderation_engine_blocked webhook payload currently only includes rule metadata such as: rule_id rule_name revision action blockedAt The payload does not include the detailed β€œReasons” explanation that is visible in the dashboard. Problem Statement: Since the webhook does not expose the violation reason, client applications can only show a generic message like β€œMessage blocked” to end users. This limits transparency and negatively impacts user experience. Requested Enhancement: Enhance the moderation_engine_blocked webhook JSON payload to include a detailed violation_reasons (or similar) field, matching the Violation Details β†’ Reasons shown in the dashboard.

πŸ’‘ Feature Request

CometChat – Blocked State Messages Should Not Update Delivery Status After Unblock

We have identified an issue related to message delivery status behavior in CometChat when users are blocked and later unblocked. Scenario: User A logs in on Device 1 User B logs in on Device 2 User A blocks User B User B sends messages to User A (messages correctly show single tick) User A unblocks User B User B sends a new message after being unblocked Current Behavior: Messages that were sent by User B while blocked initially show a single tick (correct behavior). However, once User A unblocks User B, those old messages are automatically updated to double blue ticks, even though they were never delivered to User A at the time they were sent. Expected Behavior: Messages sent while the sender was blocked should permanently remain in a single tick (undelivered) state, even after the unblock action. Only messages sent after the unblock event should follow the normal delivery and read receipt lifecycle.

πŸ’‘ Feature Request