Summary
The hosted relay at communities.buzz.xyz accepts git pushes only up to ~5 MiB of pack body, which blocks seeding any real-world repo (ours is a ~210 MiB history). The relay code's own default for BUZZ_GIT_MAX_PACK_BYTES is 500 MB (crates/buzz-relay/src/config.rs), so the hosted deployment appears to run ~1% of stock. Requesting either a raise on hosted community relays or documentation that this is the intended hosted tier limit. Separately, the failure modes for oversized/large pushes are opaque enough that they cost us a full diagnostic session — two DX issues below.
All findings verified live on Buzz 0.5.2 against firc.communities.buzz.xyz, 2026-07-30, with NIP-98 auth working and small pushes succeeding throughout.
1. Hosted pack limit ~5 MiB (config request)
With client buffering fixed (see item 2), pushes of incompressible test blobs:
| Pack size |
Result |
| ~5.0 MiB |
success (4.5 s) |
| ~5.45 MB |
TLS abort mid-upload (LibreSSL bad record mac / broken pipe) |
| 6, 8, 9, 10, 20, 25, 30 MB |
same failure |
| 201.49 MiB real snapshot (5,526 objects) |
HTTP 401 / curl 56 in ~2 s |
A single 25.4 MB tracked blob fails on its own, so multi-push chunked seeding cannot work around it — git can't split one blob. Cloudflare fronts the relay and is not the binding limit (its body allowance is far higher); enforcement matches git_max_pack_bytes in api/git/transport.rs.
Ask: raise BUZZ_GIT_MAX_PACK_BYTES on hosted community relays toward the code default (500 MB), or publish the hosted limit so operators can plan around it.
2. DX: pack over limit dies as a TLS abort, not a clean error
An over-limit push terminates mid-body with curl 55/56, LibreSSL bad record mac — no HTTP status reaches the client. A clean 413 (or a sideband error naming the limit) would have turned a multi-hour diagnosis into one error message.
3. DX: chunked Transfer-Encoding push fails with instant 401
git switches to chunked transfer for any push body over http.postBuffer (default 1 MiB). Against the NIP-98-authenticated endpoint this fails instantly with HTTP 401 / curl 56 — the auth challenge can't be satisfied with a non-replayable chunked body. Workaround is git config http.postBuffer 536870912, verified (same 5 MB pack: fails chunked, lands buffered). Worth documenting prominently, or handling chunked bodies server-side, since every stock git client over 1 MiB hits this before ever seeing the real limit.
(Minor, observed while probing: sub-1MB requests intermittently drew 403 with a __cf_bm cookie — Cloudflare bot management challenging git's HTTP client. Mentioning it since it makes the failure surface look non-deterministic to operators.)
Summary
The hosted relay at
communities.buzz.xyzaccepts git pushes only up to ~5 MiB of pack body, which blocks seeding any real-world repo (ours is a ~210 MiB history). The relay code's own default forBUZZ_GIT_MAX_PACK_BYTESis 500 MB (crates/buzz-relay/src/config.rs), so the hosted deployment appears to run ~1% of stock. Requesting either a raise on hosted community relays or documentation that this is the intended hosted tier limit. Separately, the failure modes for oversized/large pushes are opaque enough that they cost us a full diagnostic session — two DX issues below.All findings verified live on Buzz 0.5.2 against
firc.communities.buzz.xyz, 2026-07-30, with NIP-98 auth working and small pushes succeeding throughout.1. Hosted pack limit ~5 MiB (config request)
With client buffering fixed (see item 2), pushes of incompressible test blobs:
LibreSSL bad record mac/broken pipe)A single 25.4 MB tracked blob fails on its own, so multi-push chunked seeding cannot work around it — git can't split one blob. Cloudflare fronts the relay and is not the binding limit (its body allowance is far higher); enforcement matches
git_max_pack_bytesinapi/git/transport.rs.Ask: raise
BUZZ_GIT_MAX_PACK_BYTESon hosted community relays toward the code default (500 MB), or publish the hosted limit so operators can plan around it.2. DX: pack over limit dies as a TLS abort, not a clean error
An over-limit push terminates mid-body with
curl 55/56, LibreSSL bad record mac— no HTTP status reaches the client. A clean413(or a sideband error naming the limit) would have turned a multi-hour diagnosis into one error message.3. DX: chunked Transfer-Encoding push fails with instant 401
git switches to chunked transfer for any push body over
http.postBuffer(default 1 MiB). Against the NIP-98-authenticated endpoint this fails instantly withHTTP 401 / curl 56— the auth challenge can't be satisfied with a non-replayable chunked body. Workaround isgit config http.postBuffer 536870912, verified (same 5 MB pack: fails chunked, lands buffered). Worth documenting prominently, or handling chunked bodies server-side, since every stock git client over 1 MiB hits this before ever seeing the real limit.(Minor, observed while probing: sub-1MB requests intermittently drew
403with a__cf_bmcookie — Cloudflare bot management challenging git's HTTP client. Mentioning it since it makes the failure surface look non-deterministic to operators.)