Group Onboarding Strategy - ecobankdevelopment.com
Setting Up ecobankdevelopment.com: A Walkthrough for HIVE Users
In my last post I explained what ecobankdevelopment.com is and why we built it the way we did. This post is the practical follow-up: how to actually set it up, from the perspective of an experienced HIVE user who wants to use it to onboard others or run a collaborative publishing account.
There are essentially two paths through the app, and they are designed to complement each other. The first is the path your new users will take — email signup, profile, drafts. The second is the path you take as the experienced user — importing a posting key, creating a group, managing who can do what. We will walk through both.
Step One: Sign Up and Profile
The entry point for everyone, including you, is email registration. After verifying your email, the first task is filling out a profile — name, bio, profile image. It is a familiar social media gesture that gives new users something to do while they are getting oriented, before anything blockchain-related enters the picture.
They can feel real forward progress here.
At any point from the profile screen, there is a button to purchase a HIVE account — but it is optional, and new users do not need to touch it to get started. That is the whole point.
Step Two: Setting Up Your Group (Experienced Users)
This is where you come in. A "group" in our app allows a HIVE account treated as a shared publishing resource. Create group in the "My Groups" page - but we also need to share a HIVE account. You bring the posting key; the app handles the rest.
Find Wallet Management in the menu:
You probably already have a suitable account if you have ever run a corporate or community blog or project account, that is the right mental model. If you have only ever used HIVE as a personal account, it is worth it to create a fresh one for this purpose with 3 HIVE or an Account Creation Token (ACT). You can use our account creation tool here: create-account.
Import the posting key for that account and your group is ready to configure.
Step Three: Permission Levels
Once the group exists, you can add other registered users to it. Each user gets a role, and the roles are meaningfully different:
- Owner — full control, holds the posting key (can see the posting key), can publish to the HIVE account.
- Moderator — can publish on behalf of the group (can use the posting key), can edit drafts.
- Editor — can edit and give direction on drafts, cannot publish.
- Member — can submit drafts for review, cannot edit others' work or publish, but can see drafts from other members.
In practice this maps cleanly to most real teams. In our @restore.world group, for example, I hold the owner role and retain publishing authority while my collaborators contribute drafts as members. I can see everything they are working on, leave direction, edit if needed, and publish when ready.
This structure is also where the onboarding value becomes concrete. A new user who has never touched HIVE can be added as a member, start writing immediately, and have their work reviewed and published by someone who knows the platform — without them needing to touch a key, manage resource credits, or know anything about markdown conventions on day one. You handle that for them while they find their footing.
Step Four: The Draft Workflow
With multiple contributors, version control matters. We have a system for versioned drafts that keeps everyone's work trackable:
Each time a draft is edited and saved, a new version is recorded. This means you can see the history of a draft, compare versions, and roll back if something goes sideways. For editors who are also teaching newer contributors markdown habits, tags, or word count expectations, this creates a natural feedback loop — propose, edit, review, publish — rather than a single high-stakes submission.
Based on user feedback, we also added the ability for members to propose edits to posts that have already been published:
This is useful for ongoing projects where posts function more like living documents than one-time publications.
Step Five: After Publishing
Posts published through our app are standard HIVE posts — they appear on Ecency, PeakD, and anywhere else that reads the chain. There is nothing proprietary about the output.
Two things happen specifically on our site after publishing. First, every post includes an About the Author section that pulls from the author's profile data — a simple, clean way to give credit to individual contributors writing under a shared account:
Second, all posts — including posts not published through our app — are readable on ecobankdevelopment.com via a clean, minimal interface with less noise than the full front-ends, which can be useful when you are sharing a post with someone who is not yet part of the HIVE world. The URL structure is simple and removes the tag:
https://ecobankdevelopment.com/@ecoinstant/we-built-all-22-of-these-tools-in-the-last-year
Myriad Secret Rules
One last thing worth naming directly. We all know that HIVE has developed a set of unwritten conventions around content — tag usage, word count, image sourcing, community norms — these things take time to absorb and are genuinely hard to communicate as a full set to a new user in the abstract.
The group structure gives experienced users a natural opportunity to act as editors in the traditional sense: reviewing drafts before publication and shaping them toward methods and mannerisms that actually perform and resonate on this platform. That knowledge transfer happens inside the workflow rather than in a separate orientation session that I have seen many new users forget before they need it.
If you give it a try, let us know how it goes. We are still actively developing the platform based on real usage, and the proposed-edits-to-published-posts feature is a direct result of community feedback. More of that is welcome.
Good morning
And thank you for your contribution in building hive