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

@david@daiwei.me This is another dangling thread:

Trying to fetch "#kyjhiwcxeknm" from Yarn pod https://txt.sour.is ...
Trying to fetch "#kyjhiwcxeknm" from Yarn pod https://twtxt.net ...
Twt could not be found

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

Yeah to @david@daiwei.me’s point re Editing. It’s only really safe to do so if you are sure that no-one has yet fetched your feed or replied to your Twt. But even then, you have to be quick 🤣 Editing/fixing a Twt inside of an existing thread is “oaky”, as long as it also doesn’t get forked and becomes the root of a new conversation 😅

@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 Ah, the first twts were from https://raw.githubusercontent.com/Fastidious/fastidious.github.com/master/twtxt.txt, not https://daiwei.me/twtxt.txt. Fetching the GitHub feed completes the thread. 👍

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.

@bender@twtxt.net “Twt could not be found” 😢

@GabesArcade@gabesarcade.com Yes, because if you edit/delete a Twt after the ecosystem has ingested it, well there then are two versions 😅 Just be aware of edits/deletes, especially if someone has already replied to said Twt 🤣

@GabesArcade@gabesarcade.com Did you by change edit or otherwise delete the Twt you replied to (2nd last in your feed) with the reply/thread id lleeypvkzbw2? That Twt was never ingested by twtxt.net (and likely the search engine) so umm hmmm threading breaks 🤣

@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’s Arcade@gabesarcade.com You will want to either build a client or use one of the ones listed here – Either way you choose! 👌 I just noticed as well in this Twt I’m replying to (threading is a thing™) that you @-mentioned@twtxt.net @bender@twtxt.net incorrectly 😅

Hmm… https://twtxt.net/twt/rb4c47bj2b2k.

@prologic@twtxt.net this was supposed to be a reply to this, not sure how it ended up all there, by itself, sad and lonely. 😅

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

It’s that time again, I’ve just rotated my #twtxt feed!

Find last quarter’s twts at the feed, or see them on the web.

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

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.

yey! I remembered how to prune my Jenny/Neomutt Twtxt feed! (I only keep 6 months worth of Twts) Now, I need to figure out how to set up a macro for that.

@thecanine@twtxt.net are you referring to the “WE FUCKING WON!” twtxt?

@bender@twtxt.net Only missing roots would trigger that kind of sync IIRC. And that only works if another peering pod has the root twt. What you’re remembering, possibly, is an attempt to do what you were thinking of… But I tried it, turned out to be too expensive of an operation to do auotmatically.

@movq@www.uninformativ.de that some lovely development from the initial one. Curious to know where this will lead!

@klaxzy@klaxzy.net nothing like a blank twt eh? 😅

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

@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

Hmmmm the AoC site is not mobile friendly 😢 Can someone post the puzzles as Twts? 🤣

@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. 😏😅)

@shinyoukai@neko.laidback.moe What do you mean by that? 🧐 Clients don’t care about the order of twts in a feed. For display clients usually sort by timestamp.

Oh my god! 🤣 It works! 🥳 My first Twt into the Fediverse (stil some improvements to be made of course), but still 😳 Wow! 🤩

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.

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/

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.

@threatcat@tilde.club unwritten etiquette (by me, and for me, but one can hope, right?).

• Proper grammar (in any language).
  
• Correct capitalisation, and punctuation.
  
• Subject extension support.
  

Anything else doesn’t matter. ☺️

@bender@twtxt.net You are totally correct! The thing is: The Caveman within was thinking how minimal can one go before things start to get too uncomfortable? And if cavemen weren’t supposed to be too self-conscious about their spelling, I could have just ssh remote echo "$(date -Is)\tTwt Twt Mother-Lover! 🤣🤣" >> /path/to/twtxt.txt and called it a day.

@aelaraji@aelaraji.com yeah, it looks tedious because it is. LOL. I can twt no matter where I am because a) with Yarn is as easy as opening a web browser, and b) with jenny is as easy at SSHing to my VPS. But, the keyword is fun. That’s what matters!

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.

Holly! I thing I might have figured out a way to twt like a true caveman 🤣
The sad thing tho is this caveman will have to cheat a bit in order to replay properly…
(P.S: I hope the multi-lines trick works, if not then F..rog it!)

@bender@twtxt.net The first format use the subject extension while the other is a new format that is inspired by mentions format, the first one should be compatible but I’m not sure, if it’s used verbatim by the client it would work, but if we consider the new proposal for it to have an optional part it wont work on clients without changes.

I finally solved the loading issue in my WIP reader, TwtStrm (and apologies again to anyone that got spammed while I was diagnosing the issue).

After another round of coding this weekend, I’m happy to report that it now renders all the twts (with markdown parsing), complete with localstorage and server-based file caching.

I meant, “jlj”. He used to be at https://twt.nfld.uk/, long gone now too. I wonder…

@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™ 😅

plus, if hashv2 was implemented in combination with text fragments the way you proposed that would solve both scripting and human readability woes!!

…though, the presence of the text fragments then makes reversing the replied-to twt (and therefore its hash) trivial, which could allow clients to tolerate the omission of the hash — and while it would be ‘non-standard’ this would be the best of both worlds; potential to tolerate (or pave a glacial path toward? :o) human writable twts whilst keeping a unique id for twts that is universal across all pods

plus, if hashv2 was implemented in combination with text fragments the way you proposed that would solve both scripting and human readability woes!!

…though, the presence of the text fragments then makes reversing the replied-to twt (and therefore its hash) trivial, which could allow clients to tolerate the omission of the hash — and while it would be ‘non-standard’ this would be the best of both worlds; potential to tolerate (or pave a glacial path toward? :o) human writable replies whilst keeping a unique id for twts that is universal across all pods

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