VergeCommon

VergeCommon

What if conservation could be an open-source project?

Enter VergeCommon: open tools for people caring for the places they share.

Organize a local conservation project, document the work, and make decisions together. From hedgerows and woodlots to larger landscapes, communities should be able to inspect, adapt, and improve the tools they depend on.

Early cooperative pilot. The shared website is live with browser accounts, private co-ops and scoped agent access. The repository also includes the self-hosted account/storage runtime and native participation source. This is an invitation to build and test with us. Real partner adoption and verified environmental impact have not yet been demonstrated. See current status and service coverage for what is live and what remains.

Find your first contribution

Quickstart · Contribution guide · Roadmap · Pilot checklist · Launch kit and release gates

Explore the project

Website · Conservation network · Member workspace · Account and device access · Contribute

vergecommon.com is the canonical service address. For what is live, verified and still open right now, read STATUS.md. The deployed service includes the launch foundation (PR #2) and the conversation actions and social sign-in work (PR #3). Dated deployment receipts and reviews live in docs/history/. Co-op and project publication is opt-in; member records and private land evidence retain their server-side access rules.

Start your own community

For the self-hosted application, use Node 24.19.0 and follow the single-server operator guide. It includes browser accounts, SQLite, private evidence files, device tokens, hosted MCP, deployment configuration, and backup/restore procedures. Build and exercise an isolated local instance before publishing it.

The original Cloudflare/Sites development path remains available through npm run launch with Node.js 22.13+. Its identity is a development fixture; never expose that development server publicly. In either workflow, create a co-op and follow the Start checklist. See Worldwide adoption for regional setup.

Part of the Viridis open commons

VergeCommon is one of five open projects that build on each other. Each one is useful alone; together they carry a piece of land from a map to a verified result.

How they connect: DFM finds where a corridor runs. The corridor almost always crosses property lines, so VergeCommon gives the neighbours along it a private place to organize and consent. GSIP adds soil evidence from the same ground. ViridisOS lets anyone recompute what was claimed, and Viridis Research holds the proofs those checks rest on. Viridis Conservation (viridisconservation.com) offers paid data preparation, assessments and support for teams that want help.

Built something with one of these? Add the badge and tell us in an issue, so we can link back:

[![Part of the Viridis open commons](https://img.shields.io/badge/Viridis-open%20commons-2e7d32)](https://github.com/jdhart81/hdfm-framework#part-of-the-viridis-open-commons)

Agents and MCP

Agents learning about VergeCommon can start at llms.txt (source: public/llms.txt) and AGENTS.md, which explain how to help a person start a co-op and how to contribute.

The MCP server supports local stdio and authenticated Streamable HTTP at /mcp in the self-hosted runtime. Local stdio offers public discovery and hypothetical pooling/allocation drafts. Hosted tokens with mcp:read can also read the owner's permitted workspaces; mcp:write adds bounded project, member-update, task and RSVP commands. App tokens and MCP tokens are separate scopes.

Create a personal agent token from /account, store it in the client's secret settings, and revoke it when finished. The hosted endpoint requires bearer support; OAuth is not implemented. Agents cannot approve legal/financial records, escalate membership, issue credits, execute payments, or publish public updates. The live endpoint passed initialization, private-read, bounded-write and denied-financial-command acceptance checks on September 19, 2026.

What is implemented

• Visible, online browser workspaces refresh every 30 seconds without discarding mounted drafts; permission-aware review reminders include monitoring and financial records.
• Stewardship and treasury receipts complement member payment receipts, with independent review, exact allocation reconciliation and project-bound evidence. These records do not send money.
• Guided co-op actions inside Discussion for private mapping, consent, evidence, partner participation, agreements, governance and external receipts, with role-aware choices and retained drafts. Conversation actions.
• A single-server Node runtime with durable SQLite and private evidence files, an authenticated gateway, username/password accounts, recovery codes, account export/closure, and revocable device/agent tokens.
• Boundary-derived area estimates, overlap screening, reviewed parcel-specific consent, scoped agreement coverage, stale-record detection, and withdrawal/revocation history. Pooling safeguards.
• iPhone/iPad source for authenticated member workspaces, member posts, explicit field-draft submission and deliberate photo/PDF/text evidence submission. A protected, account-bound queue retains exact retry requests through interrupted connections. Public discovery and the protected offline journal remain available; signing, device acceptance and Apple distribution are separate release steps.
• Exportable imagery jobs and an independent NDVI screening worker, with validated result imports and human review. Worker instructions.
• Private versioned GeoJSON boundaries, independent review, explicit external-search consent, Copernicus Sentinel-2 catalogue discovery, and reviewed field observations. See Monitoring.
• A member community board with shared events, capacity-aware RSVPs, private calendar downloads, project discussions, and steward moderation.
• A guided six-step co-op setup, local organization discovery links, and self-reported organization profiles.
• Single-use private invitations with expiry, revocation, and steward approval before record access.
• Country/territory and accounting currency settings, correct currency minor units, and hectares/acres/m² intake.
• Snapshot-based carbon pathway assessments with methodology references and independent human review.
• A worked payout preview before members propose and vote on their policy.
• Signed-in, durable co-op workspaces with steward/member roles and membership requests.
• Opt-in co-op/project discovery, general-region search, shareable links, updates and moderation.
• Projects, assigned conservation actions, completion records, and private parcel/consent intake.
• Private agreement submissions with independent review and externally executed instrument references.
• Private PDF/image/text uploads, SHA-256 file digests, evidence submissions and independent review; exact upload retries, cancellation, expiry and durable cleanup.
• Partner representative invitations, acceptance, own authority evidence, independent co-op review and withdrawal. This grants no extra permissions and does not independently verify an organization.
• Coarse capacity warnings and a finite reserve for authorized safety actions; ordinary additions pause before the hard limit.
• Versioned allocation-charter proposals with frozen electorates, member votes, quorum, and tallies.
• External legal authority, serialized credit holding, settlement, allocation, payment receipt, and retirement records.
• Two-person reviews, integer-cent allocations, per-co-op quantity caps, duplicate references, and linked audit history.
• Scoped JSON exports, membership removal, member exit, and workspace archival.
• The separate hypothetical /coop/ calculator and device-local /demo/ stewardship planner.

What the system does not execute

Verge Common does not form legal co-ops, execute or record deeds, certify ecological measurements, issue or transfer registry credits, initiate sales, send payments, or independently validate bank/registry receipts. Authorized people and external institutions perform those actions. The system stores their supporting records and review decisions.

The cooperative preparation and operational record workflows are implemented; direct registry and payment-provider integrations are not. A reviewed receipt means another steward recorded a review, not that a bank or registry independently authenticated it to the software. See OPERATIONS.md and COOPERATIVE_SYSTEM.md.

Local development

For a local instance of the self-hosted production build, use Node 24.19.0:

npm ci
npm run build:selfhost
VERGE_DATA_DIR=/tmp/vergecommon-local-data npm run start:selfhost

Open the printed loopback URL and register a local account. Keep its recovery code privately. The data path is persistent; use a dedicated empty path for synthetic acceptance tests. Follow the operator guide for canonical origin, reverse proxy, durable volumes and production settings.

For the original Cloudflare/Sites development workflow, use Node.js 22.13+ and npm. This development-only sign-in server must stay local:

npm ci
npm run db:migrate:local
npm run dev

Open the printed local URL and use Sign in. Local data and files live under ignored .wrangler/. The default local identity is a development fixture, not a production account.

Validation

For exact commands with expected output, including a woodland corridor check reproduced with the open DFM engine, see the quickstart. To cite VergeCommon, use CITATION.cff.

npm test
npm run typecheck
npm run lint
npm run build:selfhost

With a local self-hosted production build running against dedicated synthetic data:

VERGE_TEST_ORIGIN=http://127.0.0.1:3100 python3 tests/selfhost_acceptance.py

This checks independent accounts, invitations and access boundaries, version conflicts/retries, evidence storage, token scopes/revocation, hosted MCP and account closure. The runner defaults to local services and requires explicit opt-in for private synthetic fixtures on the canonical production service. Check feature acceptance and the deployment receipt for actual results.

With the original Cloudflare development server running, run its HTTP persistence/concurrency checks:

python3 tests/http_integration.py

Local tests use synthetic records and archive their workspaces. The separately authorized production acceptance run also used private synthetic records, archived its workspace and closed its test login accounts.

Hosting and authentication

Two runtime paths share the same routes, SQL schema, co-op state transport and domain commands:

• Self-hosted Node: npm run build:selfhost builds the shared app for the bundled gateway. SQLite adapters replace D1 and private local evidence replaces R2. A single application process runs behind Caddy; the internal app listener is loopback-only. Browser accounts use salted scrypt password hashes and secure session cookies. Expiring device/agent tokens are stored hashed, checked on each request and revocable. Cookie writes require the canonical origin; verified bearer clients use their own scopes without copying browser cookies.
• Cloudflare/Sites: npm run build retains the Worker, D1 and R2 deployment. The Sites dispatcher supplies authenticated identity and strips caller identity headers. .openai/hosting.json retains the original hosting project ID; forks must use their own project and storage bindings.

Both paths enforce co-op membership and roles inside the private APIs. Never expose the internal application listener or trust caller-supplied identity headers. Self-hosted accounts use usernames and a one-time recovery code, with no email verification, email reset, MFA or OAuth provider. Save the recovery code securely. Password change/recovery revokes earlier sessions and tokens. See Security, architecture and the operator guide.

The self-hosted adapter applies the existing initial SQL migration transactionally. It does not automatically copy data or identity from an existing Sites deployment. Preserve deployed migration history and rehearse any later schema or record migration with a backup.

Data boundaries and operating limits

Public profiles show only explicitly public project summaries/updates, general regions, and active member counts. Agreements, land references and evidence are restricted to their submitters and stewards. Members can inspect co-op governance and financial records; payout bank details are not collected. Files download as attachments. Review the privacy policy.

The self-hosted runtime supports one application process and one local SQLite database; it is not a replicated/high-availability deployment. Daily local backups are active, staging and production restore verification passed, and an initial matching production archive was copied offhost. See the deployment receipt for the exact recovery results. A recurring encrypted offsite schedule and recovery-key custody still require operator configuration. Each co-op is an atomically versioned aggregate with a 750 KB hard application limit, 500 member records and 5,000 audit events. In the next candidate, ordinary growth pauses at 650 KB or 4,500 audit events to reserve finite space for authorized safety actions; a private capacity banner warns members. File storage is limited to 200 files per co-op, 4 MB each. This architecture favors correctness for initial partner co-ops; a normalized event/record store is required before larger deployment. Cross-co-op or cross-installation registry claims still need the external registry's authoritative duplicate/custody checks.

Mission and sustainability

The platform takes no percentage of credit sales. Co-op-approved stewardship and treasury allocations remain co-op funds. Optional hosted operation/support may fund maintenance; no paid service or financial outcome is promised by this release.

The repository contains the clean public system. Separate private research, proof candidates, production records, and private pilot source were not published as a bulk release. No formal or ecological certification is claimed.

Part of the Viridis open-source commons

Planning stewardship near roads or streams? DFM produces retention options a co-op can review together, and GSIP adds soil observations. The handoff between them is manual today.

This project is one of a connected set of open tools from Viridis. Each stands on its own; together they run from field evidence to checked decisions.

Conservation commons

• VergeCommon (this repository): community conservation co-ops with consent-based land mapping, field evidence and group decisions
• Dendritic Forest Management (DFM): compare forest-retention options around roads and waterways, with traceable inputs and portable reports
• Global Soil Intelligence Project (GSIP): contribute soil observations and explore open soil maps with explicit uncertainty

Verifiable science

• Viridis Canon: machine-checked Lean 4 mathematics for ecological decisions, with a DOI for every result
• ViridisOS: open reference runtime for DOI-backed decision modules and recomputable results
• Viridis Research: the nightly public research record, each claim labeled by what a verifier actually checked
• ProofLens: see what a Lean statement means before reading the proof

Agent tools

• Viridis Agent Fleet: open-source MCP agents with deterministic, auditable cores
• EnergyAI MCP: energy-planning estimates and incentive sources for AI agents

Browse every project on the Viridis profile. If this one is useful to you, a star helps other people find it.

License

Original code and original workflow templates: GNU AGPL v3.0 only. See LICENSE, NOTICE, and THIRD_PARTY_NOTICES.md. Dependency code retains its own licenses. Forks are welcome; do not imply endorsement through the Verge Common name.

Shared service and native app

The website and native client use this repository's co-op service. See architecture and legacy reconciliation and iPhone/iPad build status. Native public discovery, personal-device authentication, member posts, private discussion replies with protected explicit retries, and explicit field observation submission are implemented against https://vergecommon.com. Advanced governance, invitations, mapping and financial workflows use the website. Physical-device acceptance, signing and TestFlight/App Store distribution remain release requirements; source implementation is not a distributed mobile release.

Participation loop in v0.9.0

Share one public project, activity or progress page, with a social preview and QR code. A recipient previews the purpose before signing in, requests steward approval and returns to the same activity. Record actual attendance and completed work, obtain another steward’s review, then preview/publish or withdraw the public result. Precise meeting instructions, boundaries, member names and files stay private.

Open Care & participation inside a co-op to assign dated/recurring care and disturbance responses, submit supporting evidence, review completion, enable optional browser reminders and view the steward’s participant report. Mark test accounts appropriately before using that report; anonymous visitors and causal virality are not measured. See service coverage, privacy and the operator recovery notes.