SSCSM API capabilities

[ClobberXD]

Issue type

• Feature request / Question / Discussion

Summary

This issue is for enumerating the capabilities of the SSCSM API.

• Since the primary objective of SSCSMs is to offload a part of server's work, I assume it'd be able to do all the (local) player functions SSMs can.
• It would also have the capabilities of CSCSM for things like sending chat-messages, displaying chat-messages, etc.
• (Here's the feature request part) Since the server has control over SSCSMs, it'd be nice to extend the SSCSM API even further to be able to achieve functions like:
  • Modify FOV (Modify, not override. Each player has their own preferences. An SSCSM script should only be able to modify based on the current value instead of directly setting a fixed one. Same applies to all other functions listed below)
  • Modify mouse sensitivity (Usecase: Mods modifying FOV would also benefit from being able to modify mouse sensitivity accordingly)
  • Run callbacks on keypress (an SSCSM implementation of #7008)
  • Modify player physics (the sprint mod is the perfect usecase for this)
  • More client-side-only capabilities that I can't come up with at the moment.

[HybridDog]

Lua and LuaJIT have some problems which enable hard crashing (invalid memory access) or slowing down minetest, e.g. https://github.com/Facepunch/garrysmod-issues/issues/3526. Can SSCSM be implemented securely or should there always be a setting for the client to disable it?

[Desour]

I'd like to add some points:

- There should be callback registrations for individual nodes, something like: ```lua minetest.add_callbacks("default:chest_locked", { on_rightclick = function(pos, node) if the_chest_is_not_mine(pos) then return true -- do not send the action to the server end end, }) ``` This could maybe even be implemented in lua with `core.register_on_punchnode` and the like. - Predicting nodes should be possible. - Predicting object movement maybe, too? - Showing visual stuff that is more advanced than particles (see #5722, #6805). - Maybe an [areas](https://github.com/minetest/minetest/blob/a122ba0ef4af865d225adbe22a55b8001af04c61/doc/lua_api.txt#L4745) api? - Setting wielded item animations with keyframes or something the like (there are issues about this). - more things that are better done client side than server side - A new formspec api. It is requested already a long time. The server shouldn't give the formspec to the client directly but instead send something like a message to a sscsm so that this sscsm shows a correct formspec. Ergo the server side formspec api can be deprecated and csm can use a better api. I think, there were issues about this, but I can't find them. - Get keystrokes in the formspec. - Custom keys. Edit: See #2731.

[nerzhul]

many of what you want permit to do anything on the client lua state, it is very dangerous for clients, it's like sending random code. Look at the CSM API first. You can at least offload your formspec generation which is nice for formspec responsiveness, it's interesting for mods like unified_inventory which are very slow due to server side. Node prediction is already here and isn't linked with CSM. I don't want to have too raw access to irrlicht as lua and irrlicht have different lives :)

[ClobberXD]

• Predicting nodes should be possible.
• Predicting object movement maybe, too?

These are features to be implemented on the C++ side, I think.

• Maybe an areas api?

This seems like it should be a part of the SSM API instead.

• Setting wielded item animations with keyframes or something the like (there are issues about this).

I agree, there's also a lot of scope for animations in general. e.g. animated HUD elements

• A new formspec api. It is requested already a long time. The server shouldn't give the formspec to the client directly but instead send something like a message to a sscsm so that this sscsm shows a correct formspec. Ergo the server side formspec api can be deprecated and csm can use a better api. I think, there were issues about this, but I can't find them.

That's a little too much to ask for, considering that 5.1.0 isn't that far away, no? :)

• Get keystrokes in the formspec.
• Custom keys.

These would be great :+1:

[Desour]

• Predicting nodes should be possible.
• Predicting object movement maybe, too?

These are features to be implemented on the C++ side, I think.

Node prediction is already here and isn't linked with CSM.

I meant custom node prediction that can be done in lua. Eg. a mod could make some sort of ice shoes so that the player can walk over water with the water becoming ice. One example usecase could already be for an existing mod: the vehicles mod adds a motorcycle that makes walls behind itself like in tron. All this things would be nice to have without node display delay.

• Maybe an areas api?

This seems like it should be a part of the SSM API instead.

It is already. I thought, it could be useful for csm, too. An example usecase is additional client side protection testing to reduce server load and to increase security against players who dig the nodes and move into them.

That's a little too much to ask for, considering that 5.1.0 isn't that far away, no? :)

