[BUG-234246] Implement Websockets for scripts.

[sl-service-account]

How would you like the feature to work?

Interaction with Sim scripts is difficult when the script is acting as a server to the outside world via llHTTPResponse(). The current http server implementation is lacking modern features and existing features are quickly becoming deprecated by web technologies and security recommendations.

A Websockets server implementation will allow for basic session style connections between scripts and the outside world. It would work similar to how the http server implementation works but instead supports a maintained connection where sessions are tracked by a key.

Communication on a websocket session will only be JSON strings which is more than enough for practically any transaction of information.

A websocket session will also only be secure by default with a url like:

wss://simhost-0fa73db0312bf3c49.agni.secondlife.io:12046/cap/359476a7-097a-b4c7-13b2-01afd0178b80

A basic web socket script could look like:

key wssSession;

default {
    state_entry(){}
    
    touch(integer i) {
        llReleaseWssHost(wssSession);
        //create a new Websockets server
        wssSession = llRequestWssHost();
        
        //create a new Websockets session for example completness
        //wssSession = llRequestWssSession(string serverUrl);
        
        string sessionUrl = llGetWssHostUrl(wssSession);
        llOwnerSay(sessionUrl);
    }     changed(integer change) {
        if(change & CHANGED_INVENTORY) {
            string jsonMessage = "{}";
            llWssSend(key sessionId, string jsonMessage);
        }
    }
    
    //sessionId here would be new keys for new connections or repeated for existing connections.
    //The script is responsible for tracking the sessionsIds and the message transactions.
    wss_message(key sessionId, string jsonMessage) {
        llOwnerSay(jsonMessage);
    }
    
    wss_session_started(key sessionId) {
    
    }
    
    wss_session_ended(key sessionId) {
    
    }
}  

 

Why is this feature important to you? How would it benefit the community?

This feature would allow for scripts to work in a more modern age of web based communication. Scripts can support state changes better rather than repeatedly sending requests to get states. Websockets can also allow for more efficent communications enabling only what is needed to be sent rather than create a full http transaction which is potentially more costly.

Development of external services would be easier as the developer is free to define structured payloads between their script and their external service.

I would also have a personal use for a Websockets server implementation as I wish to provide interaction with an In-world tool with a highly interactive Webassembly application that retrieves Prim inventory information in real-time and provides updates of its inventory in real-time.

Links

Related

• [ ] https://github.com/secondlife/jira-archive/issues/12363

Original Jira Fields

| Field | Value | | ------------- | ------------- | | Issue | BUG-234246 | | Summary | Implement Websockets for scripts. | | Type | New Feature Request | | Priority | Unset | | Status | Closed | | Resolution | Unactionable | | Reporter | TheRubberSmith (therubbersmith) | | Created at | 2023-08-12T15:05:23Z | | Updated at | 2023-08-16T18:26:09Z | ``` { 'Build Id': 'unset', 'Business Unit': ['Platform'], 'Date of First Response': '2023-08-13T13:59:38.399-0500', 'How would you like the feature to work?': 'Interaction with Sim scripts is difficult when the script is acting as a server to the outside world via llHTTPResponse(). The current http server implementation is lacking modern features and existing features are quickly becoming deprecated by web technologies and security recommendations.\r\n\r\nA Websockets server implementation will allow for basic session style connections between scripts and the outside world. It would work similar to how the http server implementation works but instead supports a maintained connection where sessions are tracked by a key. \r\n\r\nCommunication on a websocket session will only be JSON strings which is more than enough for practically any transaction of information.\r\n\r\nA websocket session will also only be secure by default with a url like:\r\nwss://simhost-0fa73db0312bf3c49.agni.secondlife.io:12046/cap/359476a7-097a-b4c7-13b2-01afd0178b80\r\n\r\n\r\n\r\n', 'ReOpened Count': 0.0, 'Severity': 'Unset', 'Target Viewer Version': 'viewer-development', 'Why is this feature important to you? How would it benefit the community?': 'This feature would allow for scripts to work in a more modern age of web based communication. Scripts can support state changes better rather than repeatedly sending requests to get states. Websockets can also allow for more efficent communications enabling only what is needed to be sent rather than create a full http transaction which is potentially more costly.\r\n\r\nDevelopment of external services would be easier as the developer is free to define structured payloads between their script and their external service.', } ```

[sl-service-account]

Chaser Zaks commented at 2023-08-13T18:59:38Z

I don't see why it should be restricted to json only, especially since Second Life uses XML, LLSD, and so forth as well. I'd personally say let the scripter decide what format to use and just pass raw data messages. Also I'd suggest using llWS* instead of llWSS*, as this locks it into secure. There are scenarios where a non-secure connection is preferred, such as where implementing such stuff isn't necessary or is otherwise hard to implement on the origin.

[sl-service-account]

TheRubberSmith commented at 2023-08-14T16:26:03Z, updated at 2023-08-14T16:39:53Z

  Json was just a preference, given the example it is ultimately strings so no real problem.

I understand the perspective and reasoning of llWS* vs llWSS*. We should be mindful about promoting secure communications over plain text given the predominant secure comms on the web as a whole. Advising the user of best practice at the end of the day is best but it would be beneficial to make secure equivalents easy. It is ultimately their decision on what they wish to use however.

[sl-service-account]

Spidey Linden commented at 2023-08-16T18:26:10Z

Hello, and thank you for your feature request.

Incoming suggestions are reviewed in the order they are received by a team of Lindens with diverse areas of expertise. We consider a number of factors: Is this change possible? Will it increase lag? Will it break existing content? Is it likely that the number of residents using this feature will justify the time to develop it? This wiki page further describes the reasoning we use: http://wiki.secondlife.com/wiki/Feature_Requests

This particular suggestion, unfortunately, cannot be tackled at this time. However, we regularly review previously deferred suggestions when circumstances change or resources become available.

We are grateful for the time you took to submit this feature request. We hope that you are not discouraged from submitting others in the future. Many excellent ideas to improve Second Life come from you, our residents. We can’t do it alone.

Thank you for your continued commitment to Second Life.Hello, and thank you for your feature request.

Incoming suggestions are reviewed in the order they are received by a team of Lindens with diverse areas of expertise. We consider a number of factors: Is this change possible? Will it increase lag? Will it break existing content? Is it likely that the number of residents using this feature will justify the time to develop it? This wiki page further describes the reasoning we use: http://wiki.secondlife.com/wiki/Feature_Requests

This particular suggestion, unfortunately, cannot be tackled at this time. However, we regularly review previously deferred suggestions when circumstances change or resources become available.

We are grateful for the time you took to submit this feature request. We hope that you are not discouraged from submitting others in the future. Many excellent ideas to improve Second Life come from you, our residents. We can’t do it alone.

Thank you for your continued commitment to Second Life.