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

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

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

@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! 👏🏻👏🏻👏🏻

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.

@itsericwoodward@itsericwoodward.com I’m glad to hear it 🤣

@alexonit@twtxt.alessandrocutolo.it Holy fuck! 🤣 I just realized how bad my typing was in my reply before 🤣 🤦‍♂️ So sorry about that haha 😆 I blame the stupid iPhone on-screen keyboard ⌨️

@alexonit@twtxt.alessandrocutolo.it Maybe I misunderstood, but you have to keep the timezone offsets in mind. Simple alphabetical sorting of the timestamp strings does not yield a truly chronological order. It might be close enough for you, though.

@alexonit@twtxt.alessandrocutolo.it that sounds pretty much like Italy! LOL. We pay $48 on renewal in Florida, US, but that fee isn’t Federal, so other states may pay more, or less.

@prologic@twtxt.net That is really great to hear!

If there are opposing opinions we either build a bridge or provide a new parallel road.

Also, I wouldn’t call my opinion a “stance”, I just wish for a better twtxt thanks to everyone’s effort.

The last thing we need to do is decide a proper format for the location-based version.

My proposal is to keep the “Subject extension” unchanged and include the reference to the mention like this:

// Current hash format: starts with a '#'
(#hash) here's text
(#hash) @<nick url> here's text

// New location format: valid URL-like + '#' + TIMESTAMP (verbatim format of feed source)
(url#timestamp) here's text
(url#timestamp) @<nick url> here's text

I think the timestamp should be referenced verbatim to prevent broken references with multiple variations (especially with the many timezones out there) which would also make it even easier to implement for everyone.

I’m sure we can get @zvava@twtxt.net, @lyse@lyse.isobeef.org and everyone else to help on this one.

I personally think we should also consider allowing a generic format to build on custom references, this would allow for creating threads using any custom source (manual, computed or external generated), maybe using a new “Topic extension”, here’s some examples.

// New format for custom references: starts with a '!' maybe?
(!custom) here's text
(!custom) @<nick url> here's text

// A possible "Topic" parse as a thread root:
[!custom] start here
[custom] simpler format

This one is just an idea of mine, but I feel it can unleash new ways of using twtxt.

@itsericwoodward@itsericwoodward.com I used the dates as is for indexing them as string, the ISO format allows for free auto sorting.

@bender@twtxt.net What?! In my country you have to pay 100€ every 10 years of which about 75% are just taxes…

@movq@www.uninformativ.de I’ve got this magic spell in my config: -f bestvideo[height<=?1080]+bestaudio/best

@itsericwoodward@itsericwoodward.com pretty cool! Started following you, not to miss any progress. Thanks for the exhaustive reply!

@lyse@lyse.isobeef.org that’s pretty cool! The first video I see on YouTube of that kind. Thanks!

@lyse@lyse.isobeef.org Hm, I couldn’t trick yt-dlp into downloading the correct format. Works in the browser, though. 😅

@bender@twtxt.net @movq@www.uninformativ.de I had automatically yt-dlped https://www.youtube.com/watch?v=OZTSIYkuMlU

. It’s only worth for an experiment, no recommendation to watch.

@melyanna@tilde.club Exit! Exit!!1! https://movq.de/v/c51aa76926/exit-exit-exit.jpg