@prologic@twtxt.net @movq@www.uninformativ.de Same with tt, hash v2 has to be used right from the epoch onward. (And now replying to a message with a timestamp before the epoch still results in a v1 hash.)

@prologic@twtxt.net No. After the cutoff-date, hashes are expected to be v2. End of story.

(In jenny, a twt can only ever have one thing that can be used for threading.)

@movq@www.uninformativ.de @lyse@lyse.isobeef.org Are you clients remaining compatible with Hash v1 in case older clients are still well not upgraded? 🤔

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://we.loveprivacy.club/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! 👍

@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!

Linux 7.2 Gets Rid Of The Last Optimized MD5 Implementation
The Linux kernel has dropped the last of its architecture-specific optimized MD5 hashing algorithm implementations… ⌘ Read more

EXT4 Reworks Fast Commit Handling & Faster Directory Hash Computation
The EXT4 file-system improvements were merged today for Linux 7.2 with some enticing optimizations… ⌘ Read more

@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:

Image

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.

60% of MD5 Password Hashes Are Crackable In Under an Hour
In honor of World Password Day, Kaspersky researchers revisited their study on the crackability of real-world passwords and found that 60% of MD5-hashed passwords could be cracked in under an hour with a single Nvidia RTX 5090, and 48% could be cracked in under a minute. “The bottom line is that passwords protected only by fast hashing algorithms such as MD5 are … ⌘ Read more

53 Nations Gather To Plan a Fossil Fuel Phaseout
Ancient Slashdot reader hwstar shares a report from The Conversation: For the first time ever, more than 50 nations will gather next week in Colombia to hash out how to wind down and end their dependence on coal, oil and gas. The history-making conference was planned before the Iran war. But this year’s energy crisis has greatly raised the stakes. […] Around 80% of the trap … ⌘ Read more

Linux 7.1 Crypto Code Rework Enables More Optimizations By Default
Linux libcrypto cryptography subsystem changes for the v7.1 kernel are enabling more optimizations by default and in turn helping to achieve better crypto/hashing performance on this next kernel version… ⌘ Read more

@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.

And here we go! Yup, hash has seven.

@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 I can calculate a hash by hand… Or I can cheat and copy the hash when previewing my own feed at https://twtxt.net ;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.

To Pressure Security Professionals, Mandiant Releases Database That Cracks Weak NTLM Passwords in 12 Hours
Ars Technica reports:

Security firm Mandiant [part of Google Cloud] has released a database that allows any administrative password protected by Microsoft’s NTLM.v1 hash algorithm to be hacked in an attempt to nudge users who continue using the deprecated function … ⌘ Read more

@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.

@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.

@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/

Linux Looks To Remove SHA1 Support For Signing Kernel Modules
Patches posted to the Linux kernel mailing list this week are seeking to remove SHA1 support for signing of kernel modules. This is part of the larger effort in the industry for moving away from SHA1 given its vulnerabilities to hash collisions and superior hashing algorithms being available… ⌘ Read more

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.

Net zero Australia LIVE updates: Hastie, Cash, Henderson speak as Liberals hash out emissions policy
Follow along as we bring you the latest live news updates from Australia and around the world. ⌘ Read more