The three minute Hive Onboarding Solution we need
We had a great show, a great conversation today on Hive's Discord. I have to say, I was surprised to hear my brother @joseamenac speak so much, but then again, we used to share a stage together, so I don't know why I'm so surprised. That said, after sharing with everyone some of the future plans we have for @snapie, I think I have a clear north star to point to now.
It was @vaultec who first mentioned it, but today @raymondspeaks brought it up again and dropped "the link" in the chat. Magic link? I thought. Oh, this is the bridge—the bridge I've been thinking about. It's already built. Of course, I had to wait until after the show to do some digging, but what I thought I would find wasn't really there.
Turns out that Magic Link does solve a bunch of onboarding issues. If I was building a dapp on Ethereum, for example, I don't think there would be a better way to build it than using their SDK. That said, they don't support Hive, at least not currently.
So what is this Magic Link? What does it do? The easiest way I can describe it for the people in the back is this: They do the hard part for you. In other words, people can login with their Google accounts, with their email, a bunch of options, and their SDK handles the signing of transactions.
To me, this sort of bridge is precisely what is needed for the mass adoption of cryptocurrencies. A soft transition, if you will, for those who still don't get the need to own their keys but feel too intimidated to even dip their toes in the deep end of the pool. It's a way to get them to walk through the door.
The way I see it is this: Maybe, and I'm not saying it has to be me, but it could be—we should reach out to Magic Link and talk to them about adding Hive to their supported chains. To me, this makes a lot of sense. They've already built the machine; we just need to tweak it to our tooling, so to speak. But of course, that particular conversation, if it ever happens, cannot be predicted. They might not be interested at all, or worse, demand an unreasonable amount of money for such integration.
I'm thinking that maybe, just maybe, we should build our own magic link. A Hive Link. The name even has a good ring to it, I have to say. Not to pat myself on the back. But the thing of it is, and I hope this is clear: WE NEED THIS. This is not me being ridiculous or exaggerating, but a new user's onboarding needs to be 3 minutes tops. That is how fast it has to happen. I'm serious as a heart attack right now.
But to paint the picture, let me write some pseudo code—an idea of what it could look like for a dev if we were to build such a thing. For those of you who don't code, this might not make sense, but I'm sure you'll see the value in what I'm describing regardless.
// Import our imaginary SDK
import { HiveMagic } from "@hive/magic"
// Initialize with project credentials
const hive = new HiveMagic({
clientId: "my-dapp-id", // issued by our HiveMagic backend
apiUrl: "https://api.hivemagic.io"
})
// 1. LOGIN WITH MAGIC LINK / OAUTH
async function login() {
const user = await hive.loginWithGoogle() // or hive.loginWithEmail("[email protected]")
console.log("Logged in as:", user.username)
console.log("Session token:", user.token) // JWT or similar
}
// 2. GET USER TOKEN
async function getToken() {
const token = await hive.getSessionToken()
console.log("Current token:", token)
}
// 3. UPVOTE A POST
async function upvote(author, permlink, weight = 10000) {
const tx = await hive.vote({
voter: await hive.getUsername(),
author,
permlink,
weight // 10000 = 100% vote
})
console.log("Vote transaction broadcast:", tx.id)
}
// 4. REPLY TO A PARENT POST
async function reply(parentAuthor, parentPermlink, message) {
const res = await hive.comment({
author: await hive.getUsername(),
parent_author: parentAuthor,
parent_permlink: parentPermlink,
body: message
})
console.log("Reply transaction broadcast:", res.id)
}
// --- Sample Flow in App ---
async function runDemo() {
await login() // login
await upvote("ned", "hello-hive-world", 5000) // 50% vote
await reply("ned", "hello-hive-world", "Nice post!") // comment
}
runDemo()
Simple and beautiful
What would this solve, I hear you asking? Why should you care? Allow me to defend my position, please. This imaginary SDK, the one we ought to build, would allow all Hive dapps to integrate Web2 logins easily, and that would convert to one thing: Easy Onboarding.
You see, in the end, it's all about that. If it's too hard for people to do, they just won't do it. That's how life works, and although we may have idealistic notions about merit, we need to operate in reality.
The Backend is the Magic
In this system, the one I'm dreaming about, the one I'm sharing with you all, all the heavy lifting would be done by the backend. The complexity of Web2 users interacting with Web3 would effectively be outsourced to the backend, but the hard work, the heavy lift, would have to be done only once.
This means, of course, the backend would work just like Magic Link does. It would store keys for new users, and it would also allow dapp deployment. In other words, for dapp operators to set up their accounts, maintain their users, and tweak their preferences. Yes, we are talking about a custodial system, but it would not be the dapps doing the custodial part, and that is key.
Things to consider
My friend @mengao mentioned a simple tweak that would possibly help us move people in the right direction. Maybe the dapps could be built to not allow Web2 accounts—accounts that are not emancipated, that are held by Hive Link—to operate past a certain valuation.
What if you are forced, and guided through your emancipation, after you reach 50 Hive Power or something like that? That way a new user would have enough time to get somewhat acquainted with things, have a little bit of the stew, before he or she decides they're ready.
Again, the goal is not for this hypothetical Hive Link to be holding millions of Hive—that would be anti-crypto. The goal here is to ease the jump, to remove some friction, to change minds.
To conclude
Like many ideas that kick cans inside my head, this is one that has been making noise for weeks now. Only today has it taken a shape I can recognize, to the point I think it's very much feasible.
If you ask me, we should be building this. And by "we" I do mean we. This is something I would love to see show up in DHF.
I'm not going to sit here and tell you guys "I'm on it!" because we first have to finish the things we started. But honestly, this is one of those ideas I would not mind someone stealing from me. As a matter of fact: Please do!
MenO
Here's a thought -- maybe we wont need to do anything? :)
With what Vsc are bring to the table in the future -- perhaps we'll be able to "bolt on" to them :)
I've not talked to vaultec yet, maybe he built a custom sdk or something.
Wax (the fork of EOS) had its cloud wallet do exactly what you describe. For more advanced functions, you'd need to use a custodial wallet, but you could convert from a cloud wallet to a self-custodial wallet at any time.
it just makes sense to do this.
@ecoinstant and I have tried to bring something like this in the past. It was what
lootkit
was originally, twitter logins for hive (we never built past twitter, but planned on many of them), easy on-boarding has been on mind a LOT over the years.Oh wow... yes. twitter logins, facebook logins... those would be amazing
Ohh I missed the show again… I guess I’ll have to unmute the server so I don’t miss these meetings. The idea sounds good by the way, I’ll analyze it better because it’s 4 in the morning lol
i uploaded it... the audio is not amazing, but its there. hahahah
The main thing that I'm encountering is the keys. People are confused by them. I'm doing quite a few steps now to create an account and make it work, so yes, having it all in one dapp would be a lot better. I didn't quite understand the code, and maybe I missed the point, but for onboarding, I imagine it like this:
New user downloads keychain and creates an account. Through keychain, they can now create a HIVE account by either scanning a QR code from the patron or typing in their username. The account is created, and the keys automatically loaded into keychain. Also automatically, the patron gets a request to delegate 10B RC (or a similar amount) to the new account, to allow them to start.
Done. Account created with web2 easiness, but still with a barrier against bots, as the patron must sign off. I don't have to explain neither keys nor RC nor HP nor anything. They might learn it eventually, hopefully. And of course, I'll encourage them to learn :-D
The code is more for the nerds, but, the idea is probably best expressed differently. Maybe its best I paint a possible scenario.
You go into your app store, google or apple, and you see Snapie - Chat with people around the world, make friends, earn crypto. You download this app. You know nothing.
You see: Login with Google.
You walked through the door.
Right now... people would download the app, see: Enter POsting key only. Their face like those confused puppies. sideways look
Ideally the best onboarding happens one to one, but its not as fast. It scales if you make more of you, more onboarders, but no onboarder on his/her own hasd the reach of an app store.
That's true, but it brings more opportunity to bots creating accounts to spam and drain the pool, as you just saw in the screenshot you sent me on WA. That is a real problem that has to be addressed and at least hindered. Wherever there is "free" money, the scammer come.
Hello meno!
It's nice to let you know that your article will take 6th place.
Your post is among 15 Best articles voted 7 days ago by the @hive-lu | King Lucoin Curator by keithtaylor
You receive 🎖 0.5 unique LUBEST tokens as a reward. You can support Lu world and your curator, then he and you will receive 10x more of the winning token. There is a buyout offer waiting for him on the stock exchange. All you need to do is reblog Daily Report 783 with your winnings.
Buy Lu on the Hive-Engine exchange | World of Lu created by szejq
STOP
or to resume write a wordSTART