vouched mode -- with invite DMs

Behavior

[x] activation / deactivation

GIVEN a broadcast channel not in vouched mode

• WHEN an admin sends the command "VOUCHING ON"
• THEN subscribers will not be allowed to join unless an existing admin or subscriber has invited them to join

GIVEN a broadcast channel in vouched mode

• WHEN an admin sends the command "VOUCHING OFF"
• THEN vouching is deactivated and anyone can join

[x] enforcing vouch requirement

GIVEN a broadcast channel in vouched mode

• WHEN a random person sends HELLO to the channel
• THEN the person receives a message saying Sorry! You must have an invitation to subscribe to this channel. Ask a friend to invite you!

[x] command discovery

GIVEN a channel (regardless of vouch mode)

• WHEN a subscriber or admin issues HELP
• THEN they will see a command listing for the INVITE +12223334444 command (explaining that it will send the person a message inviting them to the channel) and the ACCEPT and DECLINE commands (explaining that they accept or reject invites, respectively)

[x] sending invites

[x] to a new user

GIVEN an subscriber (or admin) alice of a channel (regardless of vouch mode) and a random person bob

• WHEN alice sensd an INVITE <bob's number> to the channel
• THEN alice receives a message that says Invite issued.
• AND THEN bob will receive a message saying You have been invited to join the <channel name> signalboost channel. Would you like to subcribe to announcements? Reply with ACCEPT or DECLINE.

[x] to a person who is already subscribed or invited

GIVEN a subscriber (or admin) alice of a channel #foo in vouched mode and a user bob who is subscribed to or already invited to #foo

• WHEN alice sends an INVITE <bob's number> to the channel
• THEN bob receives no message and no invite metadata is recorded
• AND THEN alice receives a message that says Invite issued.
  • NOTE: we do not inform alice that we did not invite bob to prevent side channel attacks that leak information about channel membership by trying to invite a known set of phone numbers and seeing which ones are already subscribed

[x] responding to invites

[x] handling accept from a pending invitee

GIVEN a pending invite from alice to bob to join #foo channel

• IF bob responds to invite message with ACCEPT
  • THEN he is added to the channel and receives a welcome message
  • AND THEN db records of the invitation are deleted
• IF bob responds with DECLINE
  • THEN he is not added and receives something like No worries! Check out signalboost.info if you're curious! :)
  • AND THEN db records of the invitation are deleted

[x] handling accepts without an invite

GIVEN a channel with vouching on

• WHEN an univited user sends an ACCEPT message
• THEN they receive an error response saying Sorry! You do not have an invite to this channel. As a friend to invite you.

GIVEN a channel without vouching off

• WHEN an uninvited user sends an ACCEPT message
• THEN they are subscribed to the channel as receive a welcome message

[x] invitation expiry

GIVEN a pending invite from alice to bob

• WHEN 1 week passes from the date that the invite was issued
• THEN the record of the invite is permanently deleted
• AND THEN alice is notified that one of her invitations expired

Implementation

data model

• add following fields to channel table:
  • vouchingOn (bool)
• create an invites table, with fields:
  • channelPhoneNumber
  • inviteePhoneNumber
  • inviterPhoneNumber
  • index: unique combos of channelPNum and inviteePNum

logic

• if vouching on, display INVITE command in HELP responses and handle INVITE commands
• INVITE commands cause an invite record to be created
• responses to INVITE commands
  • check invites table
  • notify inviter of response
  • delete the invitation record

Out of Scope

• implementing vouching thresholds is nice-to-have, and deferred until #137 (closed)
• we would prefer to implement this feature with one-time invite codes (as per proposal by @margot below) but defer that work to #119 in favor of shipping quickly
  • we prefer that approach because (1) it does not require temporarily storing invited users' phone numbers on the server without their having consented to use the service (and possibly stranding it there if they never pass invite threshold or accept invite), (2) it does not require a user to know another user's phone number in order to invite them, or use signal as the invitation channel (they could, for example use keybase, encrypted email, a piece of paper, or any other channel)
  • however, one time codes are complex, worth getting right, and will take longer to ship and some groups are blocked on using signalboost by lack of vouch mode
  • so we will ship with the invite DM method outlined above, then circle back to implement invite codes in #119