Starting a community
How to define a local purpose, identify initial participants, choose a practical first use case, and avoid overcomplicating the first deployment.
Community Guides
Communities need practical guides, not just technology.
RelayHub exists to help people build, sustain, and interconnect resilient communities. These guides outline how communities can prepare for local-first communication, trust, knowledge sharing, trade coordination, governance, recovery, and voluntary federation.
Guide areas
Start with what communities actually need to do.
The first community guides should help ordinary groups begin safely: define purpose, onboard people, test local-first operation, preserve knowledge, recover from failures, and avoid premature complexity.
Household deployment
How households may use RelayHub-style infrastructure for local communication, knowledge access, recovery, and participation in wider communities.
Community pilots
How early groups can test onboarding, status comprehension, trust, recovery, documentation, and local-first operation before broad rollout.
Knowledge sharing
How communities can preserve guides, procedures, local knowledge, maps, histories, lessons learned, and training material.
Marketplace coordination
How communities may coordinate offers, requests, services, skills exchange, mutual aid, and local economic activity without implying settlement custody.
Federation readiness
How communities can prepare for voluntary federation with neighbouring groups while preserving local autonomy and clear trust boundaries.
First deployment path
Build the smallest useful community loop first.
A community should not begin by trying to deploy every possible feature. Start with a small, understandable, recoverable pilot and grow only after people can operate it safely.
- Define the community purpose.
- Identify the first practical use case.
- Choose the initial participants.
- Start with local-first communication.
- Keep governance simple at the beginning.
- Document roles and expectations.
- Test onboarding with non-technical users.
- Test degraded and local-only operation.
- Test recovery before expansion.
- Record lessons learned before scaling.
Pilot checklist
A pilot should test comprehension, not just connectivity.
A community pilot is not successful merely because devices boot. It should prove that people understand setup, status, trust, recovery, support, and boundaries.
- Can a new user understand what RelayHub is?
- Can a non-technical user find the right first step?
- Can users explain Ready, Local-Only, No Peers, Degraded, and Recovery?
- Can recovery instructions be found without internet access?
- Can participants distinguish trust from discovery?
- Can the group operate without assuming every feature is supported?
- Can support questions be answered without exposing secrets?
- Can the pilot stop safely if it is not ready to expand?
Trust guides
Community trust is social before it is technical.
RelayHub can support trust workflows, but communities still need human judgement, clear roles, accountability, and local governance.
Discovery
Finding a person, node, group, listing, or service does not automatically mean it is trusted.
Invitation
Communities should use clear invitation flows, role expectations, and revocation paths.
Membership
Membership should be voluntary, understandable, and governed by local community policy.
Reputation
Reputation should emerge from behaviour, reliability, accountability, and community experience.
Federation
Federation should be voluntary, limited, reversible, and based on explicit relationships.
Recovery
Recovery should preserve continuity without enabling unauthorised takeover or silent authority transfer.
Community roles
Communities need roles before they need complexity.
Early communities should define simple responsibilities so people know who helps with onboarding, documentation, recovery, hardware, support, marketplace rules, and community coordination.
Marketplace and knowledge
Community infrastructure is broader than chat.
Communities need places to share knowledge, coordinate goods and services, announce needs, preserve local memory, publish guides, and organise practical action.
Knowledge guides
Procedures, maps, local instructions, lessons learned, training material, local history, and cultural continuity.
Marketplace guides
Offers, requests, skills, local services, community rules, moderation, dispute expectations, and settlement-neutral coordination.
Governance guides
Notices, proposals, roles, working groups, decisions, moderation, accountability, and voluntary federation boundaries.
Avoid these mistakes
Good community deployment avoids false confidence.
RelayHub should help communities build capacity without assuming that technology alone creates trust, governance, resilience, legality, or support readiness.
- Do not claim a community deployment is product-supported until validated.
- Do not treat internet failure as total failure if local operation still works.
- Do not expose private keys, recovery secrets, or message contents in support requests.
- Do not assume radio transmit is lawful merely because hardware exists.
- Do not treat federation as automatic trust.
- Do not scale before onboarding, recovery, and documentation are understood.
Future guide library
The guide library is planned, not complete.
These are the practical guides RelayHub should eventually publish as the system moves from architecture and website development into pilots and supported releases.
Quick Start for Communities
Household Node Setup Guide
Community Pilot Workbook
Local-Only Operation Guide
Trust and Membership Guide
Recovery Drill Guide
Marketplace Steward Guide
Federation Readiness Guide
Hardware Selection Guide
Operator Checklist
Accessibility and Stress-State Guide
Support Export Guide
Start a pilot
Tell us what your community wants to test.
If your community is interested in local-first communication, knowledge sharing, marketplace coordination, recovery planning, or community infrastructure, start with a practical pilot conversation.
Useful details
Include your community type, region, rough size, first use case, technical comfort level, available hardware, and what you want to test.