@movq@www.uninformativ.de, having an issue fetching a twtxt context. I am getting:
Trying to fetch "#mowsvgq" from Yarn pod https://txt.sour.is ...
Trying to fetch "#mowsvgq" from Yarn pod https://twtxt.net ...
Twt could not be found
Yet, the twtxt is there: https://twtxt.net/twt/mowsvgq. Bug, or something else?
@quark@ferengi.one That’s confusion on Yarn’s part, I’d say.
Yarn’s API says that twt comes from the URL http://twtxt.prismdragon.net/twtxt.txt – but when using that URL for hashing, I get the hash bjs6aua instead of mowsvgq. That’s not the correct hash, so jenny says the twt could not be found.
Inspecting the feed using jenny -D … yields the correct hash. When looking at the raw feed, we can see:
# nick = gallowsgryph
# description = Green living and permaculture enthusiast, writer, otherkin, weird.
# url = http://prismdragon.net/twtxt.txt
# url = https://dreamwidth.org/gallowsgryph/
# avatar = http://prismdragon.net/img/gallows.png#20241025
So it’s a different URL. When I use http://prismdragon.net/twtxt.txt for hashing, I get the correct hash.
@movq@www.uninformativ.de interesting! So, what would the fix be, in this case, do you know? Aware of this, @prologic@twtxt.net?
@quark@ferengi.one At some point, Yarn must have fetched the feed and used the correct URL (otherwise it wouldn’t have gotten the correct hash). And at that point, it should have updated the uri field for this twt in its database, I guess? Disclaimer: I know nothing about the internals of Yarn. 😅
Is there a bug on my side?
@prologic@twtxt.net looks like. See @movq@www.uninformativ.de’s explanation.
@bender@twtxt.net @movq@www.uninformativ.de AFAICT this isn’t a bug with yarnd, but a. bug with the feed itself. The feed is now completely broken in that regard. See #27nifeq
@movq@www.uninformativ.de I’m assuming jenny is doing some kind of validation and verifying if that Twt really does exist on the feed uri? 🤔 But the hash is all kinds of wrong now because @gallowsgryph for whatever reason decided it might be a good idea to have a 2nd # url that doesn’t actually point to the same Twtxt feed (bad idea).
@prologic@twtxt.net I’m not sure this isn’t a bug. The feed’s URL must have changed at some point but Yarn is still using the old URL for hashing. And it’s inconsistent now:
curl -s -H 'Accept: application/json' https://twtxt.net/twt/mowsvgq
This gets you a twt which, when hashed again now using all the information from that API reply, does not yield the hash mowsvgq but bjs6aua.
But when you use the URL http://prismdragon.net/twtxt.txt for hashing instead of http://twtxt.prismdragon.net/twtxt.txt, it’s mowsvgq.
So I would expect Yarn to either know about mowsvgq (showing the new URL http://prismdragon.net/twtxt.txt) or about bjs6aua (showing the old URL http://twtxt.prismdragon.net/twtxt.txt). But not mowsvgq with the old URL. 😅
I don’t see how the second # url = metadata field is relevant here. 🤔
@movq@www.uninformativ.de Don’t we use the last url for hashing? 🤔
@prologic@twtxt.net As per https://dev.twtxt.net/doc/metadataextension.html, it’s the first URL. 😅 I think using the last URL was one of the new proposals. Or has that already been implemented? 🤯
@movq@www.uninformativ.de Hmmm now I’m confused 😅 I’ve made no changes anywhere – we still need to all agree, especially client authors and maintainers 🤣
@prologic@twtxt.net I haven’t changed anything, either. 😅 jenny uses the first URL: https://www.uninformativ.de/git/jenny/file/jenny.html#l191
@movq@www.uninformativ.de I will check when I get home 😅
I think it uses the first # url too. See here and here – @xuu Can you confirm this to be the case? 🙏 GetN("url", 0) will return the first found # url comment right?
@prologic@twtxt.net that should be right
@xuu Thanks!