Repository navigation
Relay never seeds git repos on kind:30617 announce — repos stay 404 "repository not found" indefinitely #3527
Description
Summary
On the hosted relay permissionless.communities.buzz.xyz (NIP-11 reports software: https://github.com/block/buzz, version: 0.2.0), announcing a repo via kind:30617 is accepted and stored, but the git smart-HTTP endpoint never becomes available. GET /git/<owner-hex>/<repo-id>/info/refs?service=git-upload-pack (and git-receive-pack) returns 404 repository not found indefinitely, so the repo can never be pushed to or cloned.
Per current source, announce is the only provisioning path: handle_git_repo_announcement in crates/buzz-relay/src/handlers/side_effects.rs reserves the name in Postgres and seeds the empty-manifest pointer that info_refs requires (crates/buzz-relay/src/api/git/transport.rs — Ok(None) → 404). The git router exposes only info/refs, git-upload-pack, git-receive-pack, so there is no other way to create a repo.
Reproduction (all requests NIP-98/Nostr-authenticated; unauthenticated requests correctly 401)
- Publish kind:30617 with
d=<repo-id>and a clone URLhttps://permissionless.communities.buzz.xyz/git/<owner-hex>/<repo-id>. Event is accepted ({"accepted":true}) and retrievable. GET /git/<owner-hex>/<repo-id>/info/refs?service=git-upload-packwith valid signed auth →404 repository not found, still true 2+ hours later.- Same-owner re-announce — which per the code comments "ensures the pointer rather than assuming it" — is accepted but the endpoint still 404s. This rules out a one-time race; the seed side effect is not taking effect at all.
- Reproduced with three separate identities/repos on this relay, including the community owner's key.
Why it is silent
ingest.rs treats side effects as best-effort: if let Err(e) = handle_side_effects(...) { warn!(..., "Side effect failed: {e}") } — the announcement is stored even when seeding fails, and the underlying error (object-store put, missing git_repo_names migration, etc.) exists only in relay server logs. Clients cannot distinguish "seeded" from "seed silently failed".
Relay operators: please check server logs for Side effect failed on kind 30617 on this deployment. If the deployed build predates the seeding feature, a redeploy may be all that is needed.
Suggested improvements
- Surface seed failures to the announcing client (reject the 30617, or include a warning in the OK message) instead of storing an announcement for a repo that can never exist.
- Consider a health/status probe for the git store so operators notice storage misconfiguration before users hit 404s.
Activity
tlongwell-block commentedon Jul 29, 2026
Fix is up: #3626.
What you hit: repos announced with vanilla NIP-34 (no
buzz-channeltag on the kind:30617) have no channel-membership ACL, so the SEC-005 read gate denies every fetch with a bare 404 — forever, with no hint why.What the fix does:
buzz repos bind --id <repo> --channel <channel-uuid>. Pushes get the same guidance.buzz repos bindcommand rebinds an existing announcement to a channel without re-announcing.buzz repos createalso gains--channel.Until it lands, the workaround is to re-publish your 30617 with a
buzz-channeltag pointing at a channel you're a member of.fix(git): channel binding tooling + author remediation for unbound re…
jackjackbits commentedon Jul 30, 2026
jackjackbits commentedon Jul 30, 2026
Thanks — confirming the channel-binding workaround works on the deployed relay (fresh 30617 with a
buzz-channeltag → endpoint serves immediately). But applying it to the original repo surfaced a second silent-failure mode, this time in the name registry.git_repo_namesreservations are never released, and cross-owner collisions are invisible to the author.Sequence that produced it (community
permissionless.communities.buzz.xyz):9559ef56…announcedbitchat(vanilla NIP-34, nobuzz-channel). Per the fixed understanding, this seeded fine — it was only unreadable due to the missing binding. Crucially it also reserved the name.82341f88…later announcedbitchatunder their own key — including a re-announce with thebuzz-channeltag after your fix guidance.handle_git_repo_announcementrejects it ("repo name 'bitchat' already taken by another owner"), but ingest stores the event and only logs a warning, so from the author's side the announcement is accepted and the endpoint 404s forever. Same UX black hole as the original report, different cause.9559ef56…published a NIP-09 kind:5 a-tag deletion of its 30617.handle_a_tag_deletiontakes the generic NIP-33 branch and soft-deletes the event row only — thegit_repo_namesrow is untouched. There is no user-facing way to release a name.Empirical confirmation: after the deletion, a fresh announce of
bitchatby82341f88…(with channel tag) still 404s, while a re-announce by9559ef56…(with channel tag) makes/git/9559ef56…/bitchatserve immediately → the reservation is stranded with the deleted announcement's key.Asks:
bitchatreservation held by9559ef56…so82341f88…can claim it. Not urgent — both keys belong to the same human/agent pair and we have a working repo under the agent key meanwhile (the managed-agent-owner push-authority path works nicely, for what it's worth).Minor client-interop note while we're here: pushes with packs >1MB fail with
RPC failed; HTTP 401because git streams them chunked and can't replay the body for the NIP-98 challenge dance;http.postBuffer=500mworks around it. Might be worth a line in the docs next to the credential-helper setup.fix(git): channel binding tooling + author remediation for unbound re…
fix(git): channel binding tooling + author remediation for unbound re…
Rust core audit fixes: image cap, workflow_state purge, admin grant, …