Feature Requests

I would like the ability to declare a table as a disk table, where disk tables are cheaper, with higher limits, but may have higher access latency: ``` #[table(accessor = foobar, storage = disk)] struct Foobar { id: u64 } ```

## Summary While Maincloud is not technically on a bleeding edge or nightly release cycle, the latest version is deployed immediately after a new SpacetimeDB release. Your only option to not upgrade to latest is to use Standalone or lock in an Enterprise deal for a private node. Each of these have issues: - Standalone -> Free, but doesn't scale - Enterprise -> Potentially costly, and overkill for most The logical conclusion for a vast majority of users is to use shared hosting, a-la Maincloud. It even comes with `SLA / Uptime Guarantees` if you're a Pro subscriber. ## The Issue I have no doubt that a lot of effort goes into this, but deploying new SpacetimeDB versions to Maincloud without any issue or bugs is a tall order- in fact, it's an impossible order. The new version is being deployed to thousands of modules, all on various runtime versions, and some functionality will be tested live for the very first time in unexpected ways. We can have 1,000 different smoke tests, but they will never handle all of the edge-cases. This has, and will continue to lead to disruptions to Maincloud customers. If your app or game has paying customers, this type of disruption is not acceptable. Playing devils advocate- some would even argue that these types of disruptions indicate that Maincloud is not a production-ready environment. ## Proposal Similar to [#5204](https://github.com/clockworklabs/SpacetimeDB/issues/5204) and its related [feature request](<https://spacetimedb.com/features/requests/38>) I would love to see a LTS Maincloud instance that is fixed to a specific stable build. `spacetime publish <module_name> --lts` This would prevent new Maincloud version deploys (and bugs) from disrupting production applications deployed on LTS Maincloud, giving potential start-ups and businesses peace of mind knowing their backend infra is stable. ## Challenges I acknowledge this comes with many challenges, so I am looking for feedback and replies in the github thread: - Does current maincloud transition to LTS or Latest? - Maincloud will need module migration tool to go from server to server - Can you only migrate your module from LTS to Latest and not the other way around? - At what interval is the LTS version updated? What type of key milestones indicate a version bump? - What type of deploy/patches are allowed on LTS? Bugfixes only? What about QoL? - What should be the default Maincloud publish functionality, LTS or Latest? Happy to hear your thoughts. Let's have a discussion.

it would be nice to be able to define parameters for views to not need to use tables to define what data the client wants.

it would be nice to be able to write subscriptions that subscribe to multiple tables at once with conditions that link them. something like: ```sql "SELECT * FROM auction_listing as AL, user_name as UN, item_lookup as IL WHERE AL.cathegory = 'Weapon' LINK AL.entity_id = UN.entity_id, AL.item_id = IL.item_id" ``` and it is like writing 3+ separate subscriptions and returns the rows of the 3 tables where the link and where condition matches. the problem currently is that it is a pain to get related data from multiple tables without opening potentially hundreds to thousands of subcriptions per client.

it would be really useful to have an index type for pagination. my idea is `#[index(page(page_size))` (idk rust enough if that is valid/good syntax for this) that is accessed with `ctx.db.table.column.page(nr)` and returns the subset of rows defined by the page_size that's sorted by the column it was used on. this would simplify and optimise leaderboards, Auction pages, any form of listings and so on a lot. once view parameters are out, it would be possible to make a view that takes the page nr as parameter and then just get the subset without having to manually sort and subset the data within the view. as for the client updates, the client could just insert sort the new and deleted rows, so there is no need to change bsatn or the WS protocol for that

We already have btree and hash indicies but the `hash` index route for mutli column indices is not ideal to enfore the uniqueness invariant in a convenient way. This would also be immensily usefull for procedural view primary keys because you could actually determine a pk for a subset of your data :>

