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.
• Logs include authenticated public keys and Negentropy message payloads.

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, but the supplied relay tag is currently checked only for presence, not for the correct relay URL. Authentication sessions are not durable across connections.

WebSocket origin policy

All origins are currently accepted during WebSocket upgrade. A production deployment should restrict and test the WebSocket origin policy.