clockworklabs
Option for not receiving reducer args
- We have a client which doesn't use the reducer args and they've requested to not receive them. This is medium priority and we'll reprioritize this to high priority if we decided we need to reduce network bandwidth further.
Related PR (does not solve this issue): https://github.com/clockworklabs/SpacetimeDB/pull/1812
@bfops This is frequently requested in the Discord for security reasons - people want to be able to write reducers like this:
#[reducer]
pub fn create_user(username: String, password: String, ...) {
// ...
}
You can't do this right now in SpacetimeDB since there is no way to say which reducers should or should not broadcast reducer arguments.
ah I was imagining this as a performance optimization. from a security perspective I think this will overlap the private reducer proposal that.. I'm not sure whether we have a separate ticket for?
https://github.com/clockworklabs/SpacetimeDBPrivate/issues/787 https://github.com/clockworklabs/SpacetimeDBPrivate/issues/1171
I think these are more appropriate for that concern.
We're going to call the original issue done; we have those linked issues for further work on the security side.
Hey @egormanga, we are working on a public roadmap, but for now I can say that we aren't actively working on these features right now. We're currently largely focused on auth-related features and web support.
Would you want to share more about your use case for hiding reducer args from all clients?
Currently, it involves hiding players' positions from each other when using server-authoritative physics.
@egormanga You should be able to achieve this right now by putting the player positions in an RLS-protected table, and having players send incremental updates rather than absolute positions (e.g. sending "move in the (1, 1) direction" rather than "move to (x, y)"). This would make the player positions fully server-authoritative, and hidden from the players.
I hope that helps for now!
Thank you for the solution, it works for simpler cases such as movement, inventory actions, crafting and so on, where both the server and the client both already know the data, but it pretty obviously fails as soon as you begin processing private user-generated content, such as direct chat messages.
The only possible workaround I see now is encrypting the arguments using PSK from a private table, but that's again only sanely possible for byte strings, as the encryption lacks strong typing. As soon as you try wrapping it in Protobuf for typed serialization, you've basically invented a new overlay protocol and the whole point of StDB-native websocket falls apart (as in: why not just use gRPC atp?)
That's a great use case. There is a bit of extra protection for private and/or RLS-protected tables: clients will only receive the reducer event if they subscribe to at least one row affected by the reducer, so this should work for private DMs for now.
Note: you must be careful that your reducer does not modify any publicly-visible tables for this to work!
This is definitely functionality we're working on expanding, but hopefully this behavior can work for you for now!