@david@daiwei.me It’s the right thread, yeah, and not a jenny thing per se. I used the Vim username completion and didn’t pay attention. 😅
@zyak@twtxt.z85b.xyz it forks and creates a new sub thread, obviously 🤣
@zyak@twtxt.z85b.xyz For my client right now if a fork shows up in the same thread its actually indented showing a different hash. So it actually shows slightly different if its a fork. But I guess if the hash is caculated differently or something it will be a fork but not show the orginal message above. This is the only message I saw the fork come up with the orginal message above.
I know yarn shows the forks correctly.
@zyak@twtxt.z85b.xyz For my client right now if a fork shows up in the same thread its actually indented showing a different hash. So it actually shows slightly different if its a fork. But I guess if the hash is caculated differently or something it will be a fork but not show the orginal message above. This is the only message I saw the fork come up with the orginal message above.
@zyak@twtxt.z85b.xyz In my new client it actually shows up as a fork but with the other threads above. The other forked messages show up without the orginal message above in its own thread.
@Sumomo@sumomo.neocities.org What client are you using btw? 🤔 Does it support threads, and other v2 specs? 🤔
If I say companies should at least consider the 3 line CC license before scraping my sites, I’m seen as the unreasonable one.
But when I use an alternative forontend, to read feeds on their sites, without having to make yet another free account, now the same companies and their users scream about some unspecified part of their license being violated, threaten legal action and expect me to care about it.

