Yeah, lol, fuck off. Tried to reproduce that hashing issue, thus playing around with Go a little bit. And what did I find?

$ tree ~/.config/go
/home/user/.config/go
└── telemetry
    ├── local
    │   ├── asm@devel-devel-linux-amd64-2026-07-14.v1.count
    │   ├── compile@devel-devel-linux-amd64-2026-07-14.v1.count
    │   ├── go@devel-devel-linux-amd64-2026-07-14.v1.count
    │   ├── link@devel-devel-linux-amd64-2026-07-14.v1.count
    │   ├── upload.token
    │   └── weekends
    └── upload

4 directories, 6 files

It collects and uploads “telemetry” now.

No.

(Don’t tell me how I can turn that off. Not interested. This is a compiler and it wants to track me, without asking for consent. That’s a no-go.)

@david@daiwei.me It really is almost impossible to debug these hash issues. Only thing I can do is some trial-and-error, to see if I somehow end up at pmrf6ftxsdhr instead of ksou5aqw7w5a. So far, no luck. 😅

@prologic@twtxt.net For what it’s worth, the twt hash extension is specifically modeled after yarnd’s implementation with all the quirks coming from Go’s stdlib: https://twtxt.dev/exts/twt-hash.html#timestamp-format

“All timezones representing UTC must be formatted using the designated Zulu indicator Z rather than the numeric offsets +00:00 or -00:00. If the timestamp does not explicitly include any timezone information, it must be assumed to be in UTC.”

🥳 Finally! After nearly 4 years, yarnd v0.16.0 “Silver Sojourner” is out! 🚀 Twt Hash v2, SQLite FTS5 search, HTMX-powered UI, first-time setup wizard and literally hundreds of bug fixes 🐛

Release notes: https://git.mills.io/yarnsocial/yarn/releases/tag/0.16.0

Upgrading is fully automatic — the Twt Hash v2 migration re-fetches all feeds on first start, so expect the first cycle to be a bit heavier. Images on Docker Hub as prologic/yarnd:0.16.0 👌

cc @kat@yarn.girlonthemoon.xyz @abucci@anthony.buc.ci @shinyoukai@yume.laidback.moe @eldersnake@we.loveprivacy.club 🙏

@bender@twtxt.net All the other ones worked but this broke? What’s different here? To which twt hash should this be a reply? 🤔

@bender@twtxt.net No idea. I can only tell you that the correct hash would have been rwzz277nkyju for this line:

