Document relay-operator visibility for channel messages (public and private)
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
- Domain
- documentation, security
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.sqlgeneratessearch_tsvfrom plaintextcontentfor every kind except1059, which is explicitly excluded as "(NIP-17 ciphertext)".NOSTR.mddocuments 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.mdSECURITY.md- #1185
- Dominant language
- Rust
- Stars
- 33.7k
- Forks
- 4.4k
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 239
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from block/buzz
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
workflow_sink's mention parser never masks code regions — @name inside a code span wakes the agent Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 Half a day Newbie friendliness 88/100
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
bitcoindevkit/bdk-ffi#1125 ·