Feature Request: Stripe Connect but for Instant DB
vikeri opened this issue · 5 comments
Feature request: Stripe Connect but for Instant DB
BLUF
We’d like to provision Instant DB accounts and apps on behalf of our users, similar to how Squarespace can provision Stripe accounts and payments on behalf of their users.
Need
GPT Engineer lets you build and deploy a complete frontend app using only prompts (powered by LLMs). For adding persistence we today support a Supabase integration. This requires the user to go into supabase, create an account, and configure the schema and then use the API keys to Connect to GPT Engineer. This is great for users that already use Supabase or who want a lot of control. But many users don’t care about what a persistence layer looks like as long as it gets the job done and would prefer minimal friction. We believe that Instant DB could unlock this low friction use case if there was a way for us to programmatically create Instant DB apps on behalf of our users. We don't want our users to have to go to instantdb.com and sign up, we'd want to sign up for them, ideally without them needing to do anything.
Proposed solution
A couple of API endpoints (not exactly how they should look but something to start the discussion):
POST /users
curl https://api.instantdb.com/v1/users \
-u "our_secret_api_key" \
-d email=test@example.com
-d password=long_difficult_password
Returns
{
id: string;
email: string;
}
GET /users/<id>
curl https://api.instantdb.com/v1/users/<id> \
-u "our_secret_api_key" \
-d email=test@example.com
Returns
{
id: string;
email: string;
}
POST /app
curl https://api.instantdb.com/v1/app \
-u "our_secret_api_key" \
-d user_id="user_id" \
-d name="cool_app"
Returns
{
name: string;
id: string;
public_api_key: string; // The user's client side public API key
}
GET /app/<id>
curl https://api.instantdb.com/v1/app/<id> \
-u "our_secret_api_key"
Returns
{
name: string;
id: string;
public_api_key: string; // The user's client side public API key
}
Concerns
Validating users
One possible concern here would be the validation of users and their emails. We naturally have our users already validated so either we establish trust that way or we device some other way of establishing trust. Ideally we'd like to avoid the user having to re-validate their email again for example.
Giving users access to their Instant DB dashboards
We naturally would like the user to have access to their Instant DB dashboards just as a normal Instant DB user. This is straightforward if they are using SSO since then that login can just be reused. But if the user is using GPT Engineer with email and password we will likely need to ask the user to add an Instant DB password when creating the user.
Proposal # 2:
Enable claimable projects.
The UUID of claimable projects is secret. A person that knows the UUID can claim it. Once it is claimed it is editable by both the creator of the project and the person who claimed it.
Thanks for writing these up!
It sounds like the most important functionality is:
- You should be able to spin up an app easily, and associate it with a user (i.e. an email address)
- You should be able to programmatically give that user access to the app (either by transferring ownership, or by adding that user as a collaborator, or allowing apps to be "claimable")
Let me know if I'm understanding things correctly @vikeri @AntonOsika :)
Correct!
I think Viktor’s solution here is easiest to implement.
You would just need to store:
- user record field: api secret it was created with (optional)
- project record field: api secret it was created with (optional)
and verify api secret, on create project and edit project, if attempted by someone else than user
api secrets are given out after appropriate trust+contract is signed with third party
Let me know if I'm understanding things correctly
Yep!
Kicking this off here: #93
Will probably push updates incrementally, so you can start playing around with it asap!