✨ Feature Requests

Clarification Note: This is just for UDP side of the network in the viewer and isnt for the http network side which handles the actual downloading of assets at far higher speed than the actual legacy Max Bandwidth setting may Imply to us users. The Problem: The current Max Bandwidth setting is a legacy control that is difficult for users to tune correctly. Some suggest a "sweet spot" (often 700-1500 Kbps), as setting it too high may cause packet loss as it sent (at the viewers request) too many packets per second (pps) which some conusmer routers may struggle with, and setting it too low starves the the viewer of data. This requires users to manually "guess" their router's stable processing limit, which is not user-friendly and leads to a poor experience (e.g., packet loss, slow rezzing). Proposed Solution: Introduce a new checkbox in Preferences → Network & Files called: [ ] Enable Auto-Bandwidth Management When checked, this feature would automatically and dynamically manage the Max Bandwidth setting based on real-time network conditions. This automates the exact troubleshooting process support teams already recommend. How It Works: The Algorithm (in plain English) The algorithm's goal is to find the highest possible bandwidth setting that does not cause sustained packet loss. It does this by using the "Packet Loss" statistic the viewer already monitors. Steady-State Monitoring (When the network is calm): Rule for "Good" Connection: If Packet Loss remains at 0.0% for a full 60 seconds, the connection is stable. Action: Gently increase MaxBandwidth by 10% (e.g., from 1000 to 1100) to probe for more capacity. Rule for "Bad" Connection: If Packet Loss is sustained at or above 0.5% over a 15-second period... Action: The router is congested. Immediately decrease MaxBandwidth by 25% (e.g., from 1500 to 1125) to ease the load. The Critical "Teleport Grace Period" (Handling Network Spikes): The algorithm must be smart enough to ignore the massive, normal packet loss "burst" that happens during a teleport or new region login. Reacting to this "false positive" would incorrectly throttle the connection. Step 1: Detect Teleport. When the viewer initiates a teleport, the "Auto-Bandwidth" algorithm is SUSPENDED. Step 2: Start "Settling" Timer. When the "Teleport complete" message is received, the algorithm starts a 30-second "Settling" timer but remains suspended. Step 3: Ignore Burst Loss. During this 30-second "grace period," all packet loss is ignored. This gives the router time to process the initial data storm of the new region and for its queues to stabilize. Step 4: Resume Monitoring. After the 30-second grace period ends, the algorithm RESUMES and begins "Steady-State Monitoring" (Rule 1) again. Benefits: Solves the Guesswork: Users would no longer need to manually tune their bandwidth and reduces confusion. Improves Stability: The viewer would automatically defend itself from network congestion, reducing packet loss for users with consumer-grade routers. Smarter Performance: It dynamically adapts, lowering the throttle during a crowded event and raising it in a quiet region, always seeking the best possible performance for that user's specific hardware.

Currently we have a 'scripted agent status' checkbox on our account which marks the whole account as scripted or not. However, I do not think this reflects the reality of scripted agents. Some accounts are used as 'part-time' scripted agents (Think for example of people making roleplay alts, that are only sometimes used as bots). It would be more helpful to have an additional scripted agent status flag as part of the login session. Essentially, the viewer would tell the simulator if this current login session is 'scripted'. This will help also with compliance as scripted viewers can be programmed to send this flag automatically when logging in, and it will mean that when a human logs in with a normal viewer, they won't falsely be marked as scripted.

This has been going on for a while, and lately really aggressive, so it is time to talk about the increased sensitivity of account security features which is not useful at all. There are two key problems getting very annoying lately in this regard: 1: SL websites "forgetting" login and forcing login when you open the websites from your other device (PC and phone for example) despite "remember me" has been enabled at last login. 2: MFA challenges being required too often, for logins to non-critical websites from the devices we use every day. The way certain external services, mainly Support cannot remember a login, never made sense, but apparently the last few months this got worse because "security features" interfere with it. Simply put, I always open the Support website on my PC, never on my phone. I almost always open my Dashboard from my phone, very rarely on PC. If I open Support on the PC, I will have to log in. Regardless of "remember me" enabled, it happens that I have to log in several times over a few hours, because the website just "forgets" my login. Makes no sense. However the more annoying part is that after this, if I open my Dashboard on my phone (where I had been logged in), I need to log in again. So it seems the two devices (PC and phone) cannot stay logged in simultaneously. Why? I can stay logged in from several devices on my Google account for example, it saves them as trusted devices. It can't be too difficult to implement that for SL as well. The other problem is MFA tokens being required too often and for non-critical logins or actions. For example twice within 24 hours at Support, from the same PC. Then just before starting to write this, got a MFA challenge when I had to log in again on the phone to look at my Dashboard. 3 token challenges within 24 hours for non-critical logins from the two devices I've been using (exclusively) to log in to any SL service for several years. I understand you are trying to increase security to reduce risks of account theft, but... Who is going to try and steal my account using the PC and cell phone only I use? If someone tries to log in to your account from an unknown device and IP address, yes, BY ALL MEANS require a MFA token immediately each time it happens, that is what it is for. Logging users out of their accounts on one of their daily-use devices because they want to use the other daily-use device to access the same account is nonsense. And MFA challenges for non-critical actions on these daily-use devices is pointless as well. (At the same time still a lot of people get their accounts stolen because they still don't use MFA and they still enter their username and password on fake marketplace websites.) Please sort this out and if you can't recognize trusted devices automatically, add an option to add several devices on the Dashboard. Then these devices should stay logged in simultaneously if "remember me" was enabled at the last login, and except for critical actions (account detail or status change, membership, land, money) these devices shouldn't receive MFA challenges.

Some ISP:s in the world offer high bandwidth connections directly to consumers, while not having the infrastructure to forward all that traffic at the offered speeds. This can lead to a situation where the viewer's bandwidth setting is set quite high, while in reality the connection can't handle that throughput all of the time, or with very shifting actual capacity. I would like to propose that the viewer upon failing to log in, or failing in teleporting, if it can detect the signs of packet loss or connection issues causing this, that it recommends the user to reduce the bandwidth setting. Perhaps proposing to the user to start very low, and if it works, to increase it at future attempts.

Add encryption to all client-to-server communications. For example, by AES encrypting the UDP packets using a data key sent over the TCP login channel. If this isn't feasible in the short term, move any messages that potentially have highly sensitive communications, such as chat and IM messages, to TCP. Failing that, provide a UI warning before users log in using open wifi networks. There is an extremely high risk of real world harm to people who fail to realize the implications of logging in over an open network - consider a scenario where a user logs into SL using an open college wifi network, someone sniffs the network traffic, then passes around private messages about their sexuality or another highly personal topic. I highly recommend that the SL team do an internal risk assessment or threat modelling exercise as a double check. Potentially scary stuff.

Would be great to auto log in after log out as well as sit on a predetermined furniture. Especially after restarts.

The reliability of the world map is really poor. Tiles disappear/appear as you zoom in and out, it takes way too long to display a proper map and often doesn't display anything at all. I spend more time zooming in and out of the world map trying to get stuff to appear than I do actually using the world map. I think this experience is pretty common amongst residents. When I talk in the Second Life discord, viewer developers seem to think that it is simply 'the way it is' - 'The old image must be cached' etc. What I'm saying is that fundamentally it seems like whatever protocol powers the world map does not seem fit for purpose. Failures are too frequent on all viewers, TPV or first party cannot reliably render the world map when opened. I think this should be taken to the drawing board, the fundamentals and failure points assessed, and a better, more fail-safe world map protocol should be designed that will address the reliability issues of the existing design.

I want to suggest a feature idea to help counter copy-bots and bot-based griefers in private regions. This feature would let region owners optionally enable more security for their regions. The idea is for regions to validate viewers with special keys Related - https://feedback.secondlife.com/feature-requests/p/start-verifying-viewers Proposal Details: Region owners can turn this feature on or off If turned on: * LL and official TPV viewers would connect to regions using a private key for validation * The simulator would check the connection with public keys and decide if the viewer can connect. Validation happens entirely on the simulator side, and viewers would send encrypted requests with private keys if the region has this feature turned on * To handle viewer/simulator updates or key refreshes, the system could support multiple keys (old and new) * The "officialness" through key can be controlled by Linden Lab through key management with each TPV project Benefits: Regions with this option turned on would block viewers that don’t have valid keys. This could stop unauthorized viewers from stealing content or trolling other residents and region owners Residents using official viewers wouldn’t notice any difference. They’d connect to the region just like always through LL and Official TPV viewers Project viewers or new TPVs without keys could still connect to regions that don’t use this feature like right now Residents and region owners would have fewer concerns about trolls and content thefts. Linden Lab will have to deal with less AR cases This does not leave a trace of connections except on the simulator so 3rd party would not know which viewer was used to connect to the region (rejected would not be in the region) Key Management: Linden Lab would issue unique key pairs (private and public), and give the private key for each LL and TPV viewer TPV teams would be responsible for keeping their private keys secure. These keys should be kept secure to prevent leaks or misuse Linden Lab would revoke keys if they are leaked or misused Linden Lab would provide a way for TPV teams to request new keys if they are lost or compromised Why This Matters: I had a chance to meet a region owner who has been dealing with massive griefing and suspected content theft. They have a large community in their region, and visitors are systematically trolled, and their unique content seems to be stolen. This idea came to me as a way to give region owners more control while still keeping things simple for users