✨ Feature Requests

With the dismantling of the almost two decade long "LDPW" and "Mole" naming conventions, it will become increasingly difficult for Official Second Life Viewer users to properly distinguish and verify that a Linden Lab contracted employee avatar account is in fact a genuine one and not just an ordinary Resident account owner fraudulently claiming to be one. This is most apparent in the official Second Life Viewer, where all avatars have identical coloured nametags, mini-map dots and chat text. The official Second Life Viewer currently has no easy visual way to identify real Linden Lab employees and avatars from ordinary Resident accounts. This could become a genuine Trust & Safety issue too. To counteract this, I propose that the Official Second Life Viewer adopts the same system that Firestorm Viewer has used for many years; specific nametag, chat text and mini-map colours linked to Linden Lab employees, contractors and avatars. Firestorm Viewer traditionally uses a dark blue colour to easily identify real and genuine Linden Lab employees and avatars seen inworld. Perhaps instead of using dark blue (which is difficult to read against dark backgrounds), that all genuine Linden Lab employees, contractors and avatars could use the same shade of blue as used in the official current Second Life logo? This particular shade of blue is a lighter blue used inworld at places such as the Welcome Hub and in external websites such as SL Marketplace - and even within this Canny Feature Request page too. In Firestorm, all Residents by default have green coloured mini-map dots, but have a default white nametag and white chat text . Friends have yellow nametags, yellow chat text and yellow mini-map dots. Other third party viewers have also adopted this colour convention, some even expanding on it to include magenta as the colour used by Estate Owners. Firestorm and other third party viewer users also have a Preferences option to change any of these default colours to whatever they desire too, but seen only locally within their own viewer. Additionally, all genuine Linden Lab employees, contractors and avatars should have the Second Life logo permanently displayed in their Profile front page details. Bots should also be given a specific nametag, mini-map dot and chat text colour too. Perhaps red?

Please add a clearly labeled “Urgent: Death Threats / Real-World Violence / Severe Racist Abuse” category to the existing in-world abuse report tool. Selecting this category should flag the report for priority review and prompt follow-up by the Governance team. I am requesting this because I have personally received death threats in Second Life. I filed police reports and submitted them to Linden Lab, yet the person’s main account remains active, and they continue to access Second Life through alternate accounts. This experience has left me concerned about how serious threats are identified and prioritized. While Harassment and Intolerance may already cover this conduct, there needs to be a clear way to distinguish urgent incidents within the reporting system. A direct threat to someone’s life or a severe racist attack should be immediately recognizable to the team reviewing incoming reports. This request is specifically for a category within the existing in-world reporting tool that signals the need for urgent assessment and follow-up. A resident should not have to experience repeated threats before a serious incident receives prompt attention.

Club ELFIN (since 2008) has floors in non-adjacent Mainland regions Mimolette and Enoki. Both had near-simultaneous restarts/warnings during our events six times in 2026: Sep 25 (~23:05 JST), Oct 9 (~22:00), Oct 12 (~22:00), Oct 16 (22:03/22:04), Oct 23 (22:09/22:10), Nov 6 (~22:10–22:13). All six events stopped; the evacuation region also restarted, scattering staff and guests. Nov 6 screenshots show warnings. We first learned that Boxy 5000 lets anyone request a restart at any time, even outside their home region. In Support Ticket #2568780, Freckle Linden confirmed that the Oct 12 restarts were again requested via Boxy 5000 by the same resident responsible for earlier incidents. One resident repeatedly requested restarts across regions. Please investigate later incidents; their requester is unknown. Please implement NOW a fair system for ALL Mainland residents—homes, schools, shops, clubs—to request advance restart-avoidance windows. These are preferences, not vetoes or guarantees; emergency work remains possible. Improve notices, restart classification and safeguards for resident requests. Without an alternative, ELFIN may have to consider preventive restarts before events to protect them, though we wish to avoid this practice. What would happen if club owners, event organizers and commercial venues worldwide all did the same, even once per 24 hours? Widespread uncoordinated restarts could disrupt Mainland. We may seek joint support from operators in Japan and worldwide, but hesitate: publicizing preventive restarts might encourage their spread. Please issue interim guidance before broad outreach. Please answer: (1) Will you start implementing advance restart-avoidance requests now? (2) If difficult, why? (3) If you consider widespread preventive restarts insignificant, why? This expands our existing request, “Avoid Scheduled Region Restarts During Japanese Prime Time (22:00–24:00 JST)” (40 votes Nov 8). Please link/merge without losing votes or comments; our Oct 31 renaming question remains unanswered. We made three songs to explain this issue simply and calmly to Linden staff and friends worldwide. Please listen and share your thoughts: English: Second Life Goes On and On？ https://youtu.be/RvGjHIndRe0 Japanese: Second Lifeは続くよどこまでも？ https://youtu.be/qf0aNDB93XE Portuguese: Second Life Continua Sem Fim? https://youtu.be/Efh1iaTrrHY We love Second Life and seek cooperation. Crea Shepherd | Club ELFIN

