Local-first by default
RelayHub is designed to keep essential operation local where practical and avoid hidden dependency on centralised services.
Security
Security requires honesty, recovery, and evidence.
RelayHub is being designed as local-first infrastructure for resilient communities. Security claims must remain realistic, testable, and clear.
Security posture
Practical security, not magical guarantees.
RelayHub should reduce unnecessary exposure, support local operation, preserve recovery paths, and make capability boundaries visible. It must not overstate privacy, anonymity, censorship resistance, or operational safety.
Least privilege
Services should run with only the access they need, and administrative control should not be exposed unnecessarily.
Policy-governed capability
Features should only activate when hardware, software, policy, trust, legal, runtime, and user gates allow them.
Recovery-first design
Recovery, rollback, safe reset, support export, and identity preservation are treated as core architecture rather than optional extras.
Threat boundaries
What RelayHub does not promise.
Honest security starts by naming limits. RelayHub is intended to support resilient communication and community coordination, but it must never be described as invulnerable, perfectly anonymous, or guaranteed under all conditions.
- RelayHub does not provide perfect anonymity.
- Reticulum reachability does not automatically imply trust.
- Radio communication may be observable and regionally regulated.
- Physical device access can change the threat model.
- No system can guarantee message delivery in all conditions.
- Experimental features must not be treated as product-supported.
Responsible disclosure
Report security issues clearly and safely.
If you discover a vulnerability, privacy issue, unsafe behaviour, or misleading security claim, please report it responsibly. Do not exploit systems, access other people’s data, disrupt services, or publish active vulnerabilities before there has been time to assess and respond.
Reportable concerns
- Security vulnerability
- Privacy exposure
- Unsafe default
- Misleading capability claim
- Recovery failure
- Authentication or access-control issue
- Support export redaction issue
Recovery-first
A secure system must still be recoverable.
Security controls that make ordinary recovery impossible can create fragility. RelayHub designs should preserve safe rollback, guided recovery, identity continuity where possible, and privacy-preserving support export.
Security principle
No convenience feature should silently increase exposure. No update should silently enable new sharing, new federation, new gateway behaviour, or new radio transmission without clear policy permission and validation.
Contact
Security contact
Use the contact form for security reports and include as much detail as possible: affected page, endpoint, expected behaviour, observed behaviour, reproduction steps, browser or device context, and whether any data may have been exposed.
Email: hello@relayhub.tech
Contact form: relayhub.tech/contact