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

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) (implicit ofeed=self).
  
• Replies: (tno:N) (ofeed:<url>).
  
• Clients: increment tno locally for new threads, copy tags on reply.
  
• Subjects optional, not required.
  

…

@lyse@lyse.isobeef.org @prologic@twtxt.net Can’t we find a middle ground and support both?

The thread is defined by two parts:

1. The hash
   
2. The subject
   

The client/pod generate the hash and index it in it’s database/cache, then it simply query the subject of other posts to find the related posts, right?

In my own client current implementation (using hashes), the only calculation is in the hash generation, the rest is a verbatim copy of the subject (minus the # character), if this is the common implemented approach then adding the location based one is somewhat simple.

function setPostIndex(post) {
    // Current hash approach
    const hash = createHash(post.url, post.timestamp, post.content);

    // New location approach
    const location = post.url + '#' + post.timestamp;

    // Unchanged (probably)
    const subject = post.subject;

    // Index them all
    addToIndex(hash, post);
    addToIndex(location, post);
    addToIndex(subject, post);
}

// Both should work if the index contains both versions
getThreadBySubject('#abcdef') => [post1, post2, post3]; // Hash
getThreadBySubject('https://example.com#2025-01-01T12:00:00') => [post1, post2, post3]; // Location

As I said before, the mention is already location based @<example https://example.com/twtxt.txt>, so I think we should keep that in consideration.

Of course this will lead to a bit of fragmentation (without merging the two) but I think this can make everyone happy.

Otherwise, the only other solution I can think of is a different approach where the value doesn’t matter, allowing to use anything as a reference (hash, location, git commit) for greater flexibility and freedom of implementation (this probably need the use of a fixed “header” for each post, but it can be seen as a separate extension).

@prologic@twtxt.net I know we won’t ever convince each other of the other’s favorite addressing scheme. :-D But I wanna address (haha) your concerns:

1. I don’t see any difference between the two schemes regarding link rot and migration. If the URL changes, both approaches are equally terrible as the feed URL is part of the hashed value and reference of some sort in the location-based scheme. It doesn’t matter.

2. The same is true for duplication and forks. Even today, the “cannonical URL” has to be chosen to build the hash. That’s exactly the same with location-based addressing. Why would a mirror only duplicate stuff with location- but not content-based addressing? I really fail to see that. Also, who is using mirrors or relays anyway? I don’t know of any such software to be honest.

3. If there is a spam feed, I just unfollow it. Done. Not a concern for me at all. Not the slightest bit. And the byte verification is THE source of all broken threads when the conversation start is edited. Yes, this can be viewed as a feature, but how many times was it actually a feature and not more behaving as an anti-feature in terms of user experience?

4. I don’t get your argument. If the feed in question is offline, one can simply look in local caches and see if there is a message at that particular time, just like looking up a hash. Where’s the difference? Except that the lookup key is longer or compound or whatever depending on the cache format.

5. Even a new hashing algorithm requires work on clients etc. It’s not that you get some backwards-compatibility for free. It just cannot be backwards-compatible in my opinion, no matter which approach we take. That’s why I believe some magic time for the switch causes the least amount of trouble. You leave the old world untouched and working.

If these are general concerns, I’m completely with you. But I don’t think that they only apply to location-based addressing. That’s how I interpreted your message. I could be wrong. Happy to read your explanations. :-)

@prologic@twtxt.net I can see the issues mentioned, but I think some can be fixed.

1. The current hash relies on a url field too, by specification, it will use the first # url = <URL> in the feed’s metadata if present, that too can be different from the fetching source, if that field changes it would break the existing hashes too, a better solution would be to use a non-URL key like # feed_id = <UNIQUE_RANDOM_STRING> with the url as fallback.

2. We can prevent duplications if the reference uses that same url field too or the client “collapse” any reference of all the urls defined in the metadata.

3. I agree that hashing based on content is good, but we still use the URL as part of the hashing, which is just a field in the feed, easily replicable by a bot, also noting that edits can also break the hash, for this issue an alternative solution (E.g. a private key not included in the feed) should be considered.

4. For offline reading the source would be downloaded already, the fetching of non followed feeds would fill the gap in the same way mentions does, maybe I’m missing some context on this one.

5. To prevent collisions there was a discussion on extending the hash (forgot if that was already fixed or not), but without a fallback that would break existing clients too, we should think of a parallel format that maintains current implementations unchanged, we are already backward compatible with the original that don’t use threads at all, a mention style format for that could be even more user-friendly for those clients.