This has been asked for several times but most recently in discord: https://discord.com/channels/1037340874172014652/1352309930010480791/1352309991088062569 We need a way to have a column in one table reference a column in another table, something like: ```rust #[spacetimedb(table, name = "my_table", )] pub struct MyTable { #[primary_key] #[auto_inc] pub id: u64, // ... } #[spacetimedb(table, name = "another_table")] pub struct AnotherTable { // WARNING: This is pseudocode and does not actually work. #[foreign_key(MyTable)] pub id: u64, // ... } ``` The user I referenced above has this specific case where they have a `Vec<u64>` which each one of those `u64`s references a key in another table. So it's more like something like this: ```rust #[spacetimedb(table, name = "player_inventory")] pub struct PlayerInventory { #[foreign_key(Item), cascade_delete=false] pub items: Vec<u64> } #[spacetimedb(table, name = "item")] pub struct Item { #[primary_key] #[auto_inc] pub id: u64, pub name: String, // ... } ```

# Improved SpacetimeAuth Web UX ## Summary I’d like to request improvements to the SpacetimeAuth web login experience, especially for apps using third-party providers like Google and Discord. ## Issues ### 1. Extra authorization step The current identity-provider flow appears to require these steps: 1) Click login button on app 2) Click “Login with Google/Discord/etc.” 3) Click authorize with the provider 4) Click “Authorize Application” That fourth step is confusing for new users because they feel they already authorized the login provider. Ideally, third-party auth would only require selecting the provider and approving the provider login. If the extra step is required for technical reasons, the page should more clearly explain what is being authorized and why. ### 2. Login screen polish Play testers said the SpacetimeAuth login page looked somewhat “sketchy,” especially when only Google and Discord providers are available and email login is not enabled. A few CSS/layout improvements would help it feel more trustworthy and consistent with the polish of the main SpacetimeDB website. ### 3. Embedded login option It would be super helpful to support embedding the provider selection directly inside an app, similar to Firebase Auth, instead of requiring a redirect away from the page. ### 4. Role management Role management would still be useful, but it is lower priority for me because I already implemented a custom solution. ## Impact These changes would reduce login friction and improve trust for users trying apps built on SpacetimeDB, and prevent losing new players in the onboarding process.

Something like this: ``` // Pseudocode func upsert(ctx, primary_key_value, value): if ctx.primary_key_column.try_find(primary_key_value): // Row with a matching primary key column exists ctx.primary_key_column.delete(primary_key_value) ctx.primary_key_column.insert(primary_key_value, value) ``` In order to `upsert` on a column it needs to have a unique constraint on it.

Right now it is reasonably expensive to load in physics, terrain, or nav data during a "tick" which is the hottest path. Ideally we have some first-class support for a cheap read-only table that can be initialized at startup. Right now there is the potential to use a `const` or `static` but with caveats so having the team support this pattern out of the box would be really valuable. For example, I have navmesh grid data that is ~8mb. I need to load in ~200 bytes * 9 (for the chunks surround) per moving entity. So if I have 100 players and maybe 1000 monsters running around thats 1,100*200*9 potentially bytes read every ~100ms when I never need to edit this data. I can simply add this data into a const and bundle it with the module but it doesn't feel like "the spacetimedb way" of doing things. If something is 100% read only I'd like a way to read that data for close to free instead of the charge at the same rate as hot data.

## Summary Current state requires you to create your own `Secrets` table. You publish, and then use the CLI to SQL insert into your secrets table. Example of the table below: ```csharp [Table(Public = false, Accessor = "Secrets")] public partial struct Secrets { [PrimaryKey] public string Key; public string Secret; } ``` ## The Issue The problem here is mainly around visibility, but also it's a bit clunky and unintuitive to set up. SpacetimeDB is supposed to about developer experience after all, right? - You can read your secret after setting it (goes against industry standard) - All collaborators can read private tables in maincloud, meaning your secrets can be read - You are required to set up the table correctly (whoops I set it to public) - You need to use the CLI to `INSERT INTO Secrets (Key, Secret) VALUES ('my-key-value', 'my-secret-value')` which not super enjoyable ## Proposal I am proposing that secrets mimic Cloudflare worker secrets, and you interact with them similarly to how Wrangler CLI interacts with them in that environment. In SpacetimeDB, there should be no need to declare your `Secrets` private table- it should just exist. Instead, you simply run a CLI command, or newly created `/v1/database/:name_or_identity/secrets PUT/DELETE` routes, which allows you to upsert (insert or update) a secret for a particular key. ```powershell PS E:\chippy> spacetime secret <module-name-or-identity> <put|delete> <key-value> Enter a secret value: *********************** - Creating the secret for <module-name-or-identity> ✨ Success! Uploaded secret <key-value> ``` Secrets would be PUT or DELETE only, and never able to be read via the HTTP /v1/sql routes. As planned it *could* be printed in a console log within a reducer, but that's a fairly intentional way to leak the secret. I'd leave all that nitty gritty implementation to the pros, but that's the idea. I am a heavy user of secrets in my modules, and this extra layer of accidental leak-proofing would be greatly appreciated.