[2026-07-11 14:47:17+00:00] [(#5bpwpdcjnhcz) <a href="https://yarn.girlonthemoon.xyz/external?uri=https://daiwei.me/twtxt.txt">@david<em>@daiwei.me</em></a> (This thread is broken again on my end. Another bug or fix not released yet? 😅)]

Fixed the broken hashes in the Twtxt App (https://twtxt.app) 🥳 It was hashing your twts with a client-side timestamp the server never used 🤦‍♂️ Now it keeps the canonical created/hash the pod (or twtd) returns, and the GitHub/Gitea backends write a # url = preamble so every client hashes your feed the same way. Thanks @fastidious@tilde.town for the report 🙏

@prologic@twtxt.net I linked you some of my findings on the twtxt.app on IRC. The main problem is the hashing. Totally broken. But you have got to give it some thought, because GitHub hosting of the feed is tricky (even more so if they are CNAMEing their domain to it). It is also finicky because Pages is auto-enabled on username.github.io, so actions must run each time you twt.

FYi 👋 I’m aware of an optimist precomputed hashing bug on the new twtxt.app 🤯 Trying to work with @bender@twtxt.net remotely on my vacation yo fix it 🤣

← expected hash

← expected hash

← expected hash

@javivf@adn.org.es Heh! 😏 I don’t get it haha, but I just saw your post about supporting the v2 Hash ext, nice! 👍

Twtxtory v0.0.3 supports Twt Hash v2 Extension 🍾

@balloonfu-sen@yarn.girlonthemoon.xyz Do you mind git pull && make build and updating your yarnd instance so it’s in-line with the new Hash v2 spec 🙏

@GabesArcade@gabesarcade.com by asking me nicely 🤣 Which you just did! If you either provide me a desired username and password and secure medium to give this to you I can do that easily, or alternative a desired username and email address (never stored, only hashed), after which you can “Reset password”.

🚨 jenny was broken due to the switch to v2 hash tags.

I pushed a hotfix to main, but this needs a few more test cases. I’ll do that tomorrow.

Haha, I just noticed that this is the first twt hash v2 that I reply to. \o/ Oh yeah!

@lyse@lyse.isobeef.org Bummer, but thanks for the heads-up. 🙂

Where are you seeing it? I remember running across a similar issue before, but I thought I already fixed it by falling back to the hash URL.

That having been said, I like your idea of defaulting to the subscribed / “following” URL.

Also, there appears to be an extra “r” in my handle in your mention (it’s “itsericwoodward”, not “itsericwoordward”). No big deal, just wanted to mention it.

@itsericwoordward@itsericwoodward.com I just want to let you know that your mention completion seems to be broken. :-) The URL is duplicated with a comma in between. Actually, the protocols differ. I suspect that you extract all url metadata fields from the feed, not only the canonical one used for hashing (the first one) and join them. I’m not completely sure, I would need to read up on the specs (it’s already past bed o’clock, though), but I guess that there is no explicit rule for picking the mention URL. Without having thought about it too much, I reckon the safest bet is to stick to the hashing URL when in doubt and the URL that was used to subscribe to the feed is not available for whatever reason. The URL from the subscription list is probably even better.

@prologic@twtxt.net @bender@twtxt.net Thanks! Yeah, it already supports Twt Hash via twtxt-lib (both v1 and v2, when the time is right), plus most of the other features (multiline, user-agent, and metadata), and I’m working on (re-)implementing threading, mentions, and hash filtering (to make conversations easier to follow).

Here’s a current snapshot of my local version, in case anyone is interested:

I was wondering why all the twt hashes in my replies today were still so short. I was ahead of the times. The Twt Hash v2 Epoch only begins next month.

@itsericwoodward@itsericwoodward.com Excited to see twtxt tooling in the Node ecosystem! Any plans to implement the Twtxt v2 extensions? Things like Twt Hash + Subject (proper threading), Multiline, etc. — all documented at https://twtxt.dev 👀

@movq@www.uninformativ.de I really like your style of writing, btw. It’s much calmer and less aggressive then mine. :-) When I turned my bullet points into paragraphs, I got a bit mad in the process.

Sure, feel free to include anything you want. Regarding citing, this is where twtxt falls short in my opinion. Especially with feed rotation, classic links die quickly. Message hashes only help so much. Nobody outside the twtxt universe knows how to deal with them. So, not perfect for inclusion on a web page. Linking to a thread or message on some yarnd instance might be the more user-friendly option. But the disadvantage is that it’s “just” a mirror, not the primary or original source. In all reality, this could be considered splitting hairs, though.

I should have probably written a proper article. That would have given me time to review the result more carefully, too. ;-) Perhaps that’s something for the future. But honestly, I’m not sure if I really want to waste my time and energy on that subject. So many other fun or useless things come to mind right away that I could do instead. 8-)

So, yeah, do whatever feels best to you. I don’t mind being cited or linked, but I also don’t mind not to be cited or not to be linked to. :-D Not a helpful answer, I know. Sorry. ;-) But anyway, thanks for asking, mate! I do appreciate it.

To finish my thought, linking to my frontpage is probably also useless, since I deliberatly do not have a table of contents there. In fact, my entire frontpage is rather silly.

@lyse@lyse.isobeef.org Thanks for the heads-up.

It lead me to publish an updated version of twtxt-lib (v0.10.0) which supports the v2 hashing algorithm: https://twtxt-lib.itsericwoodward.com/

Hey all my dear twtxters! Again, please have a look at https://git.mills.io/yarnsocial/twtxt.dev/pulls/28 so that we can button the Twt Hash v2 Extension up soon. Love to get some feedback, comments, questions, doubts, critiques, improvements, etc.

@rdlmda@rdlmda.me most of our conversations used to be about twtxt, I am not going to lie. Lately? Not so much. It turns out (a) we don’t need a longer hash, (b) we don’t care so much about changing addressing, and © I am just Bender, what else can I say? :-D :-P

@prologic@twtxt.net well, it isn’t rocket science, is it? 😅 Yet, without using the hashes and starting to follow people, it is very, very rudimentary. I know, I know, there were a couple of years during which people lived just fine without those. Yet, once you get used to certain things, there is no going back.

@prologic@twtxt.net In my opinion, the integrity isn’t lost. The same input data always result in the same output hash, no matter when you calculate the hashes. It’s true that a corrupt database contents yields to corrupt hashes, but then you have a whole bigger problem than just receiving different hashes. :-D