We already have avatar complexity controls that help limit how demanding other avatars are to display. I’d like similar control over objects and scenery, available to every resident without needing land ownership or estate permissions. Sometimes a location looks fairly simple but still causes a noticeable drop in FPS. Poorly optimized mesh, excessive detail, and heavy texture use can contribute to that, yet visitors don’t have a straightforward way to identify which objects are the most demanding. Lowering graphics settings affects the entire scene. Residents should also have the option to find and hide individual objects that may be hurting their performance. The main request is a simple viewer tool that lets us: List nearby objects and sort them by estimated rendering cost. Select and highlight an object so we can identify it. Derender that object directly from the list. Easily review and restore anything we’ve hidden. Where practical, the tool could show useful details such as triangle count and texture usage, with a clear explanation that rendering cost is an estimate and performance varies by computer and settings. An optional object complexity limit, similar in purpose to avatar complexity controls, would also be useful. Users should be able to exempt selected objects from automatic hiding, particularly buildings, floors, and objects they need to interact with. These controls would affect only the resident’s own view. They would leave the build and everyone else’s experience unchanged. Even starting with the sortable list and manual derender/restore controls would give residents a practical way to troubleshoot low FPS. It could help people stay and enjoy shops, venues, and events where they might otherwise have to leave because of poor performance.

When traveling, shopping, exploring, building, etc. with friends, it would be a nice function built into the client to be able to copy the position and focus direction of my own camera to paste into chat or IMs so that other users have the option to left-click/touch/tap it (similar to a SLurl, maybe call it a SLookAt? lol) to look at whatever it was I was looking at. I know there are scripted camera gadgets that can already do this, but having a native copy/paste "Look at this thing" function in the client itself would be immensely helpful for keeping users (especially new users) within the client instead of paying for a gadget or needing to rely on video screen-sharing in third party apps.

Just what the title says. The ability to de-render all objects owned by a resident, or de-render entire parcel.

The tiny Empire posting and the strong support it received was dismissed in a manner that can only be described as cavalier, despite the submitted evidence showing that it was a massive abuse of common resources. Bad enough, but to then to close the board was, in my opinion, a very disrespectful act. Please re-consider the closure and please, please at least respond to the very real concerns about the tiny empire abuse with an explanation as to why it is tolerated?

