✨ Feature Requests

  • Search existing ideas before submitting- Use support.secondlife.com for customer support issues- Keep posts on-topicThank you for your ideas!
Separate Offline Message Limits for Instant Messages and Group Notices
Currently, there is a single cap that applies to both private instant messages and group notices received while offline. This can create a significant problem for users who belong to many groups, especially when those groups send a large number of notices. Because both types of messages count toward the same limit, group notices can quickly fill the offline message queue. When we log back in, we may receive a large number of group notices until the delivery limit is reached, with no way of knowing whether important private instant messages were prevented from being delivered. In some cases, we don't find out that someone sent us an offline message until hours later, when that person asks why we never responded. I'd like to propose separate offline delivery limits for private instant messages and group notices. For example, as a Premium Plus member, my current limit is 240 messages total. Because I receive a lot of group notices, I frequently hit that limit while offline. I've had people become upset with me for not responding to messages that I never actually received because the cap had already been reached. Under this proposal, instead of having a single limit of 240 messages for everything, Premium Plus members could receive up to 240 offline instant messages and up to 240 offline group notices separately. Users on other membership tiers could retain their existing limits, but those limits would also be separated between instant messages and group notices. Separating these limits would greatly reduce the chances of important personal messages being lost simply because a user's offline queue was filled with group notices.
6
·
Communication
·
tracked
Improve Visibility and Handling of "Restrict IMs to Friends" Setting
Users frequently enable the “restrict IMs to friends only” setting to reduce spam or increase privacy, but there is no persistent or contextual reminder that the setting is active. As a result, users often forget it is enabled, sometimes for extended periods. This leads to missed messages without any indication that communication attempts were blocked. Currently, there is: No visible UI indicator that the restriction is active during normal use No warning when initiating communication with non-friends No system for capturing or reviewing blocked messages This creates avoidable communication failures and user confusion. The number of "I didn't know I had that enabled" has steadily increased over the last several years. Proposed Improvements 1. Contextual Reminder on IM Initiation When a user opens or attempts to start an IM with a non-friend, display a clear notice such as: “You currently have IMs restricted from non-friends.” This ensures the setting is visible at the moment it becomes relevant. 2. Outbound Message Handling If a user attempts to send a message to a non-friend while the restriction is active, provide one of the following options: Temporarily allow IMs with that specific user (UUID) for the current session (similar to how you get a first-time session message from scripted agents) Prompt to disable the restriction entirely, with a confirmation warning explaining the impact This prevents contradictory behavior where the user initiates communication but silently blocks replies. 3. Inbound Message Queue (Held Messages) Instead of discarding or fully blocking incoming IMs from non-friends, introduce a “held messages” system in the UI: Messages from non-friends are stored in a reviewable queue Users can selectively read, accept, ignore, or mute/block senders The UI should provide a clear indicator that messages are being held This preserves user control while eliminating silent message loss. Expected Outcome These changes would reduce missed communications, improve user awareness of active restrictions, and maintain privacy controls without sacrificing usability. The current behavior prioritizes blocking at the cost of transparency; this proposal restores balance by making the system more explicit and recoverable. User Impact / Rationale When users forget this setting is enabled, they may initiate conversations with non-friends and receive no response. From their perspective, messages appear to be delivered normally, but replies are silently blocked. There is no feedback indicating that the restriction is the cause. This creates a misleading experience: users interpret the lack of response as disinterest, rejection, or platform inactivity, rather than a configuration issue. Over time, repeated failed interactions can reduce trust in the messaging system and discourage further engagement. In practical terms, this setting can unintentionally simulate a non-responsive user base ("everyone's a bot", “no one cares about me”, “this place is dead”). Without clear feedback or recovery mechanisms, it contributes to avoidable frustration and may lead some users to disengage from the platform entirely.
2
·
Communication
·
tracked
Load More