✨ Feature Requests

I think that the group owner the one that started the group should be able to remove and and all avitar the assign to the role of "OWNER" when people leave the group . It would be very much handy then having to wait on a trouble ticket.

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 would love to see the ability for people to get the server code and be able to run your own regions on AWS servers you rent yourself.

Hi! I run a medium sized Community in Second Life. Over the years, my community, like many others moved from using the Group Chat features in Second Life to discord due to the need for the ability to have persistent discussions that happen over the long term. However, I feel that this has had the side effect of giving my community less of a reason to log into Second Life. After all, all of the community discussions happen outside of Second Life now in discord instead. I believe that if we had a persistent group chat, many users will log into Second Life, simply to see what messages they missed in the group chats whilst they were away, which will ultimately lead to more activity. Communities like mine would be able to transition back to using Second Life as our primary communication venue, which will be good for Second Life's long-term health as more people will be engaging with the platform and helping it to grow, and in turn help financially justify other much-needed improvements to the group chat system.

Back in Spring/Summer of 2020 there was work being done to make the common chat channel (channel 0) definable by region owners. This work was done under the project name "Voices Carry". During the May 15, 2020 TPV Developer meeting, the new simulator chat range capability was discussed in that it'd: a) require viewer-side UI support, which had yet to be completed. b) The range set for a region would be reported to the viewer by the simulator as a part of the region information. c) and that the server-side support will be appearing real soon now™. Then at the May 26, 2020 Simulator User Group meeting this was further explained that: "a new ability is being developed to allow region / estate owners / managers to set the open chat range on a region (see BUG-228333). This update is only intended to affect nearby chat channel 0 (the default open chat channel)." And there followed at that time some clarification discussion with Rider Linden and Oz Linden addressing some of the inter-region concerns arising from this. In June of 2020, server release 2020-06-05T19:36:41.543337 "includes work in the simulators to eventually allow per-region values for Shout, Say, and Whisper distances. NOTE: Currently these values are read only, and can be accessed via the Sim Console." Which sparked similar discussion on the Second Life Server sub-forum. Not long after, but I'm not sure of the time frame the scripting function llGetEnv() had data for "whisper_range", "chat_range", and "shout_range" added as a return for scripts to be able to dynamically find out what the channel 0 chat ranges had been adjusted to. All of this was done during the cloud migration work and I assume by necessity was a lower priority. But then, nothing ever came of it. I know that projects get abandoned all the time for various reasons, but I wonder if this one simply fell through the cracks and might be something that can be re-looked at as a possible feature for Region/Estate managers to update on their own. (I'd be nice if it could be a parcel level setting but also understand why that might be desirable or even feasible.") In addition to extracts from the official Release Note and server forum, some of the detail extracts from the meetings come from Inara Pey's blog "Living in a Modem World", and full links can be provided on request. Thanks.

Allow group owners the ability to see when new members join by adding a date joined section.

Currently, the way 2FA works is that the current 30 second window is checked. Often times, 2FA will give a code that is 20 or more seconds into the 30 second window, giving people 10 or less seconds to type the code. You can either choose to wait, or try and rush it and hope that the login process all succeeds within 5 seconds. The way that most login portals handle TOTP tokens is to do a rolling window, that checks either the previous and current, or current and next. This removes the chance for system time differences, user input delays, etc.

Hello Linden Lab, I would like to request a feature that allows residents to block incoming monetary or item transfers, either globally or on a per-user basis. Specifically, I am asking for the ability to prevent other users from sending me Linden Dollars or gifting me items without my consent. There are situations where I have clearly communicated that I do not want to receive gifts or money, yet individuals continue to send them regardless. This removes my control over financial interaction and places me in uncomfortable social situations that I cannot prevent through existing tools. While blocking communication helps in some cases, it does not resolve unwanted financial transfers initiated as a way to push interaction or emotional pressure. An optional setting to refuse all incoming gifts and/or L$ transfers, with an additional ability to selectively block specific users from sending them, would give residents meaningful autonomy over how they engage financially in Second Life. This would help prevent boundary violations, reduce harassment, and support consent-based interaction. Thank you in advance.

Unpacking items requires a sandbox or proper rights. First you rez the item, then you open it, copy it to your inventory (root folder), and finally you clean up the mess on the land (if its done - leaving a mess). Optionally you move the box and unpacked folder to the appropriate place in your personal inventory. This process is not very intuitive and unnecessarily time consuming (especially for noobs). I would suggest making it possible to rightclick a box in inventory and unpack it directly to the inventory where the box is located. The same familar way how you handle zip folders on your desktop. Best regards.

Currently, we can attach a maximum of 38 attachments, but since objects attached to the "HUD" position are also counted in the total, it's sometimes impossible to wear more. This phenomenon is particularly noticeable for furry users. After equipping the necessary furry parts, there are often only 5-6 attachment slots left, along with some commonly used HUD adjustments for body or other parts, leaving almost only 1-2 slots, or even none, for clothing. I hope there can be a separate limit on the number of objects attached to the HUD position, independent of the attachment count.