Hopefully this is not too much info for a single post.
And, hopefully I have been able to coherently organize my thoughts.
TL;DR version:
- existing #onboarding is either too cumbersome (full onboarding) or too restrictive (‘one-click’ onboarding)
- #affinity-groups are the ultimate key to expanding the #Hive user base
- affinity groups can also play a meaningful role in assisting with the onboarding process
- low-friction creation of new #front-ends (similar to #LeoFinance) represents the quickest path to explosive growth
The Onboarding Process
After learning about Hive a couple weeks ago, many of my students commented about the difficulty of the onboarding process (they felt that widespread adoption would remain elusive until that process becomes much more streamlined and seamless). This info is, of course, not new to the Hive community.
‘One-Click’ Onboarding via a Key Custodian is a Big Step in the Right Direction, but Remains too Restrictive
LeoFinance and #3Speak (and others, I presume) have done a good job making the onboarding process a lot easier (by automatically creating a newbie’s Hive account on their behalf, after simple email verification or via twitter login, then serving as ‘key custodian’ until that individual is ready to take control of their own keys).
Current Problems with ‘One-Click’ Onboarding
The problem with that approach (from what I can tell) is twofold:
- the individual cannot operate outside of the front-end where they were onboarded until they actively take control of their keys, and
- ‘one-click’ onboarding via one front-end excludes a new user from also using one-click onboarding elsewhere (unless they are willing to activate and use multiple Hive accounts -- one for each front-end).
As such, the ‘one-click’ processes currently in place unfortunately creates silo’d accounts that are only useful on a single front-end, thus severely limiting the new user’s ‘introduction to the ecosystem’ experience.
Affinity Groups: A Three-Fold Improvement Approach
I want to start by giving a shout-out to 
Prior to my conversation with
What Can be Done Immediately? Establish a ‘Community Organizer’ Badge
Imho, affinity groups represent the single biggest user-base expansion opportunity for the Hive ecosystem. We should encourage every new Hive member to create a new Hive ‘community’ centered around any topic (not currently on Hive) that is especially relevant to an affinity group the new member identifies with. As suggested in the heading, this encouragement could be accomplished via a ‘Community Organizer’ badge that gets awarded once a new member creates a community that attains a certain number of initial subscribers.
Two big advantages emerge from encouraging the creation of new communities by new members:
- once the new member has created a new community, there will be a natural propensity for that new member to try to recruit individuals from that affinity group to become Hive members and thus begin contributing both to the new community and to the overall Hive ecosystem. (NOTE: imho, a percentage of rewards for the posts within a given community should go to the creator / admin of that community -- this could be a system-level standard (i.e. posting within a community represents de facto acceptance that a portion of your rewards will go to that community’s creator), or simply applied as an added beneficiary to the default beneficiaries list), and
- a new member who creates a new community and recruits new users to Hive can (and likely will) actively help those new users navigate the full onboarding process.
Two Needed Improvements to Expand the Outreach Potential of Affinity Groups
Two additional improvements to the Hive ecosystem could facilitate expansion of the Hive ecosystem. Those two improvements are:
- enable nested (or linked) communities, and
- make it easier for new ‘LeoFinance’-type front-ends (i.e. ‘tribes’) to be created.
I will expand upon both of these proposed improvements below.
Enable ‘Nested’ Communities
Currently, (as best I can tell) each post can be associated with one and only one community. This seems to be a reasonable restriction (to keep posters from spamming all available communities). However, it could be advantageous to allow community admins to ‘nest’ other communities within their community. For example, I have recently created a community for a class I teach (Entrepreneurial Value Creation in Society). The community is Spring 2021 Seminar.
If I convince other faculty members (from my university or from other universities) to create similar communities, there would be a significant synergistic advantage for us to create a larger ‘University Communities’ community with each of our individual communities nested within the larger community.
I envision this added feature being accomplished by a couple of relatively simple revisions to the status quo.
- allow the admin of any community to ‘nest’ within their community whatever other communities the admin believes would be beneficial to its subscribers, and
- allow the admin to stipulate whether the posts from each ‘nested’ community are displayed flatly or in a hierarchical structure within their community.
Establish LeoFinance as a ‘Cloneable’ Model for New Affinity Groups
The way LeoFinance has been able to establish itself as a stand-alone affinity group (which, I guess is more correctly referred to as a ‘tribe’) is a testament in and of itself to the power of Hive as a decentralization powerhouse. We need dozens of similarly tight-knit autonomous tribes operating within the Hive ecosystem.
The way LeoFinance offers its own ‘One-Click’ onboarding, the way it utilizes its own rewards token and rewards-granting criteria, etc. make for an extremely attractive user portal for new tribes to mimic (e.g. external organizations who might migrate their own member activity to Hive, or entrepreneurial indidivuals seeking to create some entirely new ‘gathering place’ for a specific affinity group).
My naïve ‘wish list’ initially envisioned:
- a checklist of the features currently utilized by LeoFinance,
- a price-list identifying the cost associated with ‘cloning’ each specific feature, and
- a ‘Create Tribe’ button that would establish the new tribe, complete with landing page, token, customized rewards criteria, etc.
Little did I know (until my discussion with
As such, I am excited to be launching (with
Expand the Hive by encouraging and facilitating the creation of new communities and tribes!
UPDATE
With respect to onboarding, here is what I am planning to do with my students:
- Create one Hive account for each student (using a generic naming convention, such as “osu-xx”).
- Store the private keys.
- Distribute the ‘posting key’ to each student for his/her ‘classroom’ account.
- Because it is a key with limited capabilities, it should not require any more safeguarding on their part than their twitter password.
- At the end of the semester,
- encourage students to create their own personal Hive accounts,
- transfer any rewards they’ve accumulated to their respective personal accounts,
- reset the ‘posting key’ for each of the ‘classroom’ accounts (to reuse them next semester).
Anyone see any potential problems with this approach?
In similar fashion, the ‘one-click’ custodians could, during onboarding, store the owner key and active key while immediately distributing the posting key (and tell the user to protect it the same way they protect their twitter password). Then inform the user that they can retrieve their active key once they have rewards they want to manage and the owner key once they are ready to assume full control of the account.
