Secret or env special table

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:

[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.

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.

Requested by @Lethalchip via the SpacetimeDB site.

Start by examining the proposed /v1/database/:name_or_identity/secrets PUT/DELETE routes and the spacetime secret CLI command, along with the existing SQL-based secrets-table workflow described here. Define how secrets are created, updated, deleted, and protected from HTTP /v1/sql reads. Done means a built-in secret store and CLI/API flow that avoids declaring a private Secrets table and does not expose secret values through SQL routes.