My points were not all directly meant for 5.1 but as far goals that may be worth thinking about.

[hecktest]

From my own, old notes on the subject...

Server provided script API

Send messages to the server. (duh) Get/set an object's position, rotation, velocity, bone transforms. Get/set animations, models, textures, and other visual properties on an ObjectRef. ( Usually just self, but there are uses for messing with objects client side, such as extrapolation ) Create one or more camera space viewmodel objects. Animate viewmodel object. Manually set bone positions on a viewmodel object. Create world space local objects, animate, set positions, etc... Set a local camera position, rotation and fov offset. Override the camera entirely. (killcams, etc) Clearing the override returns control of the camera to the default. Hide/show objects. Modify a mapblock's contents locally. (until the next update) Query nodes. Perform a raycast. Perform an AABB check. (Server also needs this) Perform a rotated box check. Perform a sweep test. (Sweep a physical object in any direction and see what it would hit on its way) Perform any other physics check that I forgot to mention. Yes, there are uses for this. Handle input. Input should be decided by the game, rather than restricting everyone to "WASD, space, mouse, aux" that we have now. Reading raw input should still be supported. Play sounds. Query own RTT/ping. Draw arbitrary GL primitives, 2D images and 3D models. Set an arbitrary camera matrix. Anything else that's required to move current client side behavior to lua. Provide the following update events:

• Every received server frame
• Every client frame
• After rendering
• On server message received
• At any arbitrary timer

Most of the local "set thing" functions would be overridden by whatever the server provides, so their only function is making things more responsive for the client. It is up to the game to decide what should be predicted, and how.

Server side SPS-related API

Send message to client. (ha) Play time-synced animation on an object, based on a timestamp. Minetest appears to do this to some degree (I may be wrong here), but letting clients initiate the animation on their end means we need to account for the time difference, by starting the animation at an offset. Hide objects from a client. Register virtual input buttons and axes. Ideally only "menu" and "console" should be built in. Register client-side config options. (Not unlike server side mod config, but this stuff would have its own menu) Get a client's measured connection quality. (RTT at least) Events:

• On client message received

Network messages should support at least the following modes: reliable, normal, low priority

Once this is all done, move most of the current "binary" client side gameplay to server provided scripts living in core, maybe move some of them even further, to minetest_game. Give games an option to override this stuff entirely. The more you move to lua, the easier it will be to fix things, and perhaps changes in gameplay will no longer require network protocol bumps. More bugs will be fixed if people don't have to dig into C++ to fix them.

You can save a lot of work by focusing on low level functions and letting us write the rest. For example, the "areas" API proposed above is trivial to do with lua alone, as long as the client and the server can exchange strings. Helper functions in core are welcome but not critical.

Security model

SPS should be properly sandboxed, measures should be taken to ensure security and integrity during the transmission, and to prevent casual tampering with received scripts. It is neither necessary nor desirable to cache received code in any way. Other anticheat measures are futile because the engine is open source anyway. Properly sandboxed SPS will not harm the client; the only thing that may not be always preventable is denial of service by hanging the runtime. But that falls under stupid, not malicious. Other than that, SPS should be safer than the JS you're running in your browser every day, as you do not have to worry about XSS and such. Annoying game content like screamers is also a non-issue because it is already possible. Just Test 2 had no problem implementing its rubbish new years popup, no SPS needed. Crypto miners are also unlikely to work because of how little (single threaded jitted bytecode) computing power the game leaves us after rendering. If someone manages to make it work still, it's their crappy server and their problem. In general, don't play crap servers and you won't have to worry about local scripts.

[gonzalezjo]

Lua and LuaJIT have some problems which enable hard crashing (invalid memory access) or slowing down minetest, e.g. Facepunch/garrysmod-issues#3526. Can SSCSM be implemented securely or should there always be a setting for the client to disable it?

Hey, that's my issue! :wave:

If you've got any questions regarding that issue, feel free to ask. Fortunately, mitigations for the bug shown in that issue exist and are open source, if Lua and LuaJIT are still interests.

[paramat]

It would also have the capabilities of CSCSM

Since the server has control over SSCSMs, it'd be nice to extend the SSCSM API even further to be able to achieve functions like:

