Want to request a feature?

Create a new request and help us improve CometChat!

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

Real-Time Events for Tag Updates on Conversations + Local Caching Support

Currently, when tags are added to or removed from a conversation, the Conversation List does not update in real time. There are no dedicated events or listeners for tag added or tag removed actions. Because of this limitation, developers must manually refresh or re-fetch the conversation list to reflect updated tags. This leads to unnecessary screen reloads and negatively impacts user experience, especially during navigation. Additionally, there is no local caching mechanism for conversation tags. Due to the absence of caching, tag updates require a fresh API call, which affects performance and prevents seamless UI updates. We request the following enhancements: Real-time events/listeners for: Tag Added to Conversation Tag Removed from Conversation Local caching support for conversation tags, so that: Tag updates reflect instantly in the conversation list UI remains in sync without requiring manual refresh Performance is improved by reducing redundant API calls These improvements would significantly enhance real-time behavior, performance optimization, and overall developer experience while maintaining UI consistency.

💡 Feature Request

Convert 1:1 Chat to Group Chat (Add Participants to Existing Conversation)

Description Currently, CometChat treats 1:1 (direct) chats and group chats as separate entities. To include additional participants in an ongoing 1:1 conversation, a new group must be created manually, which results in losing the existing conversation context and history. We would like to request a native feature that allows converting an existing 1:1 chat into a group chat by adding more participants — similar to how platforms like LinkedIn allow users to expand an ongoing conversation. Expected Behavior Ability to add one or more users to an existing 1:1 chat. The conversation should seamlessly transition into a group chat. Existing message history should remain intact and visible to all participants (with proper permissions). System message indicating when users are added (e.g., “Rohit added John to the conversation”). Use Cases Customer support workflows where a manager or specialist needs to be added mid-conversation. Collaboration tools where discussions organically grow from 1:1 to multi-user. Sales or onboarding flows where stakeholders join an ongoing thread. Why This Matters This feature is critical for collaboration and support scenarios. Without it: Developers must create a new group and manually migrate context. Users lose conversational continuity. The experience feels fragmented compared to modern messaging platforms. Requested Scope Should be available via: Core SDKs (REST + Mobile/Web SDKs) UI Kits (prebuilt UI support) Optional Enhancements Ability to choose whether past history is visible to newly added users. API method like: convertDirectChatToGroup(conversationId, userIds[])

💡 Feature Request