Help me design a decentralized version of hiveprojects.io

hiveprojects.io has been around for a while now, and it serves a simple purpose — listing projects built on the Hive blockchain. But the current model has some friction I'd like to talk honestly about, and I'm hoping we can figure out a better path together.

The current problems

Right now, hiveprojects.io is centralized in the most old-school way possible: someone submits a project, and I review and approve it manually. That creates a few real issues:

1. Verification takes time. I'm a bottleneck. If I'm busy, projects wait.
2. I feel personal pressure around scammy or suspicious entries. If something looks off, I have to make the call alone. I'm not comfortable being the single point of judgement for what's legitimate and what isn't — and honestly, that discomfort means I'd rather not review anything at all than risk approving something fishy. That might be a personal flaw, but it's the truth.
3. Vibecoded projects are hard to evaluate. More and more projects are AI-assisted, sometimes obviously so. Whether that's a problem is debatable — but verifying quality becomes even harder.
4. Not many people submit entries. The barrier to getting listed is just high enough that a lot of projects never bother.

The result? That pressure to judge has quietly made me avoid the task altogether — and hiveprojects.io has fallen behind because of it. The site is becoming outdated, not because I don't care about it, but because the current model puts me in a position I'm not comfortable being in.

What I'd like to figure out

I want to move hiveprojects toward a model where the community governs the content, not a single admin. I can handle the technical side — syncing data from the blockchain, keeping things fast, building the UI or the API. What I need help thinking through is the governance layer.

Here are the specific questions I'm hoping we can discuss:

1. How do you prove ownership of a project?

This sounds simple but it isn't. I can think of at least four distinct scenarios:

Claiming ownership of a domain or website. If someone submits a project and says "I own this", how do we verify it? One approach borrowed from the web: require a small verification file placed at the project's domain, containing the submitter's Hive public key or a username. If you can put a file on the server, you own the server. This is exactly how Google verifies domain ownership for AdSense — via ads.txt. We'd do the same thing but with a Hive-specific filename, something like hive.txt.

Ownership disputes for projects without a domain. Some projects don't have a website — a script, a library, a bot. There's no server to place a verification file on. So if @alice lists such a project and claims to be its author, and later @bob shows up saying "actually, I built that" — how do we handle it? Does the first claim win by default? Does it go to a community vote? Is there any way to resolve it without human judgement getting involved? This feels like the hardest case.

Submitting on behalf of someone else. What if @alice submits a project and says it was built by @bob? The confirmation mechanism is straightforward — a custom_json operation on-chain from @bob. But the more interesting question is: how does @bob even know a confirmation is waiting for them? The most natural answer is a notification on the website itself, visible after logging in. Should unconfirmed entries be hidden from the public listing until confirmed? And if @bob actively denies the claim, should the entry be hidden automatically?

2. Who can manage project assets?

Screenshots, logos, descriptions, links — who gets to touch them, and how? This also covers the question of who can update a listing once it's live. A few possible models:

• Owner only (the account that submitted and verified the project)
• Designated collaborators (a list the owner explicitly grants access to)
• Open edits with community approval — anyone can propose a change, but it goes live only after enough community votes approve it (like a Wikipedia edit queue)
• Website admins as a last resort for abuse cases

The open-edit model is the most decentralized, but also the most gameable. The owner-only model is safe but puts us back to a bottleneck. I'm genuinely unsure which is right here.

3. How should the community vote on visibility?

Instead of a single admin approving or hiding entries, what if the community voted? Some questions around that:

• Should it be stake-weighted (like Hive upvotes), or flat one-account-one-vote?
• What thresholds trigger hiding vs. removing vs. flagging?
• How do we prevent coordinated attacks on legitimate projects?
• Should there be an appeals process?

4. What features actually matter?

Before redesigning governance, it's worth asking: what do people actually use hiveprojects for? Is it mostly a category browser? A way to discover new tools? Are comparison features or "related projects" useful? I don't want to over-engineer something people mainly use for a quick list.

Drop your thoughts in the comments. Even half-formed ideas are welcome — this is exactly the kind of thing I'd rather figure out together than get wrong alone.

This post was created with the help of AI (redacted and formatted).