The CPCSM API and the SSCSM API are the exact same thing (at the moment). The server has control over CPCSM too (restrictions), do you mean 'since the server sends the mod ...'? So this issue is not about SSCSM, it's about CSM. The only issues which are SSCSM-only are about mod sending over the network.

[ClobberXD]

The CPCSM API and the SSCSM API are the exact same thing (at the moment).

That's because the SSCSM API features requested here haven't been implemented yet. I'm sure we don't want some of the features listed here to be accessible by CPCSMs (like physics modifiers). CPCSMs should only be able to access a subset of the (SS)CSM API.

[paramat]

Sorry i'll change the title back. So you're actually requesting that SSCSM and CPCSM scripting environments are separated? That has been suggested by nerzhul.

[ClobberXD]

So you're actually requesting that SSCSM and CPCSM scripting environments are separated? That has been suggested by nerzhul.

Yes. This is because the primary objective of SSCSMs are to offload the server's workload to the client whenever and wherever possible in a secure way. With that justification, I should be able to do a lot more to the client from an SSCSM, and only from an SSCSM. Giving CSCSMs this capability/freedom would be like offering a modified client on a platter.

[HybridDog]

Giving CSCSMs this capability/freedom would just be like offering a modifiable client on a platter.

In some cases, such as admin players and creative servers, this may be desirable. Therefore a server-side setting and function to en- or disable the capabilities could be added.

[nerzhul]

Yes i think they should be separated, as a client should be able to handle mods himself for himself only and same for server. This also prevent problems with client defining globals in its own lua state which conflict with SSCSM globals

[ClobberXD]

Another suggestion: heaps of player (and entity) data like positions, animations, look-dirs, etc, are sent to each client. An SSCSM should be able to access all of these, which opens up so much more potential for (SSCS) mods.

Use-cases:

• 7646

• Selective displaying of player positions (and look-dirs) on minimap

[HybridDog]

I'm thinking that CSCSM always gives the player who uses it an advantage or disadvantage. Even a mod which saves received chat messages in a txt file gives an advantage: players who do not use it cannot read messages written shortly before being banned because the messages usually only appear in minetest chat. Maybe CSCSM should be dropped when SSCSM is available.

[nerzhul]

no need to drop it. Just have two lua states with different API levels

[HybridDog]

You're right; I didn't think about creative servers where clients are allowed to do what they want.

[raymoo]

Seems like that garrys mod exploit could already be used against servers, for example by sending a bunch of strings as formspec fields. With a modified client you could send an arbitrary number of fields and send a ton of these formspec submissions.

[TurkeyMcMac]

Request: SSCSMs should be able to create/manipulate textures. This would allow for procedural animations, among other things. From https://github.com/minetest/minetest/issues/12982.

[waleed177]

SPS should be properly sandboxed, measures should be taken to ensure security and integrity during the transmission, and to prevent casual tampering with received scripts. I don't understand why the minetest client should try prevent tampering with client side scripts in anyway, I think I should be able to modify any code running in my computer (i.e. it should be free software c;). Instead, security should be implemented server-side. I like the way browsers do it with me being able to modify the website with inspect element, and i like LibreJS c:.

[fluxionary]

security should be implemented server-side.

the problem is that the current state of server-side anti-hacking stuff is not great (see https://forum.minetest.net/viewtopic.php?f=3&t=27465), and limiting what the clients can do is much easier in the meantime.

I think I should be able to modify any code running in my computer

you can, it's pretty trivial to modify your client to use CSM even if the server restricts it. however, the server may not react kindly to your "abuse".

[tigercoding56]

also maybe simulate /override keypresses (idk what that could be used for , maybe to prevent glitching around in protected area)

[tigercoding56]

security should be implemented server-side.

the problem is that the current state of server-side anti-hacking stuff is not great (see forum.minetest.net/viewtopic.php?f=3&t=27465), and limiting what the clients can do is much easier in the meantime.

I think I should be able to modify any code running in my computer

you can, it's pretty trivial to modify your client to use CSM even if the server restricts it. however, the server may not react kindly to your "abuse".

well , and then we end up with something like Valce anticheat (which kicks me when i am streaming (watching) videos bc it eats all bandwidth) most people do not know how to modify clients anyway (we could also make client send checksum generated during the build , but anything can be modified (which is a inherent issue which i doubt we can fix))