Problem Currently, when a message is blocked through Moderation, the backend correctly updates the message state by: Marking the message as blocked for the sender. Converting the message to sender-only, preventing receivers from accessing it. However, this change is only persisted at the data layer. No real-time event is emitted to connected clients, so: Receivers continue to see the original message until they refresh or reconnect. Senders do not immediately see the message updated to its blocked state. The correct state is reflected only after the conversation is re-fetched. Proposed Enhancement Enhance the Moderation flow to emit a real-time message update event whenever a message is blocked. This event should notify all connected clients so they can immediately update the UI. Expected Behavior Sender: The message should instantly update to the "blocked" state. Receivers: The message should be removed or updated immediately based on the sender-only visibility rules. No manual refresh or reconnection should be required for the changes to be reflected.

Description: Add a new notification preference for group conversations: “Notify only for replies to your messages.” When enabled, users will receive notifications only when another group member directly replies to one of their messages. Notifications for all other group messages and activities will be suppressed, allowing users to stay informed about conversations relevant to them while reducing notification noise in active groups. Scope: Applicable only to group conversations. Trigger notifications only for direct replies to the user’s messages. No notifications for other group messages, mentions, or activities unless covered by separate notification settings. User-configurable through the group notification preferences.

We need an option to fetch the group members list in a specific order, such as: By member scope (e.g., Owner, Admin, Moderator, Participant) In alphabetical order by member name

Introduce a configurable setting to increase the current group member limit of 30 users for SMS notifications. At present, SMS notifications are restricted to groups with up to 30 members, and there is no mechanism for developers or administrators to adjust this threshold based on their application’s requirements. This limitation impacts larger communities and enterprise use cases where SMS notifications are critical for user engagement and message delivery. Providing a configurable limit—either at the app, group, or account level—would offer greater flexibility, enable support for larger groups, and allow customers to balance notification reach, cost, and performance according to their specific needs.

Improve the media upload workflow to ensure video messages remain visible and continue uploading reliably when users leave the chat screen or the application enters the background. Currently, if a user sends a video and navigates away from the conversation before the upload completes, the video temporarily disappears from the chat and only reappears once the upload finishes. Additionally, if the user leaves the chat and locks the device during an ongoing upload, the upload may fail entirely, resulting in the video never being delivered to the recipient and not appearing in the conversation afterward. The expected behavior is for pending video messages to persist in the chat with an appropriate uploading state indicator and for uploads to continue or resume reliably across navigation events, app backgrounding, and device lock scenarios. This enhancement would improve message reliability, prevent content loss, and provide a user experience consistent with modern messaging applications.

Currently, CometChat provides unread message counts at the conversation/group level, but there is no way to retrieve unread counts filtered by a specific sender within a group conversation. We need the ability to fetch the unread message count for messages sent by a particular user (for example, a doctor) from another user's perspective (for example, a patient).

Request support for advanced bot functionality within group conversations: Protected Bot Membership Automatically add a predefined bot to every newly created group. Prevent the bot from being removed, blocked, muted, or otherwise restricted by any group member, admin, or owner. Ensure the bot remains a permanent participant in the group. Selective Message Visibility in Groups Allow bots to send messages within a group that are visible only to specific users or user segments. Enable use cases such as personalized notifications, role-based announcements, and targeted reminders while keeping the conversation context inside the group. These capabilities would help developers build more advanced automation, notification, and assistant-driven experiences within CometChat groups.

urrently, CometChat does not provide a mechanism to delete all users and groups in bulk through either the Dashboard or an API. Customers managing test, staging, or development environments often need to reset application data efficiently without manually deleting individual users and groups. We request the introduction of: A Bulk Delete Users API. A Bulk Delete Groups API. An option in the CometChat Dashboard to clear/delete all users and groups. Appropriate safeguards such as confirmation prompts, permissions, and audit logging to prevent accidental deletion.

Currently, editMessage() allows updating metadata associated with a MediaMessage (such as captions, tags, or custom metadata), but it does not support replacing the actual uploaded file or attachment. The attachment URL remains permanently linked to the original uploaded file, requiring users to delete the existing message and send a new one whenever they need to replace an image, video, audio file, or document.

