✨ Feature Requests

how about a decent editor in notecarda allowing things like columns and so on. Our notecard are pitiful

As has been noted over and over again, the increase in phishing spam links is or has gotten out of control. In the following, I propose a practical way in which to address this issue which would seriously curb the issue if not altogether get rid of such an activity. Create new role abilities. New abilities would have defined rules for group owner, group moderator(s) or other trusted individuals to be the only allowed individuals to post links in a group. Sub-classification for members who don't fit the aforementioned roles to be allowed only to post image links from known/well established image sharing sites. (This too should have a on/off toggle to prevent any type of abuse as needed) Group owners/moderators can have/create an allowed list of URL's that are permitted in their group. Example: Marketplace.secondlife.com Defining permitted URLs allows only those that are an exact match and prevents misspelled and misleading links. In the event a user attempts to post outside of their role abilities, the post is blocked from being sent and user notified as to why. In the above proposed solution, spammers would not by default be allowed to post spam links in any group as the default persons of the established "everyone" role would not allow it nor any other default role as defined by the group administration. In consideration of what to do with groups whose administration has been absent for a period of 6 months or more, by default all link postings should be disabled until such a time (if ever) a group owner logs in and establishes who may post links. While some may see this as an unpopular option, it prevents those groups that some still use from being exploited. I propose this solution as if there is no ability to post phishing links, then there is less likelihood that users are entering in their credentials and their accounts being compromised as well as serving the great community good of people who just don't want to see this mess as there are other means of advertising for those who are interested. Regards, DJ Vicious

Currently, to report a message, you have to copy / paste the message that you are reporting. Sometimes these messages are larger than what the report field allows. It'd be easier on the end user if the report had context that is verified by the server, and I imagine it'd make life on Governance a bit easier, as they don't have to search for the message that is being reported, as the message context will be directly provided. This is already reported by the EventQueueGet's ChatterBoxInvitation 's instantmessage.message_params.MessageId . As a open source contributor, I'd be more than happy to draft a pull request featuring this capability into the viewer if somebody from Linden Lab wants to outline how they want this surfaced.

I am legally blind. Reading text isn’t easy. I have enough vision to see inworld; but, text chat and instant messages are tough. The idobata (spelling) program is of no help. Please make inworld text chat accessible to the legally blind and others who may have other disabilities with reading.

Would it be possible to give users a way to disable (make text only) links that are not SL supported or that do not fit a defined pattern? Supported links could include SURLs, MP, major Social Media platforms (insta, flickr, discord, primfeed), etc. If this is not feasible, would it be possible to give group owners a perm they can set for roles to allow/disallow posting of links? Having the option to allow but filter for supported links would be great, but again, if that's not possible, i can understand. This would at least give us some control over what keeps happening with malicious links in chat. i understand it would not be foolproof, but it could be a layer of protection added.

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.

Group Joiner HUDs and script and bot greeters are an annoyance in any store, but it is a particular problem in Linden Homes Commercial regions, because part of the parcel is on the pavement and so people walking past are being spammed by greeters and joiners of stores they have no intention of entering.

disallow users to pull names from groups (or anywhere) to initiate confrence calls. it's rude, unwelcome, and just spam. I don't like any personally unless I know I'm getting invited. so maybe it could be restricted to only those on a friends list at least or a pop up is shown to accept or decline them in the same way a voice confrence does.

Many people at the forums (and in world) would love to be able to outright block. When an ignored avatar (in world and in the forums) is blocked, they can still interact in unfavorable ways. Trolls should be limited, but the only thing limited is my ability to protect my privacy.

the webserver in SLS is missing some important abilities that are part of the http standard. I understand that there is a proxy server between my LSL webserver and the external internet, and therefore some restrictions must apply. But the omissions I have fallen over recently are not onerous for proxy server. For example basic realm authorisation setting cookies returning a redirect status These 3 require being able to set stock standard HTTP headers in the generated response , as is done by llSetContentType for the CONTENT_TYPE header. I'd also like to be able to do chunked responses. I accept that's a bit more ambitious So my request boils down to Please provide a function llSetHeader for at good subset of the standard HTTP headers. It should function with the same constraints as llSetContentType does.