This total feature-set could become big later, but for now we will keep it as small as functional, like this:
[ ] Give learners a way to "invite" friends by email
[x] Give learners a way to search for their friends' in the registry of public profiles and "invite" them through that interface
[x] Give invitees a way to accept or reject the request
[ ] Give invitees a way to sign up for an account or link the request to an existing account
[x] Give learners a way to view pending requests, and cancel them
[x] Give learners a way to view accepted requests, and revoke access
At minimum this requires one or two tables for invites and responses, and probably a view or two to expose whatever they are allowed to see and what are pending requests and so on. We will try and avoid "notifications" in the app with "read" and "dismissed" states, and just keep it simple.
Maybe to pare it down a bit... we will only do invites via email, and then the email inbox can provide the "read/dismissed" affordances.
There are two possible entry points for inviting a friend:
a. Search public profiles: we know there's an account at the user's request time, but don't expose the email to the public web, so in a private action we look up the email and then send the "have account" invite email.
b. Invite-by-email form: we know the user's email but the client doesn't know if they have an account, so a private server action will check for accounts with this email, and if appropriate, send the "have account" email, else send the "invite new account" email
Then two different emails the helper friends may receive
a. Have account: this email contains a magic sign-in link which drops them on the "accept invite" page
b. Invite new account: this email provides a "sign up for sunlo" invite link which takes people to a signup form with some extra metadata or URL data to tie the signup back to this invite; if they click the "already have an account" link, the url data needs to come with them. after they have signed in or verified their email, they are dropped on the "accept invite" page
Accept invite: just 2 big buttons with accept/reject invite.
This total feature-set could become big later, but for now we will keep it as small as functional, like this:
At minimum this requires one or two tables for invites and responses, and probably a view or two to expose whatever they are allowed to see and what are pending requests and so on. We will try and avoid "notifications" in the app with "read" and "dismissed" states, and just keep it simple.
Maybe to pare it down a bit... we will only do invites via email, and then the email inbox can provide the "read/dismissed" affordances.
There are two possible entry points for inviting a friend: a. Search public profiles: we know there's an account at the user's request time, but don't expose the email to the public web, so in a private action we look up the email and then send the "have account" invite email. b. Invite-by-email form: we know the user's email but the client doesn't know if they have an account, so a private server action will check for accounts with this email, and if appropriate, send the "have account" email, else send the "invite new account" email Then two different emails the helper friends may receive a. Have account: this email contains a magic sign-in link which drops them on the "accept invite" page b. Invite new account: this email provides a "sign up for sunlo" invite link which takes people to a signup form with some extra metadata or URL data to tie the signup back to this invite; if they click the "already have an account" link, the url data needs to come with them. after they have signed in or verified their email, they are dropped on the "accept invite" page Accept invite: just 2 big buttons with accept/reject invite.