Dibs (Hive Commons)

Dibs

A place to offer software ideas to projects and retain credit for them.

Your idea, your credit, their code.

The missing contributor layer for the AI-agent era.

Dibs is a two-sided marketplace that connects ideators — people who call dibs on ideas: great insight, but no time, tooling, or inclination to write code — with hive-managed repositories: projects that use Hive to run coding agents under maintainer-chosen rules.

1. Ideators post ideas — public or private — in plain language / markdown.
2. Repos opt in to receive ideas, declaring topics and appetite.
3. A language model (LLM) matches ideas to repos that want them; both the idea contributor and the receiving project must accept the match.
4. On mutual acceptance, Dibs hands the ideator a prefilled GitHub issue — they file it themselves, under their own GitHub account, so the issue is natively attributed to them (label ideated). The receiving project can then have its agents work on it under its own review rules. In this default flow Dibs is just the matchmaker: it never files the issue for you.

Ideators are first-class contributors

Open source has always had a quiet contributor class with no outlet: researchers, operators, designers, power users — people who know exactly what a project needs but will never open a pull request. Open source has also always known ideas are contributions — the all-contributors spec has a 💡 "ideas" emoji, and the academic CRediT taxonomy credits "Conceptualization" as a first-class role. Dibs makes that credit real, machine-readable, and public.

Creators get credit. Agents do the work. Projects take the bow.

Every implemented idea traces back to its ideator: the GitHub issue credits the idea's author, the resulting work carries that provenance, and the public credit wall (/api/credits, "Credit wall" in the UI) lists every ideator with a settled idea: a GitHub issue URL has been recorded. This credits the proposal, not proof that its implementation shipped or its issue was closed. Settled ideas appear regardless of their visibility setting: settling a private idea makes its credit facts (author, title/TLDR, target, issue URL, and time) public, but not its body or private detail endpoint.

Try Dibs in your browser

No local installation or Go toolchain is needed. Open dibs.hivecommons.dev to browse the public surface; posting needs a Hive Hub sign-in and filing the issue needs a GitHub account.

1. Sign in and describe your idea in plain language. Choose public or private deliberately; unsettled private ideas are not included in the public wall.
2. Review suggested repositories and offer the idea to a suitable project. For Hive-managed targets, both sides accept before issue filing.
3. Open the prefilled GitHub issue, review it, and file it yourself.
4. Confirm the resulting issue URL in Dibs. This step is settlement: it records the handoff, not completion of the proposed work. Confirming also publishes the credit facts above, even for an idea marked private.

Non-Hive GitHub targets can skip the receiving-project acceptance step. For settlement and privacy details, see the consumer API. To submit from a coding agent instead, see MCP setup.

Maintainer and developer reference

The following sections cover running Dibs, its API, and local development, not prerequisites for using the hosted site.

Architecture

Single Go binary (cmd/dibs) serving both the JSON API and an embedded static UI, deployed at its own subdomain: dibs.hivecommons.dev. The base path is configurable (DIBS_BASE_PATH), so path-prefixed reverse-proxy deployments also work.

Configuration

Legacy IDEATE_* names (the pre-rename prefix) are still honored as fallbacks for every DIBS_* variable.

Roadmap

See ROADMAP.md for what is planned next. Delivery history:

• Wave 1 (done): scaffold, hub auth bridge, idea CRUD, repo registry.
• Wave 2 (done): LLM matching + TLDRs, swipe UX ("offer" / "pass"), issue settlement (credited GitHub issues), notifications.
• Wave 3 (done): deployment (GHCR image + deploy/ manifests for dibs.hivecommons.dev), public landing page, public credit wall, ideator profile stats.
• Wave 4 (done): matchmaker settlement — the ideator files a prefilled GitHub issue themselves (native attribution, ideated label) and confirms the issue URL; LLM-assisted idea refinement on posting and repo-tailored expansion on submission; token-based settlement demoted to legacy.
• Later: cookie-domain/hub-OAuth session sharing, non-hive receptor repos, idea economics.

Deployment

Every push to main publishes ghcr.io/hivecommons/dibs (latest + commit sha) via .github/workflows/docker.yml; the image is distroless and runs as non-root. Plain Kubernetes manifests for dibs.hivecommons.dev (Deployment, Service, cert-manager TLS Ingress, PVC, ConfigMap/Secret) live in deploy/, including the required DNS record and hub-cookie prerequisites.

Public surface (no sign-in required)

Everything else requires a hive hub session; signed-in ideators additionally get GET /api/me/stats (ideas posted / offered / accepted / settled).

For response schemas, eligibility/privacy rules, settlement actions, rewards, and stability levels, see the credit-wall consumer API.

Submit ideas from your agent

Dibs exposes a stateless Streamable HTTP MCP endpoint at https://dibs.hivecommons.dev/mcp, so Claude Code, Copilot CLI, Cursor, Gemini CLI, Codex, and other MCP clients can submit ideas without leaving the agent.

Dibs is listed in the official MCP Registry as dev.hivecommons/dibs (registry entry). Search for that full name: a plain dibs search also returns unrelated servers with the same name, including the 1stDibs marketplace and other coding-agent tools called dibs. How the listing is published is covered in MCP Registry publishing.

Available tools:

Token

Use Authorization: Bearer . Dibs first asks the Hive Hub /api/saas/whoami endpoint to verify the bearer token server-to-server; the hub already accepts GitHub bearer tokens for registered hub user