🥔✨ Space: Invitations

[zspencer]

Use Cases

• 🥔✨ Invite Member to a Space via Email
• 🥔✨ Viewing Invitations to a Space
• 🥔✨ Revoking an Invitation
• 🥔✨ Accepting an Invitation
• 🥔✨ Ignoring an Invitation
• 🥔✨ Responding to a Previously Accepted Invitation
• 🥔✨ Responding to Expired Invitation
• 🌫️ Space: Invitation by Link

Bugs

• 🐛 Invitations and People: whitespace in email addresses gets saved to the database, preventing us from identifying Members #1607
• 🔨🐞 Invitations are not being Delivered (May 23rd 2023 12PM PT to May 26th 2023 8PM PT) #1515

[anaulin]

I don't know what the right solution is here -- we probably want to be careful about not "leaking" the name that someone uses in one space to other spaces -- but it would be nice to also streamline the invitation experience if that person already has an email in the neighborhood.

I definitely worry about "leaking" PII into one Space based upon a Person in another Space; and lean towards preserving that boundary over convenience.

That said, it could be nice to bypass all that by adding a use case for Invitations to have usage constraints (use 1x, expires at Y) rather than requiring contact information.