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

Net zero Australia LIVE updates: Liberals in party room meeting set to hash out emissions policy
Follow along as we bring you the latest live news updates from Australia and around the world. ⌘ Read more

Net zero Australia LIVE updates: Liberals in party room meeting set to hash out emissions policy
Follow along as we bring you the latest live news updates from Australia and around the world. ⌘ Read more

Net zero Australia LIVE updates: Liberals in party room meeting set to hash out emissions policy; Meeting set to last hours; MPs to speak in alphabetical order
Follow along as we bring you the latest live news updates from Australia and around the world. ⌘ Read more

Net zero Australia LIVE updates: Liberals in party room meeting set to hash out net zero emissions policy; McCormack says Coalition should stick together regardless of decision
Follow along as we bring you the latest live news updates from Australia and around the world. ⌘ Read more

Net zero Australia LIVE updates: Liberals in party room meeting set to hash out net zero emissions policy; McCormack says Coalition should stick together regardless of decision
Follow along as we bring you the latest live news updates from Australia and around the world. ⌘ Read more

Net zero Australia LIVE updates: Liberals in party room meeting set to hash out net zero emissions policy; McCormack says Coalition should stick together regardless of decision
Follow along as we bring you the latest live news updates from Australia and around the world. ⌘ Read more

When Your Hash Becomes a String: Hunting a Ruby Million-to-One Memory Bug
Comments ⌘ Read more

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.

Modern perfect hashing
Comments ⌘ Read more

Consistent Hashing
Comments ⌘ Read more

Hash Me If You Can — How I Beat a 2-Second Hashing Challenge on RingZer0Team ⌘ Read more

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

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

Exactly, @zvava@twtxt.net, I agree. (Although, in my client at least, I wouldn’t use hashes anywhere.)

@alexonit@twtxt.alessandrocutolo.it Yeah I think we’re overstating the UNIX principles a bit here 🤣 I get what you’re trying to say though @zvava@twtxt.net 😅 If I could go back in time and do it all over again, I would have gotten the Hash length correct and I would have used SHA-256 instead. But someone way smarter than me designed the Twt Hash spec, we adopted it and well here we are today, it works™ 😅

@zvava@twtxt.net Going to have to hard disagree here I’m sorry. a) no-one reads the raw/plain twtxt.txt files, the only time you do is to debug something, or have a stick beak at the comments which most clients will strip out and ignore and b) I’m sorry you’ve completely lost me! I’m old enough to pre-date before Linux became popular, so I’m not sure what UNIX principles you think are being broken or violated by having a Twt Subject (Subject) whose contents is a cryptographic content-addressable hash of the “thing”™ you’re replying to and forming a chain of other replies (a thread).

I’m sorry, but the simplest thing to do is to make the smallest number of changes to the Spec as possible and all agree on a “Magic Date” for which our clients use the modified function(s).

@bender@twtxt.net Well honestly, this is just it. My strong position on this is quite simple:

Do the simplest thing that could work.

It’s one of the age old UNIX philosphies.

Therefore, the simplest thing™ to do here is to just increase the hash length, mark a magic™ date/time as @lyse@lyse.isobeef.org has indicated and call it a day. We’ll then be fine for a few hundred years, at which point there’ll be no-one left alive to give a shit™ anyway 🤣

@prologic@twtxt.net considering other alternatives we have seeing (of which I have lost track already), yes. Why don’t you guys (client makers) take a step at a time and, for now, increase the hash length to deal with the collisions. Then location-based addressing can be added… or not, you know. 😅