# Status: 10MB IPFS `cat` fix — code done and pushed; package build/publish still needs your input

## Done (verified, no further action needed)

- Root-caused and fixed the bug: `crates/radicle-cli/src/ipfs.rs`'s `cat()` used ureq's
  `Body::read_to_vec()`, which silently caps reads at 10MB (a default meant for typical JSON
  API responses, not LFS content). Any LFS object over 10MB failed with "the response body is
  larger than request limit: 10485760" — this is exactly what broke `blog-deploy.service` on
  the VPS today, on `assets/posts/hashcash/thumbnail.xcf` (29MB).
- Fix: raised the limit to 1GiB via ureq's `.with_config().limit(...)`. Commit `35f1f972`,
  branch `rad-lfs-ipfs`.
- Verification performed:
  1. Added a `#[cfg(test)]` regression test (`ipfs::tests::cat_round_trips_content_larger_than_ureqs_default_10mb_limit`,
     `#[ignore]`d since it needs a live Kubo daemon) — a 15MB add+cat round-trip.
  2. Confirmed it **fails** with the exact production error when the fix is reverted, and
     **passes** with the fix in place.
  3. Ran the full `radicle-cli` test suite (123 tests) — one pre-existing, unrelated failure
     (`rad_help`, a stale `--help`-output snapshot missing the `lfs` subcommand — confirmed to
     fail identically on the unmodified base commit, nothing to do with this change).
  4. `cargo clippy` clean (one pre-existing warning in an unrelated file/crate).
  5. **Live reproduction against the real file**: moved aside the cached LFS blob for
     `thumbnail.xcf` in `~/Blog/Blog`, ran `rad lfs fetch` with the *old* installed binary —
     reproduced the identical production error byte-for-byte. Ran it again with the *newly
     built* binary — the 10MB error is completely gone; it now correctly proceeds to the next
     step (prompting for a passphrase to decrypt the private-repo content, which is expected
     behavior and unrelated to this bug — I did not attempt to supply a passphrase). Restored
     the blog repo's `.git/lfs/objects` cache back to its original state afterward; no changes
     left in `~/Blog/Blog`.
- Pushed to `origin` (the Forgejo remote, `ssh://git.hswro.org:9022/mab122/radicle-heartwood-lfs.git`),
  branch `rad-lfs-ipfs`, commit `35f1f972..4ae9756a`.

## Not done — needs your call

I did **not** build or publish a package. Stopping here rather than guessing, because:

1. **No existing Forgejo-package publishing path in this repo.** There's a `build/Dockerfile`
   that cross-compiles reproducible `.tar.xz` releases (4 targets: linux/macOS ×
   x86_64/aarch64) via `cargo-zigbuild`, but nothing that uploads anywhere — no CI workflow,
   no `curl`-to-package-registry script, nothing referencing Forgejo's package API. I don't
   know what package type you want registered (generic package? a distro-specific one?), what
   name/version scheme you use there, or the auth (token?) needed to publish to
   `git.hswro.org`'s package registry. I deliberately did not go hunting through credential
   stores (`~/.netrc`, etc.) to find one myself — that's exactly the kind of thing I should ask
   about rather than dig for.
2. **The existing Dockerfile's package doesn't include `rad-lfs-transfer`** — only `rad`,
   `git-remote-rad`, and `radicle-node` get copied into the release tarball. `rad-lfs-transfer`
   is a separate crate/binary (`radicle-lfs-transfer/`) and is required for this fork's whole
   LFS-over-IPFS feature to work on a fresh install — worth fixing in the Dockerfile too, but
   I didn't want to change the packaging script's scope without confirming that's wanted.
3. **Platform scope is unclear.** The existing Dockerfile builds all 4 targets (needed for a
   real public release); the VPS only needs `x86_64-unknown-linux-musl`. Building all 4 takes
   meaningfully longer and needs the macOS SDK blob (`build/macos-sdk-11.3.tar.xz`) and Zig
   cross-toolchain set up — I can do it, but wanted to confirm whether you want the full
   release matrix or just what's needed to update the VPS.

If you want me to keep going on this (rather than picking it up in the session that already
knows this fork's packaging conventions), I'd need: the Forgejo package type/target and an
auth token (however you'd like to provide it — e.g. via an env var you set, not me searching
for it), confirmation on whether to add `rad-lfs-transfer` to the Dockerfile's package list,
and whether to build the full 4-target matrix or just linux/x86_64.