Users in SL have LONG lamented the issue of landmarks dying when a store, club, or other favored destination relocates. Landmarks die if a region is moved on the map as well. MANY Jiras and Feedbacks have been posted over the past ~23 years, asking for some way for destination owners to edit downstream landmarks. I have an idea.. Leverage Experience Tools. This suggestion is to create a sharable inventory asset, that acts like a landmark, but pulls it's data from an experience key. Let's start with some basic idea of how this asset might be set up. * On creation, the asset is full permissions for the creator. * Next owner permissions are pre-set to ✅ Copy ❌ Modify ✅ Transfer. * The Next Owner ❌ Modify is greyed out, and unable to be changed. On double-clicking: * If the current owner has modify permission, a UI floater is displayed, allowing the user to set the experience, specify the 'lookup' field for this landmark, and potentially a password field. It will also have a field that allows for viewing the current value in that field ( if the password is needed, only if it is correct) * If the asset owner does NOT have modify permission, the owner is immediately teleported to the destination. In terms of scripts: * The asset should appear (for LSL purposes) to BE a "INVENTORY_LANDMARK". * If a script is 'reading' the asset like a landmark using https://wiki.secondlife.com/wiki/LlTeleportAgent or any similar function, it should read the destination value and attempt to use it as expected. In all other ways it should act like a landmark, allowing sharing, etc. Perhaps an exception can be made allowing the placing of this no-modify asset into a notecard, as landmarks are OFTEN shared as notecard attachments. -------------------- If the permissions thing can't be done, perhaps a secondary approach to this is simply that ONLY the 'creator' of a smart-landmark asset, can edit it's experience data, password, destination, etc.. and that information would simply not be presented to "owner != creator" asset owners.. allowing the asset to otherwise work exactly like every other landmark for every user, except it's creator. The existing UI for "Landmark Properties" has lots of space for expansion related to experiences, and could serve as the basis for the interface for this new asset. The existing "About Landmark" UI even has some "Edit" functionality already in place. Though I'll be honest, I have no idea what "Landmark Location" means on this dialog. UI for changing the destination of a parcel's "Landing Point" or changing the destination of a "Pick" or a "Classified" already exist, and perhaps the UI design language and behind-the-scenes mechanics for these functions can be mined for a consistent user interface. ------------------- Perhaps a warning notice should appear when editing this new Experience Landmark . "Note: Editing this will edit all copies of this experience landmark that have been shared. If you would like to create a new Experience Landmark using this one as a template, click here: Create a New Experience Landmark". I'm sure someone else can figure out better phrasing.

A common problem is the "Out Of Date LM". I just had an awkward situation with that: I used a seasonal LM, and the first things that rezzed were seasonal decorations, but when everything finally rezzed: I had TPed into a private residence. And they were home. Very, very awkward. Whenever the topic of killing off "dead LMs" comes up, it is pointed out that it would require a search of everyone's inventory, be very computationally expensive, etc. Very valid concerns. I would like to propose a different mechanism: the region or parcel owner may set an "Expire Old LMs" property on their land (perhaps for a nominal fee, if overuse is a concern for some reason?) that sets to the current date and time. When someone uses an LM, have it check for the presence of that date, and if the LM was created before that timestamp, the TP fails and the Resident is noted that their LM has "expired". At which point, several possible outcomes. 1) The LM is moved to Trash. 2) The LM just "poofs", is removed entirely. (I can see both sides of the argument on this one.) 3) The LM is moved to an "Expired Landmarks" folder. 4) Nothing is done to the LM, the Resident has to deal with it manually. (Which will just lead to repeated attempts, tbh.) This removes the massive-inventory-search problem: it is comparing two properties at the time of use, and the thousands of LMs sitting idle in the inventory DB don't get bothered at all. It would reduce the incidence of "Hey, you just TPed into my house!" and "Didn't this used to be a club?" When land is abandoned, I would have the date set automatically.

Building on the individual voice moderation option introduced in the recent update, I’d like to suggest a similar control for sounds. Give authorized parcel and estate moderators the ability to mute sounds coming from a specific resident, including gestures, dance attachments, music players, and other sound-emitting objects they own. At venues, someone repeatedly playing loud or disruptive sounds can interrupt conversations, events, and everyone else’s experience. Staff should be able to address that individual without disabling sounds for everybody or immediately having to eject or ban them. The restriction should prevent others within the managed area from hearing that resident’s sounds, including sounds from their attachments and rezzed objects. It should be separate from text and voice moderation, reversible, and limited to the parcel or estate where staff have permission to moderate. The same idea behind muting someone who abuses voice should apply to someone who abuses sounds. Give staff a way to handle the disruption without taking the fun away from everyone else.