Implicit accounts, similar to ones that Ethereum and Bitcoin do. They don’t exist on-chain until someone actually sends some $N to them. They are not usually super useful for applications because user doesn’t have any $N to spend on gas.
“Named” accounts, which require an actual registration. This registration currently done via calling a function on .near account, which requires that whoever creates it already has a NEAR account. “Named” accounts have a benefit of having a readable name that people can recognize when they are using apps and sending funds. At the same time, they require right now a bit of “dance” to create as exchanges and other tools outside of NEAR Wallet don’t support their creation.
Proposal
Let’s create a faucet that allows people to create “named” accounts.
This requires solving “Sybil” problem, as such faucet will be funding this accounts with some $NEAR.
There are next options to provide good enough solution:
Using Github and various ways to identify if this account is legit. For example age of the account and that it has been active. There are existing systems that try to evaluate how real a Github account is.
If user wants to use specific app, an account with an access key for only that app can be created. Faucet will keep the full access key, pretty much making sure that funds are not abused (outside of just sending a lot of transactions to the given app). If user wants to grab their account, they should get more funds into the account (e.g. receive from someone else) and then ask faucet to withdraw it’s initial funding & delete full access key.
There are two major user flows:
A specific faucet website, which have few of the above options to initiate account creation. It checks that this is indeed a valid person and that they haven’t already used this faucet. After that, it create a “near drop” and redirects them to wallet.near.org to finish creating an account.
Any app can integrate a piece of JS with the same “create account” options that hit the same backend which create a “near drop” and redirect to wallet.near.org + allow to authorize this specific in nearly created account before redirecting back.
It’s important to highlight that this will be a temporary faucet, meaning that app developers should not rely on that continuously.
One alternative to simplify this, is to integrate this faucet directly into wallet.near.org right now.
I really believe in this idea and feel it is needed. Would this be better served by the guilds or validators hosting this service? In that way there would be some level of connection to the ecosystem. I had thought about a giveaway for the guild or staking pool.
One more thought would be to partner with exchanges to provide the accounts to their users through a special URL.
This would provide a level of filtration and ensure that the individual was connected to the community. However, if the purpose is mass adoption it may to work.
In addition to the proposed GH validity check, another way is to ask for a Keybase acct with a min of 3 or 4 verified profiles. Because the person might not have an active or a GH account at all.
But here is my main suggestion: partner with a couple of exchanges, and have them offer their KYCed users an option to create a NEAR account and receive a small amount of NEAR. This would probably works wonders for marketing/awareness, and Sybil resistance is baked in already. I wouldn’t even say just partner with the larger exchanges, allow any exchange that trades NEAR to offer this. You might get some ppl that have accounts at multiple exchanges end up with 5x the faucet amount after registering at 5 exchanges, but I think it is a small price to pay for having these many ppl become aware of NEAR. Think of it as Customer Acquisition Cost.
I get that the above is not in line with the original intent of the proposal, but it is something to think about.
Great proposal.
I also thought about similar faucet which will help for those who bought ENS addresses (name.eth) to get corresponding accounts in NEAR for free. So in addition to github/keybase verifications we can use true onchain proofs.
I think this is a great idea! Anyone who has already paid/shown commitment to buy an ENS address could get a NEAR account (ideally same name). Pretty sure there are ways to get the ENS account holder to sign a message and use that info to authorise creation of a NEAR account for them!
Re the exchange idea, this could be a co-promotion campaign where we “airdrop” NEAR accounts (in a way that they can pick their own name) to all users or $NEAR traders of an exchange. I bet there are thousands of traders who have NEAR but no NEAR account!
@StefanoPepe 's idea/approach relies on Twitter for sybil resistance. I like Twitter more than Github because of its potential for virality. There was a short lived UBI project which got tons of attention through asking people to verify with their Twitter accounts!
