JoinColony
Support Reputation bootstrapping via email
As discussed today in Product Sync, we would like to allow colony owners to invite users via email, and give them reputation.
After working through a few ideas, we seem to have settled on the following design:
- A colony admin inputs a list of user emails and the amount of reputation to bootstrap.
- A
Bootstrappingextension receives arrays ofsha256(pin)and reputation amounts. - Users receive emails containing their pin, and given a link to the onboarding process.
- After onboarding, the users can submit their email and pin to claim the reputation.
Incorporating pins makes the process secure -- the admin uploads the hashes, which cannot be reverse-engineered without knowing the email addresses and the pins. As long as the email accounts are secure, then only the users should be able to claim their tokens.
Pin generation should take place in the client, which then sends the email and configures the extension. The pins should never have to be stored or transmitted publicly.
@arrenv to clarify, is this feature meant to give both tokens and reputation, or reputation only?
@arrenv to clarify, is this feature meant to give both tokens and reputation, or reputation only?
It is meant to do either. So, if they have created their token via Colony, then tokens and reputation. If they are bringing their own token, then reputation only is more fitting.
@arrenv I'm not sure I understand this distinction. I had imagined an implementation where tokens are sent to the bootstrapping extension, which then sends tokens & reputation to the user. So it doesn't really matter whether the token is BYOT or created via the colony, as long as the tokens can be sent to the extension.
My suggestion would be to send tokens to the user if tokens are held by the extension, and to give reputation only if not. This way a colony can decide whether or not to give tokens along with reputation by sending tokens to the extension (or not).
@kronosapiens Good point, it doesn't need to explicitly be whether they bring there own token or not. But in the UI we were trying to simplify the process. They should be able to give tokens if the bring their own token.
So, I like your solution for the extension. Then we can account for it in the UI.
@arrenv if there are insufficient tokens available, should the user receive the amount available, or should the function return an error? I ask because the implementation I'm considering involves transferring tokens if the contract has them, and only giving reputation if not. But in the case where there are only some tokens available, what should we do? Transferring the balance is simpler, but I recognize might not be the best experience for a user. Essentially I am saying it is up to the colony to ensure sufficient funds are available.
Another approach is to have a boolean parameter which explicitly toggles whether or not tokens are meant to be transferred. It would make for a slightly more complicated implementation (but not by much). In that case, I would say we should return an error if the tokens are not available.
@kronosapiens Based on my understanding of providing reputation and tokens if there are funds available in the extension, otherwise only provide reputation. I would assume that the funds would need to be transferred to the extension when the person is creating the bootstrapping. Which, would mean there should be no case where there are not enough funds available in the extension. Unless I'm misunderstanding something.
In the edge case where they are not enough funds available, then returning an error would be fine.
@arrenv another product question is how to implement reputation decay, if at all. The idea is that the reputation given begins to decay as soon as it is submitted, so that there is an incentive to claim the reputation as soon as possible (or rather, there is no incentive to delay claiming the reputation). Is this an important feature to implement? It'll add a non-trivial amount of complexity to the extension, so I'd like to know how much of a priority it is.
My opinion on this is that it makes more sense that reputation decays as soon as it is submitted.
So, as an example, if two people got paid 100 each, if one claimed right away they would have 100 tokens and 100 rep. It decays for 1 week and they would have 100 tokens and 98 rep. The second would claim at 1 week mark, they would receive 100 tokens and 98 rep.
There is a hiccup in that approach, in that we may run into gas limits if the user waits a very long time to claim their tokens. Is some amount of approximation an acceptable compromise?