@zvava@twtxt.net By hashing definition, if you edit your message, it simply becomes a new message. It’s just not the same message anymore. At least from a technical point of view. As a human, personally I disagree, but that’s what I’m stuck with. There’s no reliable way to detect and “correct” for that.

Storing the hash in your database doesn’t prevent you from switching to another hashing implementation later on. As of now, message creation timestamps earlier than some magical point in time use twt hash v1, messages on or after that magical timestamp use twt hash v2. So, a message either has a v1 or a v2 hash, but not both. At least one of them is never meaningful.

Once you “upgrade” your database schema, you can check for stored messages from the future which should have been hashed using v2, but were actually v1-hashed and simply fix them.

If there will ever be another addressing scheme, you could reuse the existing hash column if it supersedes the v1/v2 hashes. Otherwise, a new column might be useful, or perhaps no column at all (looking at location-based addressing or how it was called). The old v1/v2 hashes are still needed for all past conversation trees.

In my opinion, always recalculating the hashes is a big waste of time and energy. But if it serves you well, then go for it.

@zvava@twtxt.net The problem you now then is you lose integrity of the message content if you compute the hashes at runtime rather than on the way in. So if your message content or database becomes corrupt in any way, so do your hashes.

@lyse@lyse.isobeef.org while caching those is a good idea the problem is baking data that can be calculated into the database instead of some cache, because post hashes are not fixed and change for every post edit. you can always easily look up other twts by hash with a cached lookup table, but now you’re not locked into them so supporting hashv2 or other hash variants or any other solution becomes far easier

@zvava@twtxt.net I might misunderstand what you wrote, but only hashing the message once and storing the hash together with the message in the database seems a way better approch to me. It’s fixed and doesn’t change, so there’s no need to recompute it during runtime over and over and over again. You just have it. And can easily look up other messages by hash.

very good blog post that reminded me why it’s taking so long to ship bbycll — previously i had computed the hashes of every post before storing them in the database, after realizing it’s a much better idea to compute the hashes during runtime and only store the post content & timestamp i’m now having to rewrite every function that reads & writes data. i hope the reason as to why i lost motivation is obvious — thankfully i caught it early enough so that once i’m done rewriting just those functions i should™ be able to finalize 1.0-rc with little hassle

⇒ the cardinal sin of software architecture: the unnecessary distribution, replication, or restructuring of state, both in space and time.

@lyse@lyse.isobeef.org Damn. That was stupid of me. I should have posted examples using 2026-03-01 as cutoff date. 😂

In my actual test suite, everything uses 2027-01-01 and then I have this, hoping that that’s good enough. 🥴

def test_rollover():
    d = jenny.HASHV2_CUTOFF_DATE
    assert len(jenny.make_twt_hash(URL, d - timedelta(days=7), TEXT)) == 7
    assert len(jenny.make_twt_hash(URL, d - timedelta(seconds=3), TEXT)) == 7
    assert len(jenny.make_twt_hash(URL, d - timedelta(seconds=2), TEXT)) == 7
    assert len(jenny.make_twt_hash(URL, d - timedelta(seconds=1), TEXT)) == 7
    assert len(jenny.make_twt_hash(URL, d, TEXT)) == 12
    assert len(jenny.make_twt_hash(URL, d + timedelta(seconds=1), TEXT)) == 12
    assert len(jenny.make_twt_hash(URL, d + timedelta(seconds=2), TEXT)) == 12
    assert len(jenny.make_twt_hash(URL, d + timedelta(seconds=3), TEXT)) == 12
    assert len(jenny.make_twt_hash(URL, d + timedelta(days=7), TEXT)) == 12

(In other words, I don’t care as long as it’s before 2027-01-01. 😏😅)

The funny thing is, Yarn moving to Twt Hash v2 sounds a tad more optimistic than Git adopting SHA-256.

Git is several years too late, while Yarn is pretty much on time.

Hm, so regarding the hash change:

https://git.mills.io/yarnsocial/twtxt.dev/pulls/28

How about 2026-03-01 00:00:00 UTC as the cut-off date? 🤔

All my newly added test cases failed, that movq thankfully provided in https://git.mills.io/yarnsocial/twtxt.dev/pulls/28#issuecomment-20801 for the draft of the twt hash v2 extension. The first error was easy to see in the diff. The hashes were way too long. You’ve already guessed it, I had cut the hash from the twelfth character towards the end instead of taking the first twelve characters: hash[12:] instead of hash[:12].

After fixing this rookie mistake, the tests still all failed. Hmmm. Did I still cut the wrong twelve characters? :-? I even checked the Go reference implementation in the document itself. But it read basically the same as mine. Strange, what the heck is going on here?

Turns out that my vim replacements to transform the Python code into Go code butchered all the URLs. ;-) The order of operations matters. I first replaced the equals with colons for the subtest struct fields and then wanted to transform the RFC 3339 timestamp strings to time.Date(…) calls. So, I replaced the colons in the time with commas and spaces. Hence, my URLs then also all read https, //example.com/twtxt.txt.

But that was it. All test green. \o/

No, I was using an empty hash URL when the feed didn’t specify a url metadata. Now I’m correctly falling back to the feed URL.

Hmmm, looks like my twt hash algorithm implementation calculates incorrect values. Might be the tilde in the URL that throws something off. :-? At least yarnd and jenny agree on a different hash.

Just typing twts directly into my twtxt file.

Details:

• Opening my twtxt file remotely using vim scp://user@remote:port//path/to/twtxt.txt
  
• Inserting the date, time and tab part of the twt with :.!echo "$(date -Is)\t"
  
• In case I need to add a new line I just Ctrl+Shift+u, type in the 2028 and hit Enter
  
• In order to replay, you just steal a twt hash from your favorite Yarn instance.
  

It looks tedious, but it’s fun to know I can twt no matter where I am, as long as can ssh in.

@lyse@lyse.isobeef.org I think will be bad if handled incorrectly.

The client must reference both properly or it would miss posts, including both this way is a bit pointless if you can’t use the hash or url separately.

Being a highly likely a breaking change anyway I think @zvava@twtxt.net proposal looks much better.

@lyse@lyse.isobeef.org i would like to ditch hash addressing but as was pointed out it would be a pain in the ass to get clients currently working off of hashv1 to suddenly switch to location-based addressing instead of just hashv2 with the option to eventually phase it out — unless we can rally together all active client developers to decide on a location-based addressing specification (i still think my original suggestion of #<https://example.com/tw.txt#yyyy-mm-ddThh:mm:ssZ> is foolproof)

@zvava@twtxt.net My clients trusts the first url field it finds. If there is none, it uses the URL that I’m using for fetching the feed.

No validation, no logging.

In practice, I’ve not seen issues with people messing with this field. (What I do see, of course, is broken threads when people do legitimate edits that change the hash.)

I don’t see a way how anyone can impersonate anybody else this way. 🤔 Sure, you could use my URL in your url field, but then what? You will still show up as zvava in my client or, if you also change your nick field, as movq (zvava).

@zvava@twtxt.net Yes, the specification defines the first url to be used for hashing. No matter if it points to a different feed or whatever. Just unsubscribe from malicious feeds and you’re done.

Since the first url is used for hashing, it must never change. Otherwise, it will break threading, as you already noticed. If your feed moves and you wanna keep the old messages in the same new feed, you still have to point to the old url location and keep that forever. But you can add more urls. As I said several times in the past, in hindsight, using the first url was a big mistake. It would have been much better, if the last encountered url were used for hashing onwards. This way, feed moves would be relatively straightforward. However, that ship has sailed. Luckily, feeds typically don’t relocate.

@alexonit@twtxt.alessandrocutolo.it prologic has me sold on the idea of hashv2 being served alongside a text fragment, eg. (#abcdefghijkl https://example.com/tw.txt#:~:text=2025-10-01T10:28:00Z), because it can be simply hacked in to clients currently on hashv1 and provides an off-ramp to location-based addressing (though i still think the format should be changed to smth like #<abc... http://example.com/...> so it’s cleaner once we finally drop hashes)

is the first url metadata field unequivocally treated as the canon feed url when calculating hashes, or are they ignored if they’re not at least proper urls? do you just tolerate it if they’re impersonating someone else’s feed, or pointing to something that isn’t even a feed at all?

and if the first url metadata field changes, should it be logged with a time so we can still calculate hashes for old posts? or should it never be updated? (in the case of a pod, where the end user has no choice in how such events are treated) or do we redirect all the old hashes to the new ones (probably this, since it would be helpful for edits too)

@movq@www.uninformativ.de You were seeing that mayn hash collisions for you to notice this? 😱

The twtiverse appears to have shrunk. Among the 61 feeds that I follow, I don’t see any hash collisions anymore. 🤔

@prologic@twtxt.net I think nobody will stop you if you replace the current hashing with SHA-256 if you call it improvement™ 😉