Trust and Security
Privacy should be architectural, not merely contractual.
Daemonet is designed to reduce the information and authority any one component requires. That does not eliminate trust; it makes trust explicit, narrower, replaceable, and easier to test.
Ownership
Managed authority stops where customer authority begins.
User devices are authoritative for identity, keys, profile membership, topology, application state, data, and direct relationships. 1Man is authoritative only for the managed capabilities it explicitly grants and operates.
No password-account or operator fallback may approve a device, rewrite a profile, recover an identity, or silently replace current device state with a durable cloud copy.
Threat model
Protect content and authority without pretending traffic is invisible.
Daemonet is designed to resist passive content observation, unauthorized endpoint substitution, forged authority, replayed capabilities, provider capture, and damage from one lost device or unavailable coordinator—within the limits of the deployed configuration.
Unreadable content
WireGuard and application encryption protect confidentiality and integrity. Packet timing, volume, source networks, and destinations may still be observable.
No endpoint substitution
Clients verify signed endpoint and service identity. A coordinator can deny service or return stale data, but must not silently become the trusted origin.
Scoped damage
A valid peer can use only its granted capability, but can retain plaintext it is legitimately shown and may attack exposed application behavior.
Revocation and recovery
Remove the device key and rebuild authority through owner-defined recovery rather than provider impersonation.
Confidential, verifiable pieces
Client encryption and authenticated shards limit disclosure and detect corruption; availability still requires enough independent honest capacity.
Visible failure and exit
No insecure downgrade. Established direct relationships continue where possible, and self-hosting remains an operational exit.
Endpoint truth
Encryption cannot protect data from an authorized but compromised endpoint, a participant who copies what they receive, weak local credentials, malware, unsafe browser extensions, or an operator who misconfigures the service.
Data handling
Retain the minimum state required for the named job.
A coordinator needs short-lived connection state, not a permanent social graph. An entitlement verifier needs the scoped right and evidence, not browsing history. A shard provider needs opaque pieces and integrity challenges, not plaintext.
Encrypted, expiring introduction state and abuse-resistant operational limits; no application payload.
Signed authority and current routes; no claim that DNS itself hides every query or carries traffic.
Product scope, subject or bearer binding, validity, limits, and revocation evidence; no mandatory biography.
Invoice and settlement evidence required for authorization; no wallet seed or signing capability.
Short room lease and encrypted signaling; messages and file bytes stay on participating endpoints.
Only explicitly selected bandwidth, storage, or compute receives the bytes its role requires, under a distinct policy.
Responsible use
Privacy-preserving infrastructure still has operators and obligations.
Users must have the right to connect devices, share content, process data, and grant access. Node and service operators need narrow abuse controls, incident procedures, legal review, security contacts, and visible failure without converting the network into a surveillance inventory.
Do not use experimental services for emergencies, production patient data, regulated financial custody, unlawful content, or workflows whose safety depends on unproven availability or anonymity claims.
Compliance roadmap
Architecture can prepare for regulation. It cannot self-certify.
Healthcare, institutional, and regulated claims require independent review, operational controls, contracts, evidence retention, incident response, continuity tests, insurance, risk analysis, and any required agreements.
Until those gates are complete, Daemonet is described as designed for regulated environments—not HIPAA compliant, SOC 2 certified, or approved for production protected health information.
Report security
Send reproducible vulnerability reports to security@daemonet.io. Do not include third-party personal data, exploit public systems, or rely on a marketing page as a coordinated-disclosure contract.
Trust evidence, not adjectives