Skip to content

feat(cli): support visibility on channels update#1350

Open
tlongwell-block wants to merge 1 commit into
mainfrom
feat/cli-channel-visibility
Open

feat(cli): support visibility on channels update#1350
tlongwell-block wants to merge 1 commit into
mainfrom
feat/cli-channel-visibility

Conversation

@tlongwell-block

Copy link
Copy Markdown
Collaborator

What

Add --visibility <open|private> to buzz channels update, so a channel's visibility can be flipped after creation from the CLI. Previously visibility was a create-time-only field: channels create took --visibility, but channels update only handled name/description/ttl.

Why it's small

The plumbing below the CLI already existed:

  • SDKbuzz_sdk::build_update_channel already accepts a visibility arg, validates open|private, and emits the ["visibility", v] tag on the kind:9002 edit-metadata event (crates/buzz-sdk/src/builders.rs:572). Already covered by SDK tests (:2069, :2086).
  • Relayside_effects.rs already validates the tag value, gates it behind owner/admin auth, applies the DB update, invalidates the visibility/accessible-channel caches, and emits a visibility_changed event (:382-397, :424-437, :1075-1107).

The CLI just hardcoded None for that arg and exposed no flag. This PR wires the flag through — no SDK or relay changes.

Change

  • lib.rs: add visibility: Option<ChannelVisibility> to the Update clap variant (value_enum, so invalid values are rejected at parse time with [possible values: open, private] — matching channels create).
  • channels.rs: thread it into cmd_update_channel, include it in the no-op guard + error message, and pass it to build_update_channel.

No public alias — held to open|private to match create, the SDK, and relay validation (one vocabulary).

Testing

  • cargo test -p buzz-cli -p buzz-sdk — green (135 + 205).
  • cargo clippy -p buzz-cli — clean.
  • cargo fmt -p buzz-cli --check — clean.
  • Live smoke against a real channel (f5bf2e54-...), each flip confirmed via the stored kind:9002 visibility tag on the relay:
buzz channels update --channel <uuid> --visibility private   # -> accepted; relay stores ["visibility","private"]
buzz channels update --channel <uuid> --visibility open      # -> accepted; relay stores ["visibility","open"]
buzz channels update --channel <uuid> --visibility public    # -> rejected at parse: [possible values: open, private]

Review

Planned and diff-reviewed with Wren; independently confirmed not already wired by Max.

Visibility (open/private) was a create-time-only field: `channels
create` took `--visibility`, but `channels update` only handled
name/description/ttl, so there was no way to flip a channel's
visibility after creation from the CLI.

The plumbing already existed below the CLI: `buzz_sdk::build_update_channel`
accepts a `visibility` arg and emits the `["visibility", v]` tag on the
kind:9002 edit-metadata event, and the relay validates the value, gates
it behind owner/admin auth, applies the DB update, invalidates the
visibility/accessible-channel caches, and emits a visibility_changed
event. The CLI just hardcoded `None` and exposed no flag.

Wire `--visibility <open|private>` through `channels update` as a clap
ValueEnum (matching `channels create`), so invalid values are rejected
at parse time, and thread it into build_update_channel. Visibility is
also included in the no-op guard and its error message.

Live-tested against a real channel: open->private->open, each flip
confirmed via the stored kind:9002 visibility tag.

Co-authored-by: Tyler Longwell <tlongwell@block.xyz>
Signed-off-by: Tyler Longwell <tlongwell@block.xyz>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant