✨ Feature Requests

As of this writing, residents can engage in abusive behavior by sending L$ to people who have blocked them. This enables the unwanted receipt of messages from blocked parties using the L$ Pay notes as an attack vector. When someone is blocked, all methods of communication or interaction should be prohibited at the forefront. People circumventing this are not only harassing people, but exploiting a safety exploit in the payment system to continue harassing people, which given the negligble cost of L$ on an individual level, these attacks could be persistent.

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

As someone who has a lot of friends in my list who also are hosts, i genuinely wish there was an option to disable the incoming Teleport Requests i get every day as it's quite bothering at times when you're focused on something important (like creating). It would be nice if SL had a mode just like the "busy" mode where it doesn't give you those unnecessary IM notifications or Teleport Requests when you have this mode activated.

Gesture chat spam in crowded areas is very disruptive and problematic for screen readers and translators. A simple toggle should be added to the viewer that filters chat instantiated by gestures from local chat.

From time to time, SL will drop entire posts from chat, leaving a gap in conversations. Example: I was in a group chat and had my alt on at the same time, watching the chat in both viewer windows. Everything worked normally, till someone posted a message that I saw, but my alt did not see. Example: just today, in an IM conversation with a friend, I asked a question and waited for an answer. After a good 20 minutes they messaged with "Are you ok?" because from their perspective, I'd gone silent. I copied and pasted our chatlog back to them, and they said "Oh, I never got that last message" and copied their log back to me, where it was indeed missing. Example: A long conversation with another friend, where (I thought) I was responding to everything she said. Suddenly she types "I guess you're AFK or not interested in talking to me tonight, so I'm going to log and go to bed". Fortunately I had her on Discord as well, so I screencapped my IM window and pasted it to her there. A long pause, then she screencapped her own and sent it to me...and everything I had said was missing. A relog on her end fixed it. This lack of reliability causes all sorts of problems, from needed information failing to reach those who need it, to hard feelings because someone thinks you're ignoring them because they never got your answer/reply, and so on. Out of ALL the online venues I've ever been in that had a chat function (games, IM apps, etc), this is the ONLY one that has done this to me, and the only one that does it as far as I'm aware...and it's done this for the entire time I've been in SL. There really has to be something that can be done to fix this. Never mind new chat features or enhancements for now, just make it reliable

We're working on upgrading Second Life’s voice system from to WebRTC, bringing better audio quality, noise cancellation, and automatic gain control while also enabling voice on mobile clients. Why the Change? Our current Vivox implementation is outdated and lacks modern audio enhancements. WebRTC will improve voice clarity, spatialization, and performance across devices. What’s Changing? Spatial Voice: We’ll use open-source solutions to maintain and enhance spatialized audio. Group & P2P Voice: A new server infrastructure will support these features. New Features: Improved voice clarity, better volume management, and potential for enhancements like reverb effects in certain regions. What to Expect? Viewer Update Required: Upgrading to WebRTC will require an updated viewer. Better voice experience: Lower latency, clearer audio, and improved support across devices. We’re finalizing the technical details and transition plan—stay tuned for more updates!

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.

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.

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

I am not certain how this could be implemented but it would be nice if in the Role options that there would be a togglable checkbox to allow or disallow certain group roles in a group from posting hyperlinks. This would make it more difficult for scammers to spam links to phishing websites that steal account log in information with fake log in screens. This would also even make it harder for for people to spam products in other designers groups that are for other stores.