![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
Invite codes on an alpha
(This was half-written but not posted yesterday. Here it is in all it's technical "glory" today.)
kokoinai and I have been talking about how to manage the LifeThunder.com alpha; specifically, how do we (a) make people want to try it out and (b) prevent too many people from seeing it while it's still in a (to be polite) "unfinished state" (*). Obviously, problem (a) is more likely to be an issue, but (b) matters as well.
Two words: invite codes.
Invite codes make people feel like they are special, like they are being let past the "velvet rope" to play with the Cool Kids. (At least, so goes the theory.) They also make it easy to control how many people can access the site.
Of course, implementing an all-up invite code system is a bother. You need to add the relevant tables to the database, track the code, delete them from the table correctly (watch out for race conditions!), hand them out to new users, etc, etc. That's a lot of work for a feature that we're only going to use while in alpha, and then will rip out forevermore. So I thought for 60 seconds and said "Forget that." In about 10 minutes I knocked up something where, when a person tries to register, it asks them for an invite code, checks to see if there is a file with that name in a particular directory and, if so, it deletes the file and lets them in. Modulo a few typos and such, it worked the first time out the gate. I then spent another 50 minutes or so testing and handling edge cases ("what if they submitted an invite code that was a relative path--could they escape up out of the directory and then nuke, for example, the system password file?" or "is there any way to submit a string that will be executed?" [answer to both of these: no, you can't]).
Ah, but I can hear you cry out: "But wait, Dave! How will people get the codes? How will new users invite their friends? What about logging which user signed up with which code? What about race conditions on checking existence of the file before you delete it? What about...?" To all of these I say: "this is an alpha-only feature."
Users will get invite codes because we send them an email that says "Hi there, in our market surveys, you expressed interest in the site. If you'd like to join, here's your invite code. And here's a half-dozen others in case you have some friends that want to join."
As to race conditions on checking before deleting files: meh. This is unlikely to happen at all--how did two people end up with the same code? But, if we get a false positive, it only means one extra person in the alpha: no problem. If we get a false negative (e.g. we gave two people the same code, so one of them is refused for a code we told them was valid)...well, that's a little more serious because we told them the code was good. But it's unlikely enough that I don't care to code for it--we can handle it via email in the unlikely event that it comes up.
Bottom line: we're a startup, and this is a short-term feature. The 20/80/110 rule (**) applies.
(*) More commonly known as "looks horrifically ugly and we're still working out bugs".
(**) Most people are familiar with the 80/20 rule and know that it derives from the Pareto principle. (Yes, I'm aware that Pareto never actually said this, he said something that involved a lot of math and other people boiled it down.) In the context of a startup, however, it's better to think of it as the 20/80/110 rule: Outside of the core, do only 20% of the work to get only 80% of the benefit. Inside of the core, do 110% of the work to get 110% of the benefit.
kokoinai and I have been talking about how to manage the LifeThunder.com alpha; specifically, how do we (a) make people want to try it out and (b) prevent too many people from seeing it while it's still in a (to be polite) "unfinished state" (*). Obviously, problem (a) is more likely to be an issue, but (b) matters as well.
Two words: invite codes.
Invite codes make people feel like they are special, like they are being let past the "velvet rope" to play with the Cool Kids. (At least, so goes the theory.) They also make it easy to control how many people can access the site.
Of course, implementing an all-up invite code system is a bother. You need to add the relevant tables to the database, track the code, delete them from the table correctly (watch out for race conditions!), hand them out to new users, etc, etc. That's a lot of work for a feature that we're only going to use while in alpha, and then will rip out forevermore. So I thought for 60 seconds and said "Forget that." In about 10 minutes I knocked up something where, when a person tries to register, it asks them for an invite code, checks to see if there is a file with that name in a particular directory and, if so, it deletes the file and lets them in. Modulo a few typos and such, it worked the first time out the gate. I then spent another 50 minutes or so testing and handling edge cases ("what if they submitted an invite code that was a relative path--could they escape up out of the directory and then nuke, for example, the system password file?" or "is there any way to submit a string that will be executed?" [answer to both of these: no, you can't]).
Ah, but I can hear you cry out: "But wait, Dave! How will people get the codes? How will new users invite their friends? What about logging which user signed up with which code? What about race conditions on checking existence of the file before you delete it? What about...?" To all of these I say: "this is an alpha-only feature."
Users will get invite codes because we send them an email that says "Hi there, in our market surveys, you expressed interest in the site. If you'd like to join, here's your invite code. And here's a half-dozen others in case you have some friends that want to join."
As to race conditions on checking before deleting files: meh. This is unlikely to happen at all--how did two people end up with the same code? But, if we get a false positive, it only means one extra person in the alpha: no problem. If we get a false negative (e.g. we gave two people the same code, so one of them is refused for a code we told them was valid)...well, that's a little more serious because we told them the code was good. But it's unlikely enough that I don't care to code for it--we can handle it via email in the unlikely event that it comes up.
Bottom line: we're a startup, and this is a short-term feature. The 20/80/110 rule (**) applies.
(*) More commonly known as "looks horrifically ugly and we're still working out bugs".
(**) Most people are familiar with the 80/20 rule and know that it derives from the Pareto principle. (Yes, I'm aware that Pareto never actually said this, he said something that involved a lot of math and other people boiled it down.) In the context of a startup, however, it's better to think of it as the 20/80/110 rule: Outside of the core, do only 20% of the work to get only 80% of the benefit. Inside of the core, do 110% of the work to get 110% of the benefit.