torii is experimental software (0.x). It's designed to be run privately (bound to localhost and reached over Tailscale or a Tor hidden service, gated to a trusted allowlist via NIP-42 AUTH) and is not hardened to be exposed on the open internet. Please deploy it accordingly.

Please report suspected vulnerabilities privately; do not open a public issue.

Use GitHub's private reporting: Security → Report a vulnerability on this repository (Security Advisories). Include:

• a description of the issue and its impact,
• steps to reproduce (a proof-of-concept if you have one),
• affected version/commit and your deployment (Docker / source, Tor on/off).

You can expect an initial acknowledgement within a few days. As a small, best-effort project there is no formal SLA, but security reports are prioritized.

torii's security model rests on a few properties; issues that break these are in scope:

• Access control: all reads/writes are gated by NIP-42 AUTH to the configured member allowlist. Unauthenticated access to events, counts, or metadata is a bug.
• Per-member isolation: each member is an isolated tenant; one member reading another's feed, inbox, archive, or DMs is a bug.
• Blind DM transport: torii never decrypts NIP-17 DMs and never stores a gift wrap addressed to a non-member. Any path that violates this is a bug.
• Keyless: torii never holds or receives a member's private key. Private (encrypted) NIP-51 list entries are decrypted by the member's own signer in the dashboard; torii receives only the resulting reference tags. A path that needs a member's key to function is a bug.
• Private posture: torii never advertises itself and must not appear in a member's published relay lists.
• SSRF / resource abuse: a member-supplied relay list should not be able to aim torii's outbound connections at internal hosts, nor turn it into a spam amplifier.

A public deployment is supported, but hardened: put a TLS reverse proxy in front (see deploy/Caddyfile.example), set trusted_proxies so per-IP limits see real clients, optionally cap connections with max_conns_per_ip, and keep the control plane private by binding it to its own address with dashboard.listen_addr (reached over SSH/Tailscale). Exposing the relay port directly, with no proxy, is still not a supported configuration.

• Exposing torii's relay port directly on the public internet with no reverse proxy (unsupported deployment).
• Attacks that require a trusted member's cooperation beyond the isolation and anti-abuse guarantees above; members are, by definition, trusted.
• Vulnerabilities in upstream dependencies (report those upstream), though we're glad to hear about them.