The 1Hive preview is a testnet coordination app for the 1Hive community.
It is forum-shaped on purpose: swarms, posts, comments, votes, challenges, and public cases. That first milestone matters on its own. 1Hive needs a real place to gather, make decisions, and see moderation happen in public.
It is also how we test the deeper work in real use. The same flows that help a community coordinate today can become the base for curation, moderation, automation, escalation to human review, and eventually a governed data commons.
The larger direction is the 1Hive Commons Protocol: a community home for knowledge work that can grow from swarms and covenanted profiles into shared canon, versioned tools, and clear terms for how commons data is used.
Here is what is in the preview today.
Swarms
Swarms are focused workspaces. Each swarm has a name, a URL slug, a description, and moderation guidelines.
A swarm is first a community space. Over time, a swarm can also become a place to gather and review a specific kind of data. The important first question is “can people coordinate here?” The next question is “what can this group collect, improve, and trust?”
That is why swarms come before the more abstract protocol layers. A commons is not useful because it has a name. It is useful when people can gather around a subject, set expectations, improve shared context, and see how disputed work is handled.
Contributions and feeds
The preview supports the basic contribution loop:
- a feed from swarms you follow;
- an all-posts feed for discovery;
- link posts and text posts;
- comment threads for context and review;
- voting for lightweight signal;
- profiles and activity for public participation history.
These are early building blocks. They make the preview useful to the community now, and they give us a place to test more deliberate commons work later: generated examples, proposed labels, source checks, annotations, duplicate detection, shared canon, and review queues.
Profiles are part of that foundation. Over time, profiles should carry more than activity history. They can express covenants, community commitments, and human validation when the work depends on identity or eligibility.
Lightweight signal
Voting uses Buzz.
Buzz is a voting resource, not Honey. It is meant for lightweight signal: what seems useful, what needs attention, and how strongly someone feels about it. Honey is reserved for actions with consequences.
That separation is deliberate. Everyday signal should stay easy. Challenges, appeals, and review work should feel more serious.
Honey-backed challenges
The preview uses Challenge, not Report.
When someone challenges a contribution, they are not sending a private complaint to a moderator. They are starting a public review process. The app opens a side panel that explains what is being challenged, why Honey is involved, what happens next, and what the possible outcomes are.
After a challenge is submitted, the app creates a public case. The challenged contribution is marked or hidden depending on its state. The author can respond. Others can follow the case. The record stays visible so people can understand what happened.
This matters for community coordination now and commons quality later. If something is wrong, disputed, low quality, or missing context, the community needs a way to challenge it without turning the whole system into a private moderation queue.
Cases and disputes
The Disputes page is a case inbox. It shows what is open, what needs a response, what is in review, what can be appealed, and what has been resolved.
A good case page should make three things obvious:
- What was challenged?
- What needs attention now?
- What happens next?
The preview includes Chiado testnet wiring for Honey-backed content challenges and Kleros-style review. That matters for testing, but users should not need to understand the contract path to follow a case. If they do, the page needs work.
Human review
The app includes human verification because some review work should depend on human eligibility.
Verification should be useful without taking over the product. It matters for review, anti-sybil rules, and future participation rules. It should not be the first thing every casual reader has to think about.
The long-term pattern is simple: AI can generate and organize more work than humans can review directly, so the system needs to decide what deserves human attention. The preview lets us test that pattern first in ordinary community moderation and review.
Honey account
The Honey page shows a user’s Honey state: wallet balance, staked Honey, available stake, active locks, and court assignments as those pieces mature.
The direction is one clear Honey account instead of many disconnected staking flows. If Honey is locked for a challenge, assigned to review, or available to withdraw, that should be understandable from one place.
Bee nodes
Bee is the early name for helper nodes that can watch activity, organize work, and flag what needs attention.
A Bee should not replace human judgment. It should help decide where human judgment is needed. That might mean finding uncertain records, surfacing possible duplicates, noticing low-confidence labels, or escalating a disputed case.
As the commons grows, Bee should help with more than reviewing records. It can support swarms, canon, digital gardens, and other knowledge work by organizing context and making uncertainty visible.
Canon and versioned tools
Swarms are where people coordinate. Canon is the next layer: shared knowledge that can be edited, reviewed, versioned, and improved over time.
That includes community wikis and personal digital gardens. A person should be able to curate their own garden with help from Bee, while also contributing to broader community canon when the work belongs in a shared record.
Git is a separate layer for code and tools. The commons should eventually be able to maintain not only what it knows, but also the software, agents, and infrastructure it uses to maintain that knowledge.
Node and protocol settings
The preview also includes early settings for users, node operators, and shared protocol rules.
Node settings matter because 1Hive should eventually support more than one operator. A node may choose what it stores, indexes, hides, or serves. That is different from a shared review outcome, which should come from challenges, cases, rulings, and appeals.
Protocol settings are for rules that should not change silently. If a shared parameter matters, changing it should be visible and reviewable.
The long-term payoff is not just cleaner coordination. A community that deliberately curates knowledge and data should be able to set terms for how that data is used. That is the data-union thesis, but it only becomes credible after the commons has real work, clear stewardship, and visible governance.
What we want feedback on
Please be specific. We are not looking for encouragement as much as clear product judgment.
Useful feedback sounds like:
- I could not tell what a swarm was for.
- The app did or did not feel useful as a coordination space.
- Buzz made sense as lightweight signal, or it did not.
- The challenge panel explained the Honey requirement, or it made things worse.
- I could follow a case, or I got lost.
- Disputes felt useful, or it felt like protocol noise.
- The Honey page answered my question, or I still did not know what was locked.
- I could see where automation should help, or the workflow still depended too much on manual review.
The preview is early, but it is real enough to test the shape of the work. We want 1Hive to become useful as a community coordination space first, then grow into a way to create useful knowledge and datasets deliberately: automation where it helps, humans where judgment matters, and Honey where shared consequences need support.