GitHub thread: https://github.com/zedeus/nitter/issues/1442#issuecomment-5413651441
Real tired of doing these, but here’s another Android developers vs Google update, this time there’s both good and bad news.
The good:
-Users will be able to enable “sideloading” for all current and future devices, attached to their Google account, rather than having to undergo the tedious 24 hour wait including process, on each device.
-Rather than these changes to “sideloading” and “advanced workflows” being implemented at random different dates, in different countries, we’ll all get them come 2027.
The bad:
As GrapheneOS developers recently mentioned “Google replaced pushing Git tags for certain source code with obtaining source code via Google Drive after making a request through Google Forms. It’s completely ridiculous and they’ve gradually become very slow at handling requests. They’re in clear violation of the GPLv2 now.”
whole thread: https://grapheneos.social/@GrapheneOS/117057099753905023
@arg@twtpub.com You actually can, but we highly discourage it and I haven’t really built “Edit” / “Delete” functionality in the Twtxt App that I know you’re using 😅 Twtxt being purely decentralised, meaning that there are absolutely zero decentralised, with the exception of the twtpub.com service you’re using to reduce as much friction as possible for newcomers to try things, makes supporting threads a bit of a controversial topic 😆 – In the end we are sticking with the Hash v2 extension, making threads use content addressing, so even if you did delete/edit a Twt, you have to be carefuly it hasn’t already been replied to in the ecosystem 🤣
but yes, however you cannot currently add it or delete post via the app as I haven’t really built that feature at the moment you technically can do it, but you do run into some challenges with breaking threads if you’ve already published something and then go back and edit it so we generally advise not to do that too much if you can help it
da hell? What’s the root of this thread? 🧵
Posting the review and plan here for posterity as it is related to this thread: https://canvas.mills.io/a/6QVGjzRW
The PR(s) as-is will likely not go ahead I’m afraid. More work to be done, but this is basically all about the “Recovery” story and how to anchor and notion of an “account” without well umm an account 🤣
sue expand ed on the main thread
@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.)
Does yarnd still support the old “threading”? Let’s see.
@movq@www.uninformativ.de ha ha in this case I think I’m OK with a broken thread ha ha
@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
+00:00 vs Z should be treated as equivalent UTC 🤦♂️ I'll take a look at the timestamp parsing in Yarnd 🧐
@lyse@lyse.isobeef.org True. Although I _think) this isn’t a problem and this thread is m00t 😅
Good morning. I’m seeing so many broken threads. You’re still investigating this, right?
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 😅
@movq@www.uninformativ.de this one:
2026-07-11T17:28:31Z (#fcyeeyd3ii2o) No yet. Let’s keep it rolling a little bit longer. I am reply to “[..] I don’t see any broken threads here. 🤔“. I can’t tag followings while on mobile. <-- THIS BROKE
Was a reply to:
2026-07-11T16:39:22+00:00 (#iqqsqst5vokf) @<david https://daiwei.me/twtxt.txt> Well, I don’t see any broken threads here. 🤔
@david@daiwei.me Well, I don’t see any broken threads here. 🤔
@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://txt.sour.is/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? 😅)]
@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. 👍
@david@daiwei.me (This thread is broken again on my end. Another bug or fix not released yet? 😅)
As an example, this is a thread @GabesArcade@gabesarcade.com’s Arcade@gabesarcade.com and @david@daiwei.me carried all on twtxt.app, no issues: https://twtxt.net/conv/r4uf52ggwseh
@movq@www.uninformativ.de I figure there is a bug somewhere, but where?

@kiwu@twtxt.net Hanging on by a thread is plenty good enough for many spiders, so it should be sufficient for you, too!!1!
Hmmm the Twtxt App isn’t grouping threads correctly 🧐
Adding support for forking, forked conversations and navigating back to the root of a thread for the Twtxt App 🤞
lleeypvkzbw2? That Twt was never ingested by twtxt.net (and likely the search engine) so umm hmmm threading breaks 🤣
It’s no big deal of course, we are fully aware of the couple of rare(ish) edge cases with the threading model.
@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 🤣
@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 😅
@arne@uplegger.eu if you see this reply threaded nicely then yes you did! 😅
How truly wonderful! I went out tonight and the first thing I noticed was the temperature drop. It felt actually quite pleasing. What a welcome surprise, I didn’t expect that at all. It was warmer in the forst than between the fields. The tiniest breeze helped to cool off the surroundings I think. Right now, the temperature shows 23°C. It’s supposed to reach 18°C at 5 in the morning before it rapidly shoots through the sky again.
When I left the house I even saw the very end of a nice sunset. A bat was around, too. The several thousand fireflies delivered a fantastic show. It’s such a pity that I cannot show this to you. :-(
There were many frogs or toads around. Luckily, the light tan gravel road made for a good constrast to the darker hopping amphibians. So, I spotted them just in time. No animals were harmed.
The moon was out and lit up the scenery. I was perfectly chasing my own shadow for several hundred meters on a forest road. I had the moon right in my back. That moon light shadow felt magical. <3
It must have set a new record on picking up spider webs along the way. The threads around arms and legs always feel quite yucky. People were blasting music somewhere in town. You could here that noise in the entire forest. I found that rather annoying. All street lamps are operational again, so I got already blinded right at the entrance to the town. But other than that, this was a very nice evening stroll. Totally recommended. Already looking forward to tomorrow. :-)
Ask HN: Are you still using your Vision Pro?
Almost two years ago there was a thread on this (https://news.ycombinator.com/item?id=40872102). I’m curious now that more time has passed what people think?
Comments URL: https://news.ycombinator.com/item?id=48465702
Points: 14
# Comments: 5 ⌘ Read more
Please don’t spam people looking for employment. It’s just cruel
Earlier I posted in a “Who wants to be hired?” thread, looking for a place where I could apply my experience in hospitality, food tech and automation.
A couple hours later I received an email:
“Hi Ilia,
I saw your comment on the June Who’s Hiring thread. I build production-ready TypeScript and Python systems that integrate LLMs into real workflows, with particular focus on RAG, agent orchestration, and clear blah-blah-blah”
Come on.
I am a forced immigra … ⌘ Read more
Nice work! Threading + mentions is where it gets fun 😅 Ping me if anything in the spec is unclear 👌
@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 came across that in some of these threads, too. I should probably give OpenRsync a shot.
@movq@www.uninformativ.de I’m kind of flag you bring thi sup, because you simply can’t. You wouldn’t even be able to in an atypical neural network either (which is what ehse things are anyway). The problem here really isn’t the so-called “AI” (I wish we’d stop calling it AI), but the flawed usage(s) thereof. I believe I even stated earlier in this thread that sometimes it may not do what you expect, it’s “probabilistic” not “deterministic” – those pushing for greater use need to understand this, those not happy with the “push”, should educate the ignorant here (especailly managers pushing for weak, insecure and bad uses).
@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.
@rdlmda@rdlmda.me You also minimally need to be calculate message hases at some point, if you want to form threads that is (copying existing ones is easy) 😅
Searching the web a bit brings up lots of threads where people hate WebP. The problem being that browsers support WebP but other programs tend to be problematic … ? 🤔
Need to fix:
- threads
-media and links
I think i may have fixed threading too but can’t easily test now as i’ve left for my
holiday and don’t really use Mastodon 😂
@therealprologic@bridge.twtxt.net Sweet! Mentions are fixed! 👌 Now just have to fix threading!
@therealprologic@bridge.twtxt.net Okay so the mention translation is. busted and umm the threading is busted. But other than that, so far so good 😊
FTR, I see one (two) issues with PyQt6, sadly:
- The PyQt6 docs appear to be mostly auto-generated from the C++ docs. And they contain many errors or broken examples (due to the auto-conversion). I found this relatively unpleasent to work with.
- (Until Python finally gets rid of the Global Interpreter Lock properly, it’s not really suited for GUI programs anyway – in my opinion. You can’t offload anything to a second thread, because the whole program is still single-threaded. This would have made my fractal rendering program impossible, for example.)
@therealprologic@bridge.twtxt.net It works! 🤣 Now I’m quite sure we haven’t got threads working yet 🤔
tilde.club feeds have no # nick and is messing with yarnd's behavior 😅
@prologic@twtxt.net And none of them use Yarn-style threading. I don’t think they’re aware of us, they’re probably using plain twtxt. Other than one hit by @threatcat@tilde.club a few days ago, I’ve seen no traffic from them. 🤔
GTK2 about to be removed from the official Arch repos: https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/2BDHYLEFSYQBDTMUOZT5J6AFTA5M3FO6/
It’ll probably all be dropped to the AUR, so I can build this myself, because I still have some stuff that depends on it (and will never receive further updates).
Python 3.14.0 released
Version\
3.14.0 of the Python language has been released. There are a lot of
changes this time around, including official support for free threading, template string literals, and much more; see
the announcement for details. ⌘ Read more
Hello again everyone! A little update on my twtxt client.
I think it’s finally shaping a bit better now, but… ☝️
As I’m trying to put all the parts together, I decided to build multiple parallel UIs, to ensure I don’t accidentally create a structure that is more rigid than planned.
I already decided on a UI that I would want to use for myself, it would be inspired by moshidon, misskey and some other “social feeds” mock-ups I found on dribbble.
I also plan on building a raw HTML version (for anyone wanting to do a full DIY client).
I would love to get any suggestions of what you would like to see (and possibly use) as a client, by sharing a link, app/website name or even a sketch made by you on paper.
I think I’ll pick a third and maybe a fourth design to build together with the two already mentioned.
For reference, the screens I think of providing are (some might be optional or conditionally/manually hidable):
- Global / personal timeline screen
- Profile screen (with timeline)
- Thread screen
- Notifications screen or popup (both valid)
- DM list & chat screens (still planning, might come later)
- Settings screen (it’ll probably be a hard coded form, but better mention it)
- Publish / edit post screen or popup (still analysing some use cases, as some “engines” might not have direct publishing support)
I also plan on adding two optional metadata fields:
display_name: To show a human readable alternative for a nick, it fallback tonickif not defined
banner: Using the same format asavatarbut the image expected is wider, inspired by other socials around
I also plan on supporting any metadata provided, including a dynamically parsable regex rule format for those extra fields, this should allow anyone to build new clients that don’t limit themselves to just the social aspect of twtxt, hoping to see unique ways of using twtxt! 🤞
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?
@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).
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?
@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 Well we have to really use the same spec or threading doesn’t really work in a truly decentralized manner 😉
@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).
@alexonit@twtxt.alessandrocutolo.it My problem is I don’t see a world where we don’t employ some form of cryptography to use as keys for threads in databases and other such things honestly. I’m not going to use url#timestamp as keys.
Each origin feed numbers new threads
(tno:N). Replies carry both (tno:N) and (ofeed:<origin-url>). Thread identity = (ofeed, tno).
@prologic@twtxt.net That’s a completely flat threading model (you can’t reply to replies). Is that intentional?
Each origin feed numbers new threads
(tno:N). Replies carry both (tno:N) and (ofeed:<origin-url>). Thread identity = (ofeed, tno).
This is possibly the only other threading model I can come up with for Twtxt that I think I can get behind.
Each origin feed numbers new threads
(tno:N). Replies carry both (tno:N) and (ofeed:<origin-url>). Thread identity = (ofeed, tno).
Example:
Alice starts thread href=”https://txt.sour.is/search?q=%2342:”>#42:**
2025-09-25T12:00:00Z (tno:42) Launching storage design review.
Bob replies:
2025-09-25T12:05:00Z (tno:42) (ofeed:https://alice.example/twtxt.txt
) I think compaction stalls under load.
Carol replies to Bob:
2025-09-25T12:08:00Z (tno:42) (ofeed:https://alice.example/twtxt.txt
) Token bucket sounds good.
TNO Threading (draft):
Each origin feed numbers new threads (tno:N). Replies carry both (tno:N) and (ofeed:<origin-url>). Thread identity = (ofeed, tno).
- Roots:
(tno:N)(implicitofeed=self).
- Replies:
(tno:N) (ofeed:<url>).
- Clients: increment
tnolocally for new threads, copy tags on reply.
- Subjects optional, not required.
…
I was trying to say (badly):
That’s kind of my position on this. If we are going to make significant changes in the threading model, let’s keep content based addressing, but also improve the user experience. Answering your question, yes I think we can do some combination of both.