Trust and data

The relay's intended operating model is a public reusable relay, so the trust boundaries below apply to any connecting client or user, not only to Nostrfi's own products or team.

Data and trust boundaries

• Event signatures are verified before storage; the relay does not hold user signing keys.
• DuckDB contains event envelopes and content and must be treated as user data.
• Gift-wrap content may be encrypted, but its event envelope and recipient tag remain visible to the operator.
• Authentication and subscription authorization live only in process memory.
• The application provides no TLS; a production deployment needs a trusted edge or equivalent transport termination. A documented, exercised TLS-terminating reverse-proxy overlay is available for this.
• Logs include authenticated public keys, but never the raw Negentropy message payload (only the subscription ID) — that hex vector is high-volume reconciliation metadata, not something worth logging at Info level.

What an operator can observe

The relay operator can observe:

• Connection metadata (IP address, timing, connection duration).
• All published event envelopes, including event content, author pubkey, timestamps, signatures, and tag values.
• Gift-wrap metadata and ciphertext (kind 1059 events are access-controlled in the application but exist unencrypted at the database-envelope level).
• Authenticated public keys after NIP-42 authentication.
• Subscription filters and query patterns.
• Negentropy reconciliation messages.

Authentication limitations

Authentication validates the event signature and challenge. The supplied relay tag's value is matched against the operator's configured canonical relay URL, and the authentication event's freshness is checked, when the operator has configured them — left unconfigured, only the tag's presence is checked (the historical, development-friendly default). Authentication sessions are not durable across connections.

WebSocket origin policy

Origin restriction is configurable. In the relay's development-mode default, all origins are accepted during WebSocket upgrade; an operator running a production deployment can switch to a mode that requires every connecting origin to appear on an explicit allow-list.

Moderation

The operator can remove or hide a specific published event from being served, and can block a pubkey from publishing or a connection source (IP or CIDR range) from connecting — independent of the same-author deletion any Nostr user can already request. These actions:

• Are authenticated to the operator's own key, not any connecting client's.
• Are logged for accountability.
• Act on this relay's storage and serving only — they do not, and cannot, prevent the same content from being published to other relays.
• For a pubkey ban specifically: block that pubkey's future publishes only. Content the pubkey already published before the ban remains served unless separately hidden.

Abuse reports are received at the contact address published in this relay's NIP-11 relay information document and triaged by the operator.