Summary
fedify lookup currently lets -p/--allow-private-address opt into private-address access for URLs discovered by --traverse, but not for follow-up fetches performed by --recurse. This is already documented behavior in the current patch-release line, so I do not think it should be changed in 2.1.x. I am opening this as a follow-up for the next minor release.
Problem
The current rule is hard to reason about because both --traverse and --recurse fetch additional URLs discovered from a user-provided root URL, yet only one mode honors the explicit -p opt-in. For example, fedify lookup --traverse -p http://localhost:8000/users/alice/outbox can follow private discovered URLs, while fedify lookup --recurse=replyTarget -p http://localhost:8000/notes/1 still rejects a private or localhost reply target. That asymmetry makes the option feel mode-specific rather than policy-based.
Proposed solution
In the next minor release, make --recurse honor -p/--allow-private-address the same way --traverse does. The default should stay strict: discovered URLs should still reject private or localhost addresses unless the user explicitly passes -p. This should be treated as an intentional behavior change for a minor release, with matching updates to the CLI help text, docs/cli.md, CHANGES.md, and lookup tests.
Alternatives considered
We could keep the current behavior permanently and rely on the docs to explain it. That keeps the stricter recursive policy, but it leaves --traverse and --recurse with different meanings for the same opt-in flag. Another option would be a separate recurse-specific flag, but that seems harder to discover and probably not worth the added CLI surface.
Scope/dependencies
This would affect the recursive lookup loaders and private-address failure hints in packages/cli/src/lookup.ts, the lookup tests in packages/cli/src/lookup.test.ts, and the user-facing docs in docs/cli.md and CHANGES.md. This issue is only about follow-up object fetches performed by --recurse, not about indirect JSON-LD @context fetches. Since the current behavior is already documented in the 2.1.x line, I think this should target the next minor release rather than a patch release.
Summary
fedify lookupcurrently lets-p/--allow-private-addressopt into private-address access for URLs discovered by--traverse, but not for follow-up fetches performed by--recurse. This is already documented behavior in the current patch-release line, so I do not think it should be changed in 2.1.x. I am opening this as a follow-up for the next minor release.Problem
The current rule is hard to reason about because both
--traverseand--recursefetch additional URLs discovered from a user-provided root URL, yet only one mode honors the explicit-popt-in. For example,fedify lookup --traverse -p http://localhost:8000/users/alice/outboxcan follow private discovered URLs, whilefedify lookup --recurse=replyTarget -p http://localhost:8000/notes/1still rejects a private or localhost reply target. That asymmetry makes the option feel mode-specific rather than policy-based.Proposed solution
In the next minor release, make
--recursehonor-p/--allow-private-addressthe same way--traversedoes. The default should stay strict: discovered URLs should still reject private or localhost addresses unless the user explicitly passes-p. This should be treated as an intentional behavior change for a minor release, with matching updates to the CLI help text, docs/cli.md, CHANGES.md, and lookup tests.Alternatives considered
We could keep the current behavior permanently and rely on the docs to explain it. That keeps the stricter recursive policy, but it leaves
--traverseand--recursewith different meanings for the same opt-in flag. Another option would be a separate recurse-specific flag, but that seems harder to discover and probably not worth the added CLI surface.Scope/dependencies
This would affect the recursive lookup loaders and private-address failure hints in packages/cli/src/lookup.ts, the lookup tests in packages/cli/src/lookup.test.ts, and the user-facing docs in docs/cli.md and CHANGES.md. This issue is only about follow-up object fetches performed by
--recurse, not about indirect JSON-LD@contextfetches. Since the current behavior is already documented in the 2.1.x line, I think this should target the next minor release rather than a patch release.