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

@kat@yarn.girlonthemoon.xyz Mine shows 1/1 of 14 Twts 😆 I think this is a bug 🤯

@itsericwoodward@itsericwoodward.com any news about this? I am, at the very least, curious!

@alexonit@twtxt.alessandrocutolo.it I took it down mostly because of continued abuse and spam:l. I intend to fix I and improve the drive and its sister at Summer point 🤞

@alexonit@twtxt.alessandrocutolo.it Love this 😍

@alexonit@twtxt.alessandrocutolo.it Yeah same 🤣 There’s also this @news-minimalist@feeds.twtxt.net feed that shows up the most important shit™ anyway (when/if that happens).

@alexonit@twtxt.alessandrocutolo.it Personally, I find the reversed order of URL first and then timestamp more natural to reference something. Granted, URL last would be kinda consistent with the mention format. However, the timestamp doesn’t act as a link text or display text like in a mention, so, it’s some different in my opinion. But yeah.

@bender@twtxt.net Seriously I have zero clue 🤣 I don’t read or watch any news so I have no idea 🤦‍♂️

@prologic@twtxt.net I know you were away, but were you under a rock?! 😅

@prologic@twtxt.net Yes, no doubt. There’s always something somewhere.

@lyse@lyse.isobeef.org Some stuff is actually more reliable, that’s true. It’s also waaaaaaaaaaay more expensive, though … :-)

I called it a day, yes. \o/

@movq@www.uninformativ.de But it’s so reliable and they have all the experts, they know what they’re doing! And don’t forget, it’s way cheaper! Just think of the 34 cents saved every year on paper, the business dude calculated!

Enjoy your weekend! (I hope, you just called it a day and don’t have to drive to the office or silly shenanigans like that.)

@lyse@lyse.isobeef.org Yep! Super fast and efficient! 😃

@kiwu@twtxt.net awwww! 😢

@prologic@twtxt.net welcome back! 🥳🥳🥳

@movq@www.uninformativ.de That’s transparency hardware support!

@zvava@twtxt.net In tt, I recognize umlauts in nicks, but they cannot include whitespace, @, !, #, (, ), [, ], <, >, " (but ' is okay). Whitespace also acts as a separator between nick and URL. @<Hello World http://example.com> ends up exactly like that and is not a mention.

Apologies if I’ve been spamming anyone out there in twtxt-land today.

I’ve been working on a couple of twtxt-related projects, and one of them is a reader (tentatively called twtstrm) written in JS. I used dummy data for the first few stages of development, but now I’m at the point where I need some real data, and that meant hitting up my actual following list.

Of course, it didn’t help that I had a typo in my If-Modified-Since headers, but all that has since been resolved.

Anyways, if I accidentally spammed you with requests today, I am sorry, and it shouldn’t happen anymore.

We thank you for your patience, and apologize for the inconvenience.

@bender@twtxt.net Soon soon🤣

@prologic@twtxt.net ah! Well, keeping fingers crossed for you and family on that RV, for sure! 🤞🏻

@bender@twtxt.net I wish 🤣 Nah work on-site thingy😆

@prologic@twtxt.net ah, I was wondering! Hoping you are having a good time, mate! Christening the new RV? :-)

I know it doesn’t need to be said, but “Texudus” is not twtxt. It is an attempt to create a, arguably, “better way™️”. 🤭

@zvava@twtxt.net ah, yes, that’s the only Texudus feed. It also seems it is a one way only feed.

@zvava@twtxt.net which Texodus feed? That I know of, there is only one, or am I wrong?

@zvava@twtxt.net @movq@www.uninformativ.de I’m not entirely sure about the spaces, but maybe they were omitted to simplify parsing of mentions in the form of @<nick url>. If the next token after the @<nick does not look like a URL, it’s not a mention but regular text. This is just wild guessing, though.

Looking at the regex and tests in the original twtxt reference implementation seems to confirm that theory in the sense as it relies on whitespace as the delimiter:

https://lyse.isobeef.org/tmp/screenshot-2025-09-17-21-30-25.png

Another thing about nicks is that the original twtxt reference implementation converts nicks to all lowercase:

https://lyse.isobeef.org/tmp/screenshot-2025-09-17-21-20-39.png

You probably know this already, the original twtxt file format specification can be found here: https://twtxt.readthedocs.io/en/latest/user/twtxtfile.html

As for extensions, I don’t know of anything outside of twtxt.dev that has actually been (partially) implemented. However, there is also the issue tracker of the official reference implementation. You might wanna dig through that. For example, there is an alternative suggestions of multiline messages: https://github.com/buckket/twtxt/issues/157

@arne@uplegger.eu Hm, noch nie gemacht. 🤔 Machst du das von Hand oder mit Code?

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

@kat@yarn.girlonthemoon.xyz, see this one, regarding “Anubis” (which I believe you use, right?): https://github.com/eternal-flame-AD/pow-buster

@rrraksamam@twtxt.net someone has a huge crush on Emily Blunt, eh? 🤭

@lyse@lyse.isobeef.org Omg, that is great. 😃

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

@thecanine@twtxt.net Id like that too, it just can’t come from me, because native mobile dev just isn’t my thing 😢

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

@zvava@twtxt.net We can do that 👌

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

@thecanine@twtxt.net it should work everywhere. It is a web application.

@lyse@lyse.isobeef.org I didn’t know they had a name, to be honest. When I/we last had a dot matrix printer, I just sat alone in the basement and made these. 😂

@bender@twtxt.net Sigh. So it’s just me. Again. 😂

Adding too this. The configuration example at the repository reads:

{
	"nick": "Example",
	"description": "alice's twtxt instance!",
	"host": "twtxt.example.com",
	"admin": "alice"
}

Would it make more sense changing nick to instance_name or similar? Usually nick is reserved for users, like here, quark. Right? Also, is host the same FQDN to be used while proxying traffic to the application? That is, using the above configuration, it’s Caddy configuration would be:

twtxt.example.com {
	encode
	reverse_proxy :31212
}

Is that correct?

Hmm, twtxt Yarn is misbehaving. Can’t even edit, nor delete. Oh well.

@movq@www.uninformativ.de Luckily, I had a grep -v git at the end, so my repo is still in working order. Phew. I wish find had grep-like --exclude-dir and --exclude options (or the include variants) instead of its own weird options that I never can remember and combine properly.

@movq@www.uninformativ.de Nice Jacob’s ladder. ;-) I had to look up this term, I also found Zig Zag. What do you folks call this in your languages? In German, it’s Hexentreppe (lit. Witch’s Staircase).

@zvava@twtxt.net It is just completely impossible to make v2 backwards-compatible with v1.

Well, breaking threads on edits is considered a feature by some people. I reckon the only approach to reasonably deal with that property is to carefully review messages before publishing them, thus delaying feed updates. Any typos etc., that have been discovered afterwards, are just left alone. That’s what I and some others do. I only risk editing if the feed has been published very few seconds earlier. More than 20 seconds and I just ignore it. Works alright for the most part.

@lyse@lyse.isobeef.org Yeah, I’ve corrupted a Git repo or two doing that … 🥴

@zvava@twtxt.net I was about to suggest that you post some examples. By now, we’re pretty good at debugging hashing issues, because that happens so often. 😂 But it looks like you figured it out on your own. ✌️

@lyse@lyse.isobeef.org 🙈😂

@zvava@twtxt.net that makes it even more so exciting! 😂

@prologic@twtxt.net I completely forgot about that topic … 😂🥴

@zvava@twtxt.net oh?! I shall play more “seriously” with it soon then. Yay!