We would like to request support for filtering groups and conversations directly by membersCount=0 through the REST APIs. Currently, this requires fetching records and performing client-side filtering, which adds additional API calls and processing overhead. Having a server-side filter for empty groups would simplify implementation and improve efficiency for use cases involving inactive or abandoned groups.

Currently, the CometChat Widget only supports changing the language, but it does not allow overriding or customizing localization/translation keys. We need support for custom localization key overrides within the Widget so developers can modify default UI text according to their application requirements without migrating to the full UI Kit or UI Kit Builder.

Introduce support for additive push token registration in the SDK to enable simultaneous push notifications for multiple logged-in users on the same device. Currently, when the same FCM/APNs token is registered for another user via registerPushToken, it gets reassigned from the previously registered user, causing only the most recently registered account to receive notifications. This limitation impacts applications implementing in-app account switching or multi-account experiences where users remain signed into multiple accounts concurrently. The requested enhancement would allow a single device token to be associated with multiple CometChat users at the same time, ensuring independent push delivery for each account and enabling seamless multi-account notification support similar to modern messaging platforms.

Currently the Chat Logs section in the CometChat dashboard only supports filtering by SenderUIDs. Please add support for ReceiverUID-based filtering as well, as it would help us efficiently monitor and audit conversations across multiple public chat groups in our integration. Support for combined SenderUID and ReceiverUID filtering would also be very useful.

Currently, a conversation between two users is only created after a message is sent or through indirect workarounds such as sending and deleting a message or using the Add Friends API with addToConversations: true. We need a direct way to create/initiate a conversation between users without requiring any message exchange.

Currently, navigating between conversations, groups, and chat sections shows a temporary grey loading/skeleton state while data is re-fetched and re-rendered. We would like support for offline caching or persistent local storage in the UIKit to enable smoother transitions and reduce visible loading states during navigation, improving the overall chat experience and perceived performance.

When a user searches for a word/message in the chat and clicks on a search result, the entire page refreshes unexpectedly instead of smoothly navigating to the selected message. This negatively impacts the user experience and breaks the expected navigation flow during message search in React applications using the CometChat UI Kit. As per the CometChat React Search documentation, onMessageClicked should support custom navigation behavior without triggering a full page reload. Requirement: Prevent full page refresh when clicking a search result Allow smooth navigation/scrolling to the selected message Ensure onMessageClicked works correctly for custom navigation handling in SPA-based React applications This enhancement would improve usability and align the behavior with expected React application navigation patterns.

Request to support for increasing the current 50-entity limit per Data Import API request or providing an alternative bulk CSV import mechanism to improve import efficiency and reduce operational overhead. This would help streamline large-scale migrations and reduce the number of API calls and batching logic required during onboarding.

request for a REST API capability similar to the SDK method getMessageReceipts(), which would allow identifying the exact group members to whom a group message was sent using the messageId. This is specifically needed for cases where group membership changes over time, as current APIs only return the current group members and not the historical recipients at the time the message was sent.

Introduce built-in state persistence support for the CometChatSearch component in the Flutter UI Kit so that previously entered search keywords and search results are retained when users navigate away from and reopen the search screen during the same app session. Currently, the search state resets completely upon reopening the component, forcing users to re-enter search queries and repeat the search process. This behavior negatively impacts usability, especially in workflows involving frequent navigation between conversations and search results. Providing automatic state retention or exposing properties/callbacks to preserve and restore the search context would align the component with modern search UX standards, improve user experience, and reduce the need for custom state-management implementations.

Introduce native support for inline URL preview generation within CometChatMessageComposer in the Flutter UI Kit. Currently, link preview metadata is fetched and displayed only after the message has been successfully sent, whereas modern messaging applications such as WhatsApp and Microsoft Teams provide real-time preview generation while the user is composing the message. This feature should detect valid URLs as they are typed or pasted, fetch preview metadata before sending, and display a dynamic preview card inline above the composer. Supporting pre-send link previews would significantly improve user confidence, enhance the messaging experience, and align the UI Kit with modern chat application standards without requiring developers to build complex custom implementations.