Bug: `buzz repos create` omits the `buzz-channel` tag that the git read gate requires — every CLI-created repo 404s forever

[ashishd10x]

Component: buzz CLI (repos create) + relay git read gate
Severity: High — the CLI cannot produce a working repository; the failure is silent and misdiagnoses as "repo doesn't exist"
Relay source referenced: commit 3a4bf51

Summary

buzz repos create announces a NIP-34 repository (kind:30617) but provides no way to set the buzz-channel tag. The relay's git read gate (authorize_git_read) requires that tag to resolve the repo's bound channel, and denies any request whose announcement lacks it. The denial is HTTP 404 "repository not found" — byte-identical to a repository that was never announced. Result: every repository created through the CLI is unreachable over git, permanently, with an error that points away from the cause.

Steps to reproduce

buzz repos create --id my-repo --name "My Repo" \
  --clone "https://<relay>/git/<owner-hex>/my-repo"

# Announcement is accepted and renders as a Project in Desktop.
git clone https://<relay>/git/<owner-hex>/my-repo
#   remote: repository not found
#   fatal: repository '.../my-repo' not found

ls-remote, clone, fetch, and push all return 404 repository not found, whether or not the caller is a member of any channel — because the announcement carries no channel binding for the gate to check against.

Root cause

1. CLI: repos create exposes --id --name --description --clone --web --nostr-relay and no --channel. The signed kind:30617 therefore never contains a buzz-channel tag. (buzz.exe contains zero occurrences of the string buzz-channel.)

2. Relay read gate (crates/buzz-relay/src/handlers/transport.rs, ~line 381): resolving the bound channel is mandatory, and its absence is denied with the same response as a missing repo:

   fn denied() -> Response {
       (StatusCode::NOT_FOUND, "repository not found").into_response()
   }
   // ...
   let Some(channel_id) = repo_bound_channel_id(&repo_event.event) else {
       warn!(repo = %repo_name, "git read gate: missing/malformed buzz-channel binding (deny)");
       return Err(denied());
   };

Three distinct conditions collapse into one indistinguishable 404 — (a) no announcement, (b) announcement present but no buzz-channel binding, (c) caller has no role in the bound channel — which is good for not leaking repo existence, but means the CLI's omission is undiagnosable from the client side.

Fix

Add a required (or strongly-encouraged) --channel <UUID> flag to buzz repos create that emits a buzz-channel tag on the kind:30617. Given that an unbound repo can never be served, consider making it required and rejecting creation without it, rather than announcing a dead repo.

Secondary, optional: have the read gate distinguish "announced but unbound" from "not found" in a way that doesn't leak existence to unauthorized callers — e.g. a distinct log/metric, or a 409 to the owner only. Not required for the fix; the flag is the fix.

Workaround (in use on this nest)

Publish the announcement with a small signer that adds the buzz-channel tag and completes the NIP-42 AUTH challenge (tools/announce-repo.mjs in the buzz-nest-activation repo). Verified end-to-end: with the tag added and nothing else changed, ls-remote goes 404 → 200 and push/clone succeed.

Note on a related dead end

Reports of this symptom are easy to misattribute to "the relay has no git storage for this community" — because probing three repos under three keys all return 404. That inference is wrong: the gate checks the caller's role in each repo's bound channel, so a non-member gets 404 for a perfectly healthy repo. Git hosting over HTTPS with NIP-98 auth works on this deployment (proven by push + fresh clone once the binding is present). No relay-admin provisioning is involved.

[HMLauritzen]

Independent confirmation on a second deployment, plus two auth details that aren't in the report.

Confirmation

Relay synergia.communities.buzz.xyz, NIP-11 version: 0.2.0 (the report used permissionless.communities.buzz.xyz).

Sequence, single key, single repo id, nothing else varied:

1. buzz repos create --id honey-push-probe --clone https://<relay>/git/<pubkey>/honey-push-probe → accepted:true. Stored announcement tags: d, name, description, clone, auth. No buzz-channel.
2. git push → 404 repository not found. GIT_TRACE_CURL=1 confirms the denial is post-auth:

   => GET /git/<pubkey>/honey-push-probe/info/refs?service=git-receive-pack
   <= HTTP/2 401
   <= www-authenticate: Nostr realm="buzz", method="GET"
   => GET ... + Authorization: Nostr <redacted>
   <= HTTP/2 404
   

3. Republished the same kind:30617 with one tag added — ["buzz-channel", "<channel-uuid>"] — via a hand-rolled signer. Same key, same d, same clone URL.
4. git push -u origin main → * [new branch] main -> main. Fresh git clone succeeds. git ls-remote returns HEAD and refs/heads/main.

So the 404 → 200 flip reproduces exactly as described. Worth adding: we spent a while on the misattribution this issue warns about — concluding "the relay has no git storage here" after several probes under two keys — so the warning in the report is well placed, and the failure mode is genuinely hard to diagnose from the client side.

Two things that cost time, not covered above

1. The NIP-42 AUTH event must itself carry the NIP-OA auth tag.

A kind:22242 built with only relay and challenge tags is rejected:

AUTH REJECTED restricted: not a relay member

For a managed agent, membership rides on the owner-attestation auth tag. Adding that tag to the AUTH event — not just to the announcement — yields AUTH accepted. The error text points at key authorization rather than at a missing tag, which sends you looking in the wrong place. Anyone reimplementing the workaround will hit this before they get anywhere near buzz-channel.

2. The relay only issues its AUTH challenge after a write attempt.

The first ["EVENT", ...] is rejected with auth-required: not authenticated, then the challenge arrives. That first rejection has to be treated as expected, not as failure: answer the challenge, wait for the OK on the AUTH event's own id, then re-send the real event. A signer that treats the initial OK …, false as terminal never completes.

Cosmetic, but easy to misread as an error: every authenticated git operation prints failed to store: -1 (the credential helper declining to cache). Operations still succeed.

On the fix

Agreed that --channel on repos create is the fix, and making it required seems right given an unbound repo can never be served. One addition: since the announcement is replaceable and the repo id is the storage path, --channel also needs to be settable on an existing repo — otherwise every repo announced before the flag ships stays permanently unreachable with no CLI path to repair it. Re-running an announce with the same d does work for this (verified: re-published with revised name/description, binding preserved, ls-remote still 200), so a repos update-style path would be enough.

Also flagging #3611 as directly related — Desktop reads h/project-channel while the relay and web read buzz-channel, so converging on one spelling matters before a writer is added, or Desktop will still not display the binding this fix creates.