#2445Requested

Module-level subscriptions

Requested on GitHub by Superxwolf
Energy Committed0TeV

Hello,

First of, amazing job with this database. The level of dedication and commitment to innovating tech definitively shows a lot of progress! I can see the potential for SpacetimeDB not only for gaming, but for more general purpose business application, with the exception of the current client permission scheme. While RLS is a good step, what if you allow modules to subscribe users to queries rather than just relying on the client side to manage it? Most business application require stricter rule around data management that would better fit on the server side. Combining module-based subscription and allowing an option to disallow client subscriptions means you could choose to control the subscriptions exclusively on the server side via reducers.

I wanted to give a good gaming example where this change can grant better flexibility with data; Lets say we have a table for player's inventory and players should only see their own inventory. This can be implemented with RLS, however if the developer wants to integrate pickpocketing players via a special skill or item, RLS would block any way for the client to get temporary visibility to another player's inventory.

I started looking through the code to see how viable this is, however I have no experience with Rust, yet I'd love to help where I can with this.

  1. bfops added the feature-request label Apr 2, 2025
  2. Thanks for the kind words and for filing this request! You're right that we don't currently support this, but we have it on our radar for the future ๐Ÿ™‚

  3. We do intend for the RLS approach to be viable for your pickpocketing example too. The code would be something like "as long as there is an active pickpocket action within the last X seconds targeting the specific player, you are able to view their inventory".

Boost this Request

Reopen this request?

The request will return to its prior live status.

Mark as Duplicate

Pick the request that Module-level subscriptions is a duplicate of. Energy rolls up into that request and GitHub closes the linked issue as a duplicate with a timeline reference to the canonical.

Unmark Duplicate

Restore as an independent request. The linked GitHub issue will be reopened and its duplicate-of relationship cleared. The original timeline entries stay as history; the note below is posted as a follow-up comment.