Document relay-operator visibility for channel messages (public and private)

Open Beginner friendly
#3,079 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
72/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Quiet
Tech stack
rust, sql

Research direction

Read SECURITY.md and NOSTR.md first, then verify the cited behavior in migrations/0001_initial_schema.sql, crates/buzz-core/src/kind.rs, and crates/buzz-test-client/tests/e2e_nostr_interop.rs. Done means the accepted privacy model for public and private channel messages, and the NIP-17 exception, are stated explicitly in the appropriate documentation.

Written by the indexing model from the issue text.

Description

What I found

Channel content (public or private) is stored and full-text-indexed as plaintext, regardless of the channel's access-control setting:

  • migrations/0001_initial_schema.sql generates search_tsv from plaintext content for every kind except 1059, which is explicitly excluded as "(NIP-17 ciphertext)".
  • NOSTR.md documents NIP-17 gift-wrap DMs (kind:1059) as supported and "not indexed in search", but also notes "NIP-04/NIP-44 not implemented" for broader DM encryption.
  • A "private" channel restricts membership/read access (NIP-29 access control), but does not change how content is stored: the relay operator can read it the same as a public channel.

So for any relay deployment (including a Block-hosted community), the operator can read all channel content, public or private. Only NIP-17 gift-wrapped 1:1 DMs are actual ciphertext to the relay.

#1185 ("encrypt 2-party DMs end-to-end with a relay-owned latch") shows this gap was already understood: its own description notes "group DMs (3-9) stay plaintext until Phase 2", but it was closed without merging, so the current state on main is gift-wrap DMs only.

Ask

Is this the intended/accepted privacy model, or a gap that should be closed? Either way, it doesn't seem to be written down anywhere as an explicit disclosure. Suggest adding a short, explicit statement to SECURITY.md (or NOSTR.md) along the lines of: "channel messages, public or private, are plaintext to the relay operator; only NIP-17 DMs are end-to-end encrypted."

References

  • migrations/0001_initial_schema.sql (search_tsv generated column)
  • crates/buzz-core/src/kind.rs (KIND_GIFT_WRAP = 1059)
  • crates/buzz-test-client/tests/e2e_nostr_interop.rs (NIP-17 gift-wrap tests)
  • NOSTR.md
  • SECURITY.md
  • #1185
Dominant language
Rust
Stars
33.7k
Forks
4.4k
Avg merge
1d 21h
Merged PRs (30d)
239

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from block/buzz

All issues in block/buzz

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.