This is somewhat related to #4031, but I would like full type support for enums, mainly named field variants ```rs enum Birthday { Custom(String), // ? currently unsupported Date { day: u8, month: u8, year: Option<u16> } } ``` as well as tuple variants ```rs enum Birthday { Date(u8, u8, Option<u16>), ... } ``` both currently error with `must be a unit variant or a newtype variant` You *can* get around this by creating a struct and wrapping it as a newtype variant, but for types that will only ever be used as a single enum variant, that's not ideal. In my testing manually implementing the derive macro, sats seems to support named field variants just fine, and with only that change you can deploy to maincloud without issue, reads and writes all work, only the module codegen step currently fails. I haven't tested tuple variants, as I don't personally need them, they're just listed here to complete the type support.

SpacetimeDB feels like it could become one of the strongest backend layers for Web4: complex onchain apps, realtime games, autonomous agents, and agent-driven economies. As blockchains get faster and cheaper, more products will move ownership, assets, payments, and settlement onchain. But they’ll still need a fast coordination layer for world state, sessions, matchmaking, inventories, permissions, live feeds, and agent workflows. A Web4 integration kit could make this much easier: wallet identity, contract event syncing, transaction/reorg handling, scoped agent permissions, approval flows, action limits, audit trails, scheduled tasks, and polished examples for onchain games, marketplaces, DAOs, token-gated apps, and autonomous agents. The goal isn’t to make SpacetimeDB a blockchain. It’s to make SpacetimeDB the realtime application layer for the next generation of blockchain and agent-driven products.

Like this, but in all langs: ```rs #[spacetimedb::table(accessor = data)] struct Data { #[primary_key] #[auto_inc] id: u64, body: Vec<u8>, } #[spacetimedb::http::handler] fn insert(ctx: &mut HandlerContext, request: Request) -> Response { let body: Vec<u8> = request.into_body().into_bytes().into(); let id = ctx.with_tx(|tx| tx.db.data().insert(Data { id: 0, body: body.clone() }).id); Response::new(Body::from_bytes(format!("{id}"))) } #[spacetimedb::http::handler] fn retrieve(ctx: &mut HandlerContext, request: Request) -> Response { let id = request .uri() .query() .and_then(|query| query.strip_prefix("id=")) .and_then(|id| u64::from_str(id).ok()) .unwrap(); let body = ctx.with_tx(|tx| tx.db.data().id().find(id).map(|data| data.body)); if let Some(body) = body { Response::new(Body::from_bytes(body)) } else { Response::builder().status(404).body(Body::empty()).unwrap() } } #[spacetimedb::http::router] fn router() -> Router { Router::new().post("/insert", insert).get("/retrieve", retrieve) } ```

For better feeling on the local machine, almost every game implements some sort of local prediction about actions sent up to the server. Is there a current approach for doing that with SpacetimeDb? Or are there plans? It seems to me that the code for most reducers would be fine to include in the client. Then the client sdk could run the reducer against the local view of the db to predict how the db would change in response to that reducer call. It has some complexity, but solving this well would make this the defacto choice for multiplayer games. It's feasible to build that infrastructure myself, but I think it could be supported natively, probably better than a wrapping framework.