If you are reading this, you probably already know how to use HIVE. You know about Keychain, about resource credits, about the difference between a posting key and an active key. You have probably even tried to explain some of this to a friend or colleague, in a process we refer to as "onboarding", and watched their eyes glaze over somewhere between "so it's like a wallet, but also a social media account" and "wait, I need to keep this password somewhere safe forever?"
This post is not for that friend. This post is for you.
We want to explain what ecobankdevelopment.com actually is, why we made some decisions that will look strange to experienced HIVE users, and whether you should trust it enough to recommend it to the people in your life.
"What It Is"
ecobankdevelopment.com is a HIVE front-end with two distinct but related purposes.
The first is onboarding. We want to be able to take someone who has never heard of HIVE, give them a reason to start publishing content, and get them doing it before the friction of wallet setup loses them forever.
The second is collaborative publishing. We treat HIVE accounts as shared resources - meaning a team, an NGO, a project, a family - can all contribute drafts to a single HIVE account, with proper editorial controls over who can actually publish.
These two things might seem unrelated, but they share a common root: the assumption that most of the interesting use cases for HIVE involve more than one person, and that the tooling has never really reflected that.
Why Email Login
We know. It feels like a step backwards.
But we all know what we keep running into: the gap between "I told my friend about HIVE" and "my friend is actually posting on HIVE" is enormous, and it is not because people are uninterested. It is because the onboarding asks them to make security decisions they don't have context for precisely before they have any reason to care.
Email login lets someone make a profile, join a group, write a draft, and feel like they are participating - before they have ever touched a wallet. At any point they can buy or create a HIVE account and connect it. We are not replacing the wallet. We are just not leading with it.
If you are experienced enough to be skeptical of this decision, you are also experienced enough to see its logic from the outside, even if you would never personally need it.
The Posting Key Question
This is the one we need to address directly, because it is the legitimate hard question.
When you add a HIVE account as a shared resource in our app, you are importing a posting key into a web application. That is a real trust decision. The posting key cannot touch your funds - it can only publish content on your behalf - but it is still a key, and you should know what you are doing with it.
Our model is: you should only do this with accounts you are already managing actively, and ideally accounts that exist specifically for collaborative or project publishing. We would not recommend importing the posting key to your main personal account unless you understand and accept the tradeoffs. The right mental model is closer to "I am giving my team access to our project account" than "I am handing over my wallet."
We are not going to pretend there is zero trust involved. There is. What we can tell you is that the architecture permits you to limit the blast radius to posting permissions only, and that we built this tool because we needed it ourselves for exactly this kind of collaborative work, including onboarding.
Who It Is For
Honestly? It is for the person who has been trying to get their community, their NGO, their content team, or their family onto HIVE for a while now, and keeps hitting the same wall.
It is for the experienced HIVE user who wants to run a shared account without sharing their password with everyone, and wants some editorial oversight over what gets published under that account.
It is not really for solo HIVE power users who already have their workflow dialed in. You will certainly find it too simple. But you might find it useful for the next time someone asks you how to get started.
What We Are Not
We are not trying to replace Peakd or Ecency. We are not trying to be a full-featured front-end. We are trying to solve a specific problem - the onboarding gap and the collaborative publishing gap - and stay out of the way for everything else.
All posts published through our app live on the blockchain like any other HIVE post. They show up on every front-end. We are just one door into a house that has many doors.
If any of this sounds like something you have been looking for, my next post walks through exactly how to set it up - so like and subscribe as they say 🤣