@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

A few threads were broken because of editing. Other than that, are you seeing major issues? I hate broken threads, trust me, so if there is an issue still causing them I want it fixed!

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

Editing isn’t good. I would recommend you forget editing exist, as it breaks threads and twtxts ended up not making sense. Consider everything typed written in stone. Send a follow up twtxt amending if at all needed.

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

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.

@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://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? 😅)]

@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? 😅)

@GabesArcade@raw.githubusercontent.com there seems to be a bug on twtxt.app that is breaking threads. @prologic@twtxt.net is out, so a fix will sure come end of week, beginning of next.

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!

@bender@twtxt.net nothing good unfortunately!! been hangin on by a thread, how have u been??

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 🤞

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 🤣

Actually, I think I know what’s happening. The last twt in the thread is more recent than the original twt, so it appears out of order.

Actually, I think I know what’s happening. The last twt in the thread is more recent than the original twt, so it appears out of order.

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

Nice work! Threading + mentions is where it gets fun 😅 Ping me if anything in the spec is unclear 👌

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

https://itsericwoodward.com/images/dda03946.png

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

1. 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.
   
2. (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 🤔

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

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 to nick if not defined
  
• banner: Using the same format as avatar but 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! 🤞

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

@zvava@twtxt.net That was my greatest concern with how it is currently handled, I’m afraid to break threads even by fixing a typo.

Handling it via the pod might work but I think it’s not the best approach, external feeds and clients don’t usually use a pod api but their own implementation, so any workaround won’t work there.

That’s why my proposals addressed those issues:

• the idea of using a “key” instead of the url (with the url as a fallback), the key could even be a public key so it can be used verifieable in crypto functions
  
• using the timestamp to prevent content changes to break threads (plus being simpler to implement)
  
• using an explicit thread reference with an alternative subject format (like [#THREAD_ID] Hello world and replies with (#REPLY_ID) Ahoy) so the content can change without affecting the thread reference, and anyone can use their own schemes freely

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

@prologic@twtxt.net I think a counter in the client is not a good choice given the decentralized nature of twtxt, especially if someone use multiple cients together.

After thinking about it for a while I got to two solutions:

Proposal 1: Thread syntax (using subject)

Each post have an implicit and an optional explicit root reference:

• Implicit (no action needed, all data required are already there)

  • URL + timestamp
    

• Explicit (subject required)

  • Identity (client generated)
    
  • External reference
    
  • Random value
    

We then add include a “root” subject in each post for generating explicit theads:

1. `[ROOT_ID] (REPLY_ID)`: simpler with no need of prefixes
2. `(root:ROOT_ID) (reply:REPLY_ID)`: more complex but could allow expansions
	- `(rt:ROOT_ID) (re:REPLY_ID)`: same but with a compact version
	- `($ROOT_ID) (>REPLY_ID)`: same but with a single characters

Each post can have both references, like the current hash approach the reference can be treated as a simple string and don’t have a real meaning.

Using a custom reference this way allows a client to decide how to generate them:

• Identity: can be a content hash or signature or anything else, without enforcing how it is generated we can upgrade the algorithm/length freely
  
• External references: can be provided from another system (Eg. 7e073bd345, yarnsocial/yarn latest commit)
  
• Random value: like a UUID (Eg. 9a0c34ed-d11e-447e-9257-0a0f57ef6e07)
  

Proposal 2: Threaded mentions (featuring zvava)

Inspired by @zvava@twtxt.net’s solution it could be simplified into: #<nick url#timestamp> or #<url#timestamp>

It can be shown like a mentions or hidden like a subject.

If we’re using thinking of using a counter in the client, I think there’s no point in avoiding the timestamp anymore.