✨ Feature Requests

In Land options, right below "Avatars on other parcels can see and chat with avatars on this parcel" please add a setting for objects as well. This would be for the public channel. I'm particularly inspired by visiting a parcel with the game "Coin Clash" running, and rapidly being struck by over 100 shouted messages from a neighbor's parcel. The people I was visiting groaned "oh, that again? we have all that stuff blocked, block all the messages." So, yay, blocking is an option, but imagine having to tell every visitor to block every new game someone comes up with that screams into their parcel? And writing this reminded me of a concern I'd had with a neighboring parcel in the past: their 'friendly' barkeeper bot that listened to our chat and periodically chimed in, from the parcel next door. Let's add a setting for privacy, please!

Dear Linden Lab Team,I am writing to propose an improvement to the estate and region management system in Second Life regarding permanent bans.Currently, when a simulator (sim) changes ownership, management, or completely changes its theme, the existing ban list often remains active. This creates an inconsistency: players find themselves permanently banned from entirely new communities or public spaces they have never interacted with, based on past issues with a completely different owner.To improve user experience and retention, I would like to suggest two possible solutions:Auto-Expiration or Ownership Reset: Implement an option where estate bans automatically expire after 3, 6, or a maximum of 8 months. Alternatively, when a region changes its primary covenant or owner, the ban list should automatically reset.Monetized Unban System: Introduce an official system where players can pay a fee in Linden Dollars (L$) to request an unban from a region, which could generate extra revenue for Linden Lab or the current estate owners.Thank you for your time and for constantly working to improve Second Life.Best regards,

Experience permissions are neat, great, useful, and yet polarizing. Really handy for the scripter, really annoying for the user who knows that clicking Accept means they've just given some person or group of persons the permission to do many things to them anywhere the experience is enabled. But there's an easy solution! Experiences are tied to locations after all. Let's borrow a well-established convention from mobile apps: Add a button for ["Only for this visit"] The whole set of mechanisms for this is already in place; basically we just need the extra button and a value flag. When this choice is made, the experience is granted as usual BUT when the user leaves the region, the temporary experience is automatically revoked. (And the ability to manually revoke remains as-is). This single additional option would make it much easier to temporarily trust experiences without the significant cleanup effort that usually comes with accepting experiences. The existing mechanism to trust Experiences long-term would still remain, but this would help a ton!

Similar to how you can select people to see you online, find you on map or mod your stuff, i would love to see an option to accept or deny teleport requests. I don't want to turn everyone off but some performers who do 10 shows a day and spam a teleport request at you blindly frustrates me. I may like the person but dislike the teleport spam. So if i could just uncheck a box for them so those requests would be declined that would be an amazing quality of life thing

Avatars should not be able to use llDamage against agents or objects on parcels where they are banned or otherwise do not have access. This should also extend to objects that have been deeded to a group by said avatar. Currently, if a parcel has damage enabled, a banned avatar can still use llDamage to affect targets within that parcel. This effectively allows them to bypass parcel bans and continue interacting with residents or objects despite being explicitly denied access by the land owner. This behavior undermines the purpose of parcel access controls. If a land owner bans an avatar, that decision should prevent all forms of hostile or disruptive interaction originating from that avatar, including scripted damage. Parcel owners rely on access controls such as bans and group restrictions to manage their land and protect the experience of people within it. Allowing banned avatars to continue affecting the parcel through llDamage removes control from the land owner and weakens their ability to enforce boundaries. By permitting damage interactions across parcel bans, the platform effectively overrides the land owner’s explicit decision about who is allowed to interact with their space. Preventing llDamage from working across parcel bans would restore the intended autonomy of land owners to control interactions within the environments they manage. A secondary request would be adding a flag to the region settings that can be set TRUE or FALSE to allow damage to be dealt from sources to targets on different parcels as a region wide setting and default it to FALSE

I get the need to turn off "Allow Rez" for the mainland public areas. To prevent griefing and such. But it would be safe to say that if you're a premium member, you would be less likely to commit a grievance since you're paying for your account and getting banned from it is an incentive for good behaviour. As such, allowing premium members to rez on "Public Linden Areas" (with an auto return 5mins) would make life easier for those of us who enjoy traveling on the roads or seas with vehicles. Especially if we hit one of those dreaded banlines/zero second security orbs returning our vehicles and forcing us to spend the next few minutes trying to find a tiny square to rez a new vehicle.

Please make animations usable with their UUID like many other asset types already are. Currently animations are a lone wolf in that they cannot be referenced by UUID when they intuitively should be. Currently with scripts: Textures able to be displayed with their UUID Sounds can be played with their UUID Notecards can be read with their UUID Materials, a brand new asset type, is able to be displayed with UUID Animations: 🙃 llGetInventoryKey and llGetPrimitiveParams/etc already implement protection against obtaining UUIDs without the proper asset permissions. I do not think that an arcane limitation like "no animations by UUID" is appropriate especially with the upcoming improvements to animated mesh with the GLTF project, and to server-side scripting with the Lua VM project.

I would like to suggest an improvement to user privacy in Second Life. Currently, even after blocking someone, it is still possible for them to track or identify a user through old items, Note cards. Old Calling Cards or photos that were shared in the past. This happens because blocked users can still see the user’s current username and display name on that old content and can still access their profile. Even changing a username does not prevent this, since those references continue to link back to the same profile. Blocking mainly stops direct interaction, but it does not remove access to previously shared content. To improve user safety, I suggest the following feature: When a user is blocked, any items, photos, or other shared content that display the blocker’s name should have that name removed or replaced with “Unknown” in the metadata. This would prevent blocked users from identifying or tracking someone through old content. Implementing this change would give users stronger control over their privacy and provide better protection against harassment or stalking.

If the online status is set to "hidden", it should not be able for scripts (i.e. "Online monitors") to reveal the avatar. An exception could be made if the scripted item and the avatar are in the same parcel (for shopping reasons etc.).

Some Experiences become active on our accounts without explicit request or permission. These are often linked to Gateways or Events and remain attached even after the event has ended or we never return to the Gateway. Currently, there is no option to revoke or forget these experiences. I propose that users be given the ability to opt out and fully forget any experience they did not explicitly choose, ensuring greater autonomy and control over our digital presence.