Invite codes for access

[yoavartzi]

Let's generate invite codes to provide people access.

An invite code is a long combination of numbers/digits that is randomly generated, eg: hf95-2h30-dj35s-38oc

We retain the set of invite code in the database, with the following fields for each entry:

• Invite code
• Who it was issued to
• Date/time of issue
• If it was copied (we will use this later when we release them through the interface)
• If it was used
• Who used it
• When they used it

When a new user join the system they follow this flow:

1. They login with Google for the first time.
2. We ask for an invite code
3. If they provide a valid invite code (ie: it's in our database, and hasn't been used), they have access to the system and are dropped on their profile edit page (https://github.com/lil-lab/rec-net/issues/8). We also update the invite code entry in the database.
4. If they don't have an invite code or enter an invalid one, they are just stuck on the "enter invite code" page

When the user logins to the system next time:

1. If they passed the invite "test", they get into the system
2. Otherwise, they are asked for an invite code

Generating invite code: At this point, we should generate invite codes and distribute them manually. In the near future, we will build a mechanism to give them to existing users via the interface or emails.

This is an alternative for the email whitelist #9, which I am closing.

[yoavartzi]

@anya-ji can we prioritize this? Once we have the system controlled behind invite codes, I can show it to other folks to prepare the next batch.

[anya-ji]

Sure! I'm almost done with #50, and I'll start this right after

[anya-ji]

Just to clarify, the invitation code check should happen before the welcome screen (where they enter their username, i.e. register for recnet) right?

[yoavartzi]

When they sign with Google, we create a DB record for them with the authkey. Right? This is not something we plan to block. What happens after that?

[anya-ji]

Yes, after that they will see a welcome screen where they create a username (i.e. register for recnet, since the profile page uses the username in the URL, each active recnet user has to have a username from the beginning), so I'm wondering if we want the users to be able to create username before or after they are invited?

[yoavartzi]

It's probably best that they first have to put an invite code, and only then can create a user name. So no user name without invite code.

So if they don't have an invite code, we do retain their authentication info, and they may return in the future, but will asked the invite code again.

Do you think that will work?

Thanks!

[anya-ji]

Of course! It doesn't matter for implementation but I'm just wondering why we would want to retain their authentication info before they have an invitation code (there could just be a lot of random accounts from whoever clicks on the sign-in button stored in the database)?

[yoavartzi]

That's actually a good question. I guess I assumed we create a record on the Google side when we do this, so if we do it every time they try, we will create many records in their Google account and that will look messy to them. But actually I am not sure what we do on the Google side. Any idea?

Another consideration is that it's basically a way to harvest emails. So when we remove the need for invite codes, we can just email all existing account that don't have access and invite them. What do you think?

[anya-ji]

Ah I see. Based on our current implementation, Firebase Authentication will automatically retain every logged in user's account information, and we store a copy of that + additional fields (e.g. randomization seed, followers etc.) in the database. If we want to save the emails for later, I think we can just keep the Firebase Authentication part ("logged in" with Google auth, but not actually logged into the app), but we don't store them into the database until they have an invitation code?

[yoavartzi]

Sounds good. Thanks!

On Tue, Nov 7, 2023 at 17:46 anya-ji @.***> wrote:

Ah I see. Based on our current implementation, Firebase Authentication will automatically retain every logged in user's account information, and we store a copy of that + additional fields (e.g. randomization seed, followers etc.) in the database. If we want to save the emails for later, I think we can just keep the Firebase Authentication part ("logged in" with Google auth, but not actually logged into the app), but we don't store them into the database until they have an invitation code?

— Reply to this email directly, view it on GitHub https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flil-lab%2Frecnet%2Fissues%2F17%23issuecomment-1800318501&data=05%7C01%7Cyya5%40g.cornell.edu%7C6c869351d0704344061c08dbdfe35233%7C5d7e43661b9b45cf8e79b14b27df46e1%7C0%7C0%7C638349939661190220%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RDTrYkZTbUBBbfvviJpGgFde%2FA8IUDmx2RQ73pJs5mw%3D&reserved=0, or unsubscribe https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAZDGEKXXYNB54SBYD6LIPTYDK22TAVCNFSM6AAAAAA6JLU3DWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBQGMYTQNJQGE&data=05%7C01%7Cyya5%40g.cornell.edu%7C6c869351d0704344061c08dbdfe35233%7C5d7e43661b9b45cf8e79b14b27df46e1%7C0%7C0%7C638349939661346474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UHdnLWeBs9YerzmPWhOf7YBMRdbgqp%2Fzy2yzByfZbpo%3D&reserved=0 . You are receiving this because you authored the thread.Message ID: @.***>

[yoavartzi]

@anya-ji , once you have this implemented, can you send me a 1000 invite codes via email/shared private spreadsheet? Thanks!

[anya-ji]

Yes, will do!

[anya-ji]

If it was copied (we will use this later when we release them through the interface)

What is the copied field for exactly? (What is "releasing through the interface"?)

[yoavartzi]

At some later point we will release invite codes to existing users via the interface. For example, this is how BSky does it:

When you copy on BSky using the interface, they mark it as copied, and later when it's used as "consumed"

Makes sense?

Thanks!