✨ Feature Requests

Please improve the responses of the Utility URLs described in https://wiki.secondlife.com/wiki/Linden_Lab_Official:Map_API_Reference#Utility_URLs Since the map API utility URLs need a repair (see https://feedback.secondlife.com/server-bugs/p/map-api-failures-coords-region-name-region-name-coords ), I suggest to add these little improvements of the API along with the fix: If "var" is left out, the response should not be some Javascript code, but: the pure region name, like: "Wicktro", HTTP status code: 200 the coordinates as a simple JSON array, like: "[1134,1056]", HTTP status code: 200 In case that no data is found for the requested coordinates or region name, the response should be an empty body "" with HTTP status code 204. In other cases like the recent error, the HTTP status code should an error code like 500. HTTP status 200 should be reserved for a valid request with found data only. If "var" is given though, the response should be like it has been all the time before the php2shell fix, to not break any scripts that rely on this behavior. REASON The javascript code in the response is useless if you regard basic programming rules and due to SOP. Called from LSL scripts or PHP servers it makes even less sense. In LSL scripts the memory is very limited, so you won't want to waste any of that precious memory on unnecessary parsing. Here is a test example how LSL code could handle the suggested responses: key queryGetRegionName; key queryGetCoords; string regionName; list coords; // to contain region coords as integers updateDisplay() { string output; if ( "" != regionName ) output = "Region: " + regionName + "\n"; if ( coords ) output += "Coords: " + llList2CSV( coords ); llSetText( output, <1.,1.,1.>, 1. ); } default { state_entry() { updateDisplay(); queryGetRegionName = llHTTPRequest( " https://cap.secondlife.com/cap/0/b713fe80-283b-4585-af4d-a3b7d9a32492?var=region&grid_x=1134&grid_y=1056 ", [], "" ); queryGetCoords = llHTTPRequest( " https://cap.secondlife.com/cap/0/d661249b-2b5a-4436-966a-3d3b8d7a574f?var=coords&sim_name=Wicktro ", [], "" ); } http_response( key request_id, integer status, list metadata, string body ) { if ( 200 == status ) { if ( queryGetRegionName == request_id ) { regionName = body; } else if ( queryGetCoords == request_id ) { coords = llJson2List( body ); } updateDisplay(); } else if ( 204 == status ) { llSay( 0, "Sorry, the region could not be found!" ); } else { llSay( 0, "Sorry, the SL map API is not available right now!" ); } } } This way no fancy parsing would be required anymore. No further waste of memory for unnecessary obstacles in the API responses.

In the veins of, but totally different from , this one https://feedback.secondlife.com/scripting-features/p/request-region-list-api I would like to request an EXTERNAL API Endpoint that returns _at least_ the following Region Info: * Name * Global Coordinates * Rating (G/M/A) * Maximum Avatar * Sim type (Full/Homestead) The selector would be _either_ RegionName _or_ (X,Y) (Global Coordinates). (EXTERNAL = can be hit by scripts / apps / service outside of Second Life without having to login) The information above would be very helpful for planners of travels/tours/convoy/caravan, as we can identify possible problematic places (e.g., regions with low MaxAv and/or Homestead regions), so we can plan ahead. I believe such info can be kept in an in-memory Redis structure, with the following mappings: * RegionName => UUID * (X,Y) => UUID * UUID => DetailedInfo Once-a-week Refresh of the Redis would be enough. Or, if you're generous, daily :-)

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.

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

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.

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.

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.

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.

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.