Veydrin Community Network
The organizational standard for community networks working in service to life. Defines the rules, federation model, membership process, trust badge, and enforcement framework that VCN nodes and partners commit to.
Community organizations — veteran support, sustainable agriculture, financial empowerment, mutual aid, education, technology for public good — overwhelmingly operate in isolation. Resources go undiscovered. Organizations that could amplify each other's work never meet. People who need help navigate disconnected systems alone.
VCN is a standard, not a platform. It defines how organizations connect, establish trust, and sustain a network without depending on any single entity to keep it alive. The standard is the contract. The directory is the proof. The network is the people.
This document — the VCN Community Spec — governs the organizational layer: the nine rules every partner commits to, how local nodes form and govern themselves, how the trust badge is earned, and how violations are handled. The technical implementation standard governing how VCN-enabled apps communicate is a separate document: see the VCN Protocol Spec.
VCN is licensed CC-BY-4.0. Any organization may adopt this standard under a different name for a different community, provided they preserve attribution.
Every VCN partner — and every VCN node — commits to these nine rules. They are not aspirational. They are the minimum for carrying the badge. An organization that cannot meet all nine should not join.
VCN is not one global directory. It is a standard that local networks adopt. Each local network runs its own directory. The root VCN site is a map of nodes — not individual organizations.
A VCN node is a local cluster of organizations that have adopted the VCN standard, maintain a shared directory, and vouch for each other. A node might be a city, a neighborhood, a region, or a community of practice. The node decides its own scope.
The root directory lists nodes, not individual partners: "Cebu Community Network — 12 partners. Richmond Mutual Aid — 7 partners. Willamette Valley Restoration — 5 partners." Each node links to its own directory where individual partners are listed.
The Veydrin Order maintains two things and nothing more: this specification, and the root registry of nodes. Once a node is running and listed, the Veydrin step back entirely. The node self-governs. The Veydrin are not involved in any admission, dispute, or day-to-day operation of any node.
A node's directory is a static website generated from a public git repository, hosted on Codeberg Pages at no cost. Every partner addition, removal, or status change is a git commit with a timestamp and a reason. That commit history is the public verifiable record — no database, no admin panel, no single point of control.
Each node governs its own partners. The Veydrin do not approve or remove individual partners within a node — that is the node's responsibility. Nodes decide how they communicate, how they meet, and how they organize internally. The spec defines the standard. The node decides everything else.
The only thing the root registry governs is whether a node meets the VCN standard. If a node goes sideways — allowing partners that violate the rules, refusing to enforce the standard, misusing the badge — the node can be removed from the root registry using the same process that applies to individual partners (§6).
Nodes are independent but not isolated. A partner in one node can discover partners in other nodes through the root map. Knowledge sharing, resource exchange, and collaboration across nodes are encouraged — that is how the larger VCN community works. But the primary value is local. Cross-node connections are a benefit, not the core.
There is no fee. VCN membership is earned by meeting the standard. Any organization — nonprofit, community group, cooperative, or mission-driven business — may join a node or start a new one.
Every partner in the VCN directory is represented by a YAML file in the node's repository. The following fields are required unless marked optional:
name: "Organization Name" # required tagline: "One-sentence mission statement" # required location: "City, Country" # required website: "https://example.org" # required contact: "contact@example.org" # required — public contact email focus: ["food sovereignty", "education"] # required — 1–5 tags joined: "2026-03" # required — YYYY-MM active: true # required — false = lapsed (R8/R9) vouched_by: "partner-slug" # required — existing partner who vouched notes: "Optional public notes" # optional
The filename is the organization's slug (e.g., cebu-garden-collective.yaml). The slug is permanent — do not rename after listing. A directory template and onboarding guide are available at codeberg.org/veydrin/vcn-directory-template.
Carrying the VCN badge means being an active node — not a name in a directory. The requirements below correspond directly to Rules R3, R8, and R9.
| Requirement | Frequency | What counts |
|---|---|---|
| Respond to network requests | Within 14 days of each request | Any written response — including "we can't help" or a referral to another partner. Silence does not count. |
| Network exchange participation | Quarterly minimum | Attend a live exchange, or engage async with shared notes within 7 days. Missing a full quarter without advance notice is a standing violation. |
| Directory card accuracy | Annual minimum | Confirm your card is current at least once per year. Corrections may be made at any time. |
Governance is one sentence: existing partners, collectively. There is no standing committee, no Trust Council, no quorum requirement designed for a network size that doesn't exist yet. The partners are the council at whatever size they are.
Reports are filed by opening an issue in the node's public Codeberg repository. Each node's README must include a direct link to the repository's issue tracker for this purpose. Reports against a node (rather than an individual partner within it) are filed in the VCN root registry repository. Reports must:
Anonymous reports are not accepted. The filer's identity is kept confidential from the accused organization during discussion, but is known to the partners deliberating. Deliberately false or malicious reports are treated as violations of R6.
| Strike | Consequence | How decided |
|---|---|---|
| Strike 1 | Formal written notice. Documented in the public git history of the node directory. Partner has 30 days to respond and demonstrate corrective action. | Partners discuss openly, majority vote to issue. |
| Strike 2 | Probationary status. Badge displays provisional indicator. Partner may not vouch for or onboard other organizations during probation. | Partners discuss openly, majority vote to issue. Lifted by majority vote after 90 days minimum. |
| Strike 3 | Removal. Directory card removed. Badge revoked. Reason for removal recorded publicly in the repository commit history. Minimum 3 years before reinstatement eligibility. | Partners discuss openly, majority vote to remove. Reinstatement requires unanimous partner agreement. |
The most powerful enforcement mechanism is not institutional — it is community knowledge. Every legitimate member knows who is and isn't real. When an organization misuses the VCN badge, the community corrects the record in its own channels. The public git history and the root registry are the authoritative source of truth. Common law trademark principles apply to any misuse of the badge or the VCN name.
The VCN badge is a Michelin star, not a franchise license. Organizations earn it by meeting the standard. The Veydrin are the sole issuing authority. As the Veydrin build demonstrated goodwill through FOSS tools, community service, and education, the badge accumulates weight. Guidance without gatekeeping — two parties working as colleagues.
The root VCN site is a static site generated from the root registry repository, hosted on Codeberg Pages. When the site builds, it generates a badge image at a predictable URL for each active node and partner. Partners embed a small HTML snippet that loads the badge from this URL.
When a node is removed from the root registry and the site rebuilds, the badge URL stops resolving. The badge disappears from any site embedding it. No action required by the removed party — it simply stops working.
Organizations implementing VCN-enabled applications that serve high-threat populations (domestic violence survivors, asylum seekers, political dissidents, LGBTQ+ communities in hostile jurisdictions) may qualify for the full VCN trust badge by additionally implementing the high-protection transport tiers defined in the VCN Protocol Spec §6 Tier 5 (Tor hidden service) and §6 Tier 6 (obfs4/Snowflake pluggable transports). Standard badge organizations are not required to implement these tiers.
VCN member applications must implement VODS v1.0 (Veydrin Open Data Standard) as the data interoperability baseline. VODS defines the document envelope, privacy floor, and export contract that all VCN-compatible apps must honor.
Domain-specific specializations — OHDS for apiary data, OCEADS for soilless cultivation data, OPDS for permaculture data — extend VODS and are recognized as compliant VCN data formats. Future domain specializations follow the same pattern: extend VODS, do not replace it.
VCN Community Spec uses semantic versioning (MAJOR.MINOR). All version changes are committed to the public git repository with a clear message describing what changed and why. The repository history is the canonical record of spec evolution.
| Change type | Version bump | Threshold |
|---|---|---|
| Add optional rule clarification; extend participation guidance; add non-breaking onboarding guidance | MINOR |
Majority of active nodes (via PR discussion) |
| Change a core rule; change enforcement process; change badge requirements; restructure the federation model | MAJOR |
Unanimous agreement of all listed nodes |
| Correct a typographic or formatting error without changing meaning | Patch note — no version bump | Any maintainer |
The VCN Community Spec and the VCN Protocol Spec version independently. Organizational governance and software implementation evolve at different cadences. Cross-reference the Protocol Spec for the current technical implementation version required for badge compliance.