@falsifian@www.falsifian.org In my opinion it was a mistake that we defined the first url field in the feed to define the URL for hashing. It should have been the last encountered one. Then, assuming append-style feeds, you could override the old URL with a new one from a certain point on:

# url = https://example.com/alias/txtxt.txt
# url = https://example.com/initial/twtxt.txt
<message 1 uses the initial URL>
<message 2 uses the initial URL, too>
# url = https://example.com/new/twtxt.txt
<message 3 uses the new URL>
# url = https://example.com/brand-new/twtxt.txt
<message 4 uses the brand new URL>

In theory, the same could be done for prepend-style feeds. They do exist, I’ve come around them. The parser would just have to calculate the hashes afterwards and not immediately.

On second thought, the same rule with the last physically encountered URL when starting parsing from the top applies to prepend-style feeds as well. Much simpler and cleaner this way. Should also fit prepend-style feeds better I reckon.

For the record, out of the 89 feeds that I follow, only a single one has more than one # url = field:

gemini://gemini.ctrl-c.club/~nristen/twtxt.txt

And I wonder if @nristen@gemini.ctrl-c.club is aware that the order of those fields matter. 🤔

I say fuck gemini, and gopher. 😅

Heck, fuck http too. https, or die.

@bender@twtxt.net there is a certain simplicity to that. 😅