Hey @itsericwoodward@itsericwoodward.com, I just wanna let you know that twtstrm/0.4.0 sends a broken User-Agent header. Instead of the URL, the nick is repeated.

@prologic@twtxt.net Hm, I don’t know. Over here, we have parties that we would call “left” or “right”, one of them even calls themselves “The Left”. No idea about your political landscape, but it still makes sense for us. 🤔 For me, at least.

@bender@twtxt.net 🤣

@zvava@twtxt.net Hahaha, I love it! This illustrates the contradiction very well.

@prologic@twtxt.net how dare you! (read it with Greta emphasis, and accent)

@movq@www.uninformativ.de See here’s the thing… I just don’t fucking gt this whole “left” vs. “right” shit™ anymore. None of it makes any sense whatsoever. When my wife tries to explain it to me it’s completely the opposite to what you just said just now 😱 – So from here on, I’m just going to keep things simple” nutters” and “normal” 🤣

@bender@twtxt.net I feel you buddy 🤗 At one point we have quite a vibrant community. Phil was great, jlj too and Adi was well just Ado 😅

@prologic@twtxt.net Germany was listed as “opposing” on https://fightchatcontrol.eu/ for a while, now it’s back to “undecided”. According to netzpolitik.org, it’s still debated. Also according to that page, there could be an important vote on the EU level on October 13/14.

The green party and the (far) left are opposing this (at least in Germany). Sadly, Germany is leaning more right with every year … As for young people: The (far) left is the strongest party among young people, with the (far) right being the second strongest one. (https://www.tagesschau.de/wahl/archiv/2025-02-23-BT-DE/umfrage-alter.shtml) Is there cause for hope? I don’t know.

@prologic@twtxt.net you doing this reminded me of mkws, and Adi. Good times, we have seeing so many people come and go. It is kind of sad, when I think about “jjl”, and Phil, and the many others…

I am feeling “mushy” today. Ugh, ageing sucks.

@bender@twtxt.net Yup! Fixing that now! 👌 Also the Tags page and the size of the trags is intentional, as more posts are tagged with the same tag, those will result in larger size rendered tags in a kind of “tag cloud” – At this this is the intention.

@prologic@twtxt.net yup, that’s what I meant. The lack of it on the URL is fine, but on the post itself it is always a good idea. Time frames matter.

Test.

@bender@twtxt.net Ahh yes I see what you mean. no indicate of when the post was made right? That should be ideally displayed on the page somewhere? Would you expect it in the url as well, because not having /posts/yyyy/mm/dd/.... was actually intentional. But yeah I should figure out where to put some additional metadata on the page.

@bender@twtxt.net hopeful of the same 🤞

@prologic@twtxt.net I can’t upload a screenshot (tried, but Yarnd simple “ate” my reply). See https://zsblog.mills.io/posts/hello-zs-blog.html. Is has no date/time on it.

@movq@www.uninformativ.de LOL. I wish and hope they keep proposing it until the proposers die of natural causes, and then it vanishes. Hopeful thinking, I know…

@movq@www.uninformativ.de Kill it with fire 🔥

@prologic@twtxt.net need to work on the CSS. For example, the tags are too big, the code blocks (and the inline ones) are too small, the single posts have no date (intended?), and so on. It’s an alpha start!

@prologic@twtxt.net They have not rolled it out (yet), they are “just” discussing it (for the n-th time).

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

@alexonit@twtxt.alessandrocutolo.it Yes well I’m pretty big on self-hosting. I’ve even tried to start a small business/company around it (but that’s another story for another day!) – Meanwhile I would encourage you to have a look at the work we’ve done in Salty.im 👌

@alexonit@twtxt.alessandrocutolo.it Well we have to really use the same spec or threading doesn’t really work in a truly decentralized manner 😉

That’s what I’m using right now, while my own client is still in the making.

A simple bash script to write a post in a mktemp file then clean it with regex.
I don’t even bother to hash the replies, I just open https://twtxt.net and copy the hash by hand since I’m checking the new posts from there anyway (temporarily, as I might end up DoS-ing everyone’s feed in my client right now).

@prologic@twtxt.net Don’t worry about it!

I also getting angry thinking how this Chat Control crap will escalate to.

I’m already thinking of countermeasures and self-hosted alternatives, while searching lists of affected apps and services to replace/drop in the worst scenario (and probably devices).

@zvava@twtxt.net Amazing! I would love to see all the specs described this way. 🤩

@prologic@twtxt.net Well, personally I would, as I already do for user feeds in my client.

That’s why part of my proposal was to allow custom strings and be free from a specific format that need periodical upgrades, but it’s not much of a problem in the end.

I’ll adapt to what we can get out of this.

@zvava@twtxt.net I axtually latest did and I wasn’t the only one 🤣

@zvava@twtxt.net That’s what I’m leaning towards yeah🤞

@prologic@twtxt.net to clarify the i meant the ability to parse feeds using unix command line utilities, as a prinicpal of twtxtv1’s design. im not sure how feasible it is to build a simple feed reader out of common scripting utilities when hashing is in play, and;

i concede, it does make a lot of sense to fix up the hashing spec rather than completely supplant it at this point, just thinking about what the rewrite would be like is dreadful in and of itself x.x

@prologic@twtxt.net to clarify: i meant the ability to parse feeds using unix command line utilities, as a principal of twtxtv1’s design. im not sure how feasible it is to build a simple feed reader out of common scripting utilities when hashing is in play, and;

i concede, it does make a lot of sense to fix up the hashing spec rather than completely supplant it at this point, just thinking about what the rewrite would be like is dreadful in and of itself x.x

@zvava@twtxt.net Haha 🤣

And I need to make something absolutely clear as well here. Twtxt was completely and utterly dead back in {Aug 2020](https://yarn.social/about.html) when I came across the spec and its simplicity and realised the lost opportunity. Since then we’ve continued to grow a small but thriving community. The extensions we’ve built over time have stood and lasted the test of time for the past ~5 years. We need not break things too badly, because what we have today and was designed years ago actually works quite well™ (despite some flaws).

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

@prologic@twtxt.net the simplest thing to do is to completely forgo hashing anything because we are communicating using plain text files right now :3

@prologic@twtxt.net the simplest thing to do is to completely forgo hashing anything because we are communicating using plain text files right now :3 while i agree hashes are incredibly helpful in the backend im not sure it has a place outside of it, it basically eliminates two core design principals of twtxt (human readability and integrating well with unix command line utilities) and makes new clients more difficult to build than it should be

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

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

@bender@twtxt.net Yes I did about a week or so ago. It took me a lot of effort to get the content even rendered in the first place. LOL I had to basically export my blog as HTML (can you believe that?!) – The Hugo export just didn’t work at all 🤣

@prologic@twtxt.net While it might work if you want to keep both, I think the point was to be able to use one or the other, if we still have to generate the hash anyway it might be pointless to use this format.

@prologic@twtxt.net I admit that I was a bit confused about the meaning of the message, at least I understood it was a “yes” from the last sentence. 😅

@movq@www.uninformativ.de Yes it’s kind of terrible 😞 – Let’s not do this 🤣

@bender@twtxt.net Really? 🤔

@bender@twtxt.net Well, you guessed correctly! 😁

Would be nice to have a fixed fee for that, a car is a car anywhere in the world…

@prologic@twtxt.net That’s a completely flat threading model (you can’t reply to replies). Is that intentional?

@prologic@twtxt.net that’s not too bad! 👏🏻👏🏻👏🏻

This is possibly the only other threading model I can come up with for Twtxt that I think I can get behind.

Example:

Alice starts thread href=”https://yarn.girlonthemoon.xyz/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.