We should also keep in mind that the current mention format is already location based (@<example https://example.com/twtxt.txt>) so I’m not that worried about threads working the same way.

Hope to see some other thought about this matter. 🤓

Here is just a small list of things™ that I’m aware will break, some quite badly, others in minor ways:

1. Link rot & migrations: domain changes, path reshuffles, CDN/mirror use, or moving from txt → jsonfeed will orphan replies unless every reader implements perfect 301/410 history, which they won’t.
   
2. Duplication & forks: mirrors/relays produce multiple valid locations for the same post; readers see several “parents” and split the thread.
   
3. Verification & spam-resistance: content addressing lets you dedupe and verify you’re pointing at exactly the post you meant (hash matches bytes). Location anchors can be replayed or spoofed more easily unless you add signing and canonicalization.
   
4. Offline/cached reading: without the original URL being reachable, readers can’t resolve anchors; with hashes they can match against local caches/archives.
   
5. Ecosystem churn: all existing clients, archives, and tools that assume content-derived IDs need migrations, mapping layers, and fallback logic. Expect long-lived threads to fracture across implementations.

While working on the Discoverability for my twtxt client (it runs client-side) I found out that Chrome doesn’t allow to set a custom user agent. 🙃

I thought it was a general thing for browsers, but it that was actually allowed in a newer specification, yet it’s still not implemented in Chrome, it does work in Firefox though.

@thecanine@twtxt.net With a progressive web app (PWA) you can have a native like experience without having to trouble yourself with building a second project that act as a client.

You can even “wrap” it into a packaged installation and publish it on stores, theres even projects to streamline it https://www.pwabuilder.com/.

@zvava@twtxt.net @lyse@lyse.isobeef.org I also think a location based reference might be better.

A thread is a single post of a single feed as a root, but the hash has the drawback of not referencing the source, in a distributed network like twtxt it might leave some people out of the whole conversation.

I suggest a simpler format, something like: (#<TIMESTAMP URL>)

This solves three issues:

• Easier referencing: no need to generate a hash, just copy the timestamp and url, it’s also simpler to implement in a client without the rish of collisions when putting things together
  
• Fetchable source: you can find the source within the reference and construct the thread from there
  
• Allow editing: If a post is modified the hash becomes invalid since it depends on [ timestamp, url, content ]

Hello everyone! 👋

After a long while away, I’m back on twtxt with this new feed.

Some of you might remember me as justamoment@twtxt.net, that was a test account I made for trying things out, but I ended up keeping it more than planned.

I also tried other social platforms in search of a place that felt right for me.

In the end twtxt was the one that ticked all of my boxes:

• Slow social: it act more like a feed reader and I really appreciate that there’s no flood of content that I can’t keep up with.
  
• No server needed: I absolutely love to have total control over my content, I tend to avoid having moving parts that might break, plus you can put your feed under version control and it’s all backed up.
  
• Ownership: I can put my feed anywhere I want and nobody can decide if I can access it or not.
  
• For hackers: a single .txt file allows me to join a community, how cool is that!
  

This is why I decided to build my own twtxt client, one that allows you to decide how the feed is presented on your “instance”.

It’s still in the making but I’ll try to share a bit of it once I defined how things should work.

Coincidentally, I discovered that @itsericwoodward@itsericwoodward.com and @zvava@twtxt.net were also building a twtxt client, seems like twtxt is set to grow!

@zvava@twtxt.net Good question. This is the spec, I think:

https://twtxt.dev/exts/metadata.html#nick

It doesn’t say much. 🤔

In the wild, I’ve only seen “traditional” nick names, i.e. ASCII 0x21 thru 0x7E.

My client removes anything but r'[a-zA-Z0-9]' from nick names.

@zvava@twtxt.net There would be only one hash for a message. Some to be defined magic date selects which hash to use. If the message creation timestamp is before this epoch, hash it with v1, otherwise hammer it through v2. Eventually, support for v1 could be dropped as nobody interacts with the old stuff anymore. But I’d keep it around in my client, because why not.

If users choose a client which supports the extensions, they don’t have to mess around with v1 and v2 hashing, just like today.

As for the school of thought, personally, I’d prefer something else, too. I’m in camp location-based addressing, or whatever it is called. There more I think about it, a complete redesign of twtxt and its extensions would be necessary in my opinion. Retrofitting has its limits. Of course, this is much more work, though.

@zvava@twtxt.net And yes yarnd does have a well documented API and two clients (CLI and unmaintained Flutter App)

@bender@twtxt.net @thecanine@twtxt.net well now this has me thinking abt the feasibility of making an android twtxt app for pods, the actual apis of pods would have to be standardized (or a fucked up version of how activitypub does it, where the “mastodon api” is the defacto client api (does yarn even have an api reference?)) or the client is just simply..a client..but editing feeds via PUT, PATCH, DELETE etc. is standardized!…? (not to mention i dont even know where to begin making an android app lmao)

@bender@twtxt.net @thecanine@twtxt.net well now this has me thinking abt the feasibility of making an android twtxt app for pods, the actual apis of pods would have to be standardized (or the fucked up way that activitypub does it, where the “mastodon api” is the defacto client api (does yarn even have an api reference?)) or the client is just simply..a client..but editing feeds via PUT, PATCH, DELETE etc. is standardized!…? (not to mention i dont even know where to begin making an android app lmao)

Wanting to add, this isn’t a twtxt client. It is Yarnd on steroids! 😂

@kat@yarn.girlonthemoon.xyz I reckon the original <details> need to have the open attribute set in order to expand it, so I cannot just define some custom CSS rules to do that in my browser.

But in regards to twtxt, my client won’t hide anything in that realm anyway. :-) It’s just more noise.

i know yarn has a CLI client in yarnc but ngl i wish there was a TUI client. that’d be really fun

@zvava@twtxt.net Hooray for more twtxt clients 🥳

I finally have my new (top-secret) twtxt client in a working state. Next comes the deployment, which I hope to finish tonight. Release date: TBD. Stay tuned!

I finally have my new (top-secret) twtxt client in a working state. Next comes the deployment, which I hope to finish tonight. Release date: TBD. Stay tuned!

@thecanine@twtxt.net I hate it when businesses do this. As well as being annoying and unreliable, Microsoft software is known to have a hell of a lot of security vulnerabilities, and the AI features increase the attack surface. One can use a client like Thunderbird for the email, but Teams doesn’t really have an alternative. Awful stuff.

@prologic@twtxt.net @movq@www.uninformativ.de My metadata only has my HTTPS URL. I didn’t consider having multiple. I was talking about my config.yaml. Jenny sounds like a good client, so I might give that a try.

@dce@hashnix.club Ah, oh, well then. 🥴

My client supports that, if you set multiple url = fields in your feed’s metadata (the top-most one must be the “main” URL, that one is used for hashing).

But yeah, multi-protocol feeds can be problematic and some have considered it a mistake to support them. 🤔

It might just be my client, but it seems that I cannot track multiple URLs at once. As such, all three of my twtxt URLs will work for following, but mentions will only reach me at my HTTPS URL (https://hashnix.club/~dce/twtxt.txt). If there is a client that can cope with twtxt mirrors, I would love to know about it.

@dce@hashnix.club Twet is a far better command line client. Yea 👌

This would have been neater, but evidently my client foesn’t support multiline posts.

Apparently twtxt wasn’t the right client to use. twet seems to be alright, though.

@eric@itsericwoodward.com Name change is no worries! 😉 Interesting/funnily enough my client yarnd seems to have picked it up automatically which is nice (I’ve historically always had a few bugs to iron out there 🤣)

@kat@yarn.girlonthemoon.xyz yeah it’s pretty terrible these days. Most recent trouble I had was something as simple as installing and setting up the Tailscale client. On literally all my other devices (Linux and Android) that was a cinch, but on Windows…. ohh boy, I had to mess around with reg edits and all sorts of crap and eventually bludgeoned it into working, but it was a bloody pain.

In 1996, they came up with the X11 “SECURITY” extension:

https://www.reddit.com/r/linux/comments/4w548u/what_is_up_with_the_x11_security_extension/

This is what could have (eventually) solved the security issues that we’re currently seeing with X11. Those issues are cited as one of the reasons for switching to Wayland.

That extension never took off. The person on reddit wonders why – I think it’s simple: Containers and sandboxes weren’t a thing in 1996. It hardly mattered if X11 was “insecure”. If you could run an X11 client, you probably already had access to the machine and could just do all kinds of other nasty things.

Today, sandboxing is a thing. Today, this matters.

I’ve heard so many times that “X11 is beyond fixable, it’s hopeless.” I don’t believe that. I believe that these problems are solveable with X11 and some devs have said “yeah, we could have kept working on it”. It’s that people don’t want to do it:

Why not extend the X server?

Because for the first time we have a realistic chance of not having to do that.

https://wayland.freedesktop.org/faq.html

I’m not in a position to judge the devs. Maybe the X.Org code really is so bad that you want to run away, screaming in horror. I don’t know.

But all this was a choice. I don’t buy the argument that we never would have gotten rid of things like core fonts.

All the toolkits and programs had to be ported to Wayland. A huge, still unfinished effort. If that was an acceptable thing to do, then it would have been acceptable to make an “X12” that keeps all the good things about X11, remains compatible where feasible, eliminates the problems, and requires some clients to be adjusted. (You could have still made “X11X12” like “XWayland” for actual legacy programs.)

Here’s an example of X11/Xlib being old and archaic.

X11 knows the data type “cardinal”. For example, the window property _NET_WM_ICON (which holds image data for icons) is an array of “cardinal”. I am already not really familiar with that word and I’m assuming that it comes from mathematics:

https://en.wikipedia.org/wiki/Cardinal_number

(It could also be a bird, but probably not: https://en.wikipedia.org/wiki/Cardinalidae)

We would probably call this an “integer” today.

EWMH says that icons are arrays of cardinals and that they’re 32-bit numbers:

https://specifications.freedesktop.org/wm-spec/latest-single/#id-1.6.13

So it’s something like 0x11223344 with 0x11 being the alpha channel, 0x22 is red, and so on.

You would assume that, when you retrieve such an array from the X11 server, you’d get an array of uint32_t, right?

Nope.

Xlib is so old, they use char for 8-bit stuff, short int for 16-bit, and long int for 32-bit:

https://x.org/releases/current/doc/libX11/libX11/libX11.html#Obtaining_and_Changing_Window_Properties

That is congruent with the general C data types, so it does make sense:

https://en.wikipedia.org/wiki/C_data_types

Now the funny thing is, on modern x86_64, the type long int is actually 64 bits wide.

The result is that every pixel in a Pixmap, for example, is twice as large in memory as it would need to be. Just because Xlib uses long int, because uint32_t didn’t exist, yet.

And this is something that I wouldn’t know how to fix without breaking clients.

OpenBSD has the wonderful pledge() and unveil() syscalls:

https://www.youtube.com/watch?v=bXO6nelFt-E

Not only are they super useful (the program itself can drop privileges – like, it can initialize itself, read some files, whatever, and then tell the kernel that it will never do anything like that again; if it does, e.g. by being exploited through a bug, it gets killed by the kernel), but they are also extremely easy to use.

Imagine a server program with a connected socket in file descriptor 0. Before reading any data from the client, the program can do this:

unveil("/var/www/whatever", "r");
unveil(NULL, NULL);
pledge("stdio rpath", NULL);

Done. It’s now limited to reading files from that directory, communicating with the existing socket, stuff like that. But it cannot ever read any other files or exec() into something else.

I can’t wait for the day when we have something like this on Linux. There have been some attempts, but it’s not that easy. And it’s certainly not mainstream, yet.

I need to have a closer look at Linux’s Landlock soon (“soon”), but this is considerably more complicated than pledge()/unveil():

https://landlock.io/

@movq@www.uninformativ.de Me too 😅 – Speaking of which i know you’ve lost a bit of “mojo” or “energy” (so have i of late), rest assured, I want to keep the status quo here with what we’ve built, keep it simple and change very little. What we’ve built has worked very well for 5+ years and we have at least 3 very strong clients (maybe 4 or 5?).

next up: authentication center / for both work & personal use.
for the work project, the customers (of my client) are unhappy with the account login flow and I need a fast & easy SSO for them.

for personal use: just a gateway to lock all the apps and provide access to friends.

i slowly realize the power of 1% everyday on what i am doing.

#<2025-05-10T19:34:00+00:00 https://andros.dev/texudus.txt> Nice:) And is this implemented in your client as well? I’ve started to brainstorm on how to parse texudus in php, but I guess it could snatch some code from you?

@sorenpeter@darch.dk Unfortunately it does break all clients, because the original spec stated:

Mentions are embedded within the text in either @ or @ format

@bender@twtxt.net My point was that the suggested syntax for extending mentions to point to a specific message (@<nick url timestamp>) and having location based treading this way, might not break older clients, since they might just igonore the last value within the brackets.

@sorenpeter@darch.dk you wrote:

“This might even be backward compatible with older (pre-yarn) clients.”

Yarnd is as backwards compatible with older clients as this. I dare to say, even more so. 😅

@andros@twtxt.andros.dev Thanks for consolidating a lot of good ideas. Especially how you have deiced to just extend the mention syntax for location-based treads. This might even be backward compatible with older (pre-yarn) clients.
What about using Z for UTC +00:00- is that allowed in your specs?
Regarding url = I would suggest to only allow one and the maybe add url_old = or url_alt = !?
I’m still not a fan of a DM feature, even thou it helps that i have now been split out into a separate feed file. Instead if would suggest a contact = field for where people can put an email or other id/link for an established chat protocol like signal or matrix.

@andros@twtxt.andros.dev @eapl.me@eapl.me Still lots of bugs in my client. 🥴 I’ll try to fix it next week.

And yes, using the same timestamp twice will very likely break threads.

@movq@www.uninformativ.de ok, I have included a small modification in the documentation to allow you to reply in your own thread: https://texudus.readthedocs.io/en/latest/
You can see my reply: https://andros.dev/texudus.txt
Don’t delete anything and give me time to make my modifications to the client.

@andros@twtxt.andros.dev I set up a test feed here:

https://www.uninformativ.de/texudus.txt

I made some preliminary adjustments to my client so that it can work with the different threading model. (And I totally get the concerns, this can be quite a bit of work. Especially in a large code base like Yarn.)

I’ve just released version 1.0 of twtxt.el (the Emacs client), the stable and final version with the current extensions. I’ll let the community maintain it, if there are interested in using it. I will also be open to fix small bugs.
I don’t know if this twt is a goodbye or a see you later. Maybe I will never come back, or maybe I will post a new twt this afternoon. But it’s always important to be grateful. Thanks to @prologic@twtxt.net @movq@www.uninformativ.de @eapl.me@eapl.me @bender@twtxt.net @aelaraji@aelaraji.com @arne@uplegger.eu @david@collantes.us @lyse@lyse.isobeef.org @doesnm@doesnm.p.psf.lt @xuu@txt.sour.is @sorenpeter@darch.dk for everything you have taught me. I’ve learned a lot about #twtxt, HTTP and working in community. It has been a fantastic adventure!
What will become of me? I have created a twtxt fork called Texudus (https://texudus.readthedocs.io/). I want to continue learning on my own without the legacy limitations or technologies that implement twtxt. It’s not a replacement for any technology, it’s just my own little lab. I have also made a fork of my own client and will be focusing on it for a while. I don’t expect anyone to use it, but feedback is always welcome.
Best regards to everyone.
#twtxt #emacs #twtxt-el #texudus

@movq@www.uninformativ.de I think we can make this work 👌 As long as it’s just a client hint.

just for the record I didn’t say I was leaving the twtxt ‘community’ (did I?) but than I have other priorities to focus on in the following months. Please don’t be condescending, is not cool.

Development of Timeline (PHP client) has been stale for some reasons, a few of them in my side, so I think it won’t be updated to the new thread model, at least pretty soon.
So is not that I’ll stop using twtxt, just the client I use won’t be compatible with the new model in July.

@movq@www.uninformativ.de If we’re focusing on solving the “missing roots” problems. I would start to think about “client recommendations”. The first recommendation would be:

1. Replying to a Twt that has no initial Subject must itself have a Subject of the form (hash; url).
   

This way it’s a hint to fetching clients that follow B, but not A (in the case of no mentions) that the Subject/Root might (very likely) is in the feed url.

@lyse@lyse.isobeef.org likewise I don’t have the energy for a fundamental shift in any of our specifications that would inevitably cause a lot of toil and try and change in our clients implementations and unforeseen problems that we haven’t really fully understood:

@movq@www.uninformativ.de Agreed, finding the right motivation can be tricky. You sometimes have to torture yourself in order to later then realize, yeah, that was actually totally worth it. It’s often hard.

I think if you find a project or goal in general that these kids want to achieve, that is the best and maybe only choice with a good chance of positive outcome. I don’t know, like building a price scraper, a weather station or whatever. Yeah, these are already too advanced if they never programmed, but you get the idea. If they have something they want to build for themselves for their private life, that can be a great motivator I’ve experienced. Or you could assign ‘em the task to build their own twtxt client if they don’t have any own suitable ideas. :-)

Showing them that you do a lot of your daily work in the shell can maybe also help to get them interested in text-based boring stuff. Or at least break the ice. Lead by example. The more I think about it, the more I believe this to be very important. That’s how I still learn and improve from my favorite workmate today in general. Which I’m very thankful of.

@lyse@lyse.isobeef.org Hahahaha 🤣 I mean it’s “okay” every now and then, but what’s the point of having good clients and tools if we don’t use ‘em 🤣