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

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

@bender@twtxt.net https://andros.dev/texudus.txt, its url doesn’t correspond to the feed either

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

@lyse@lyse.isobeef.org @movq@www.uninformativ.de bbycll’s nickname regex is /^([-_\p{N}\p{L}])+$/iu because i don’t like how english-centric only allowing ascii letters/numbers is though this only applies to local users as of now, currently all nicknames are tolerated when parsing remote feeds and i just do mentions how yarn does (just the feed url)

in the wild, i’ve noticed a texedus feed with spaces in the nick (where its spec explicitly disallows whitespace in the nick) and feeds with other symbols in the nick too. honestly, i think we should just tolerate arbitrary nicknames for sake of user expression (while stripping or converting unreasonable characters) and just leave them out of mentions

@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

Speaking of Sudoku, I was banging my head against this for 15 minutes:

https://sudokupad.app/adventure/94-advvvvvvvven

I’m glad I eventually got it right. 🥴

(via https://dosgame.club/@Tijn/115221132694421937)

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

I’m happy to report, after the successful remix of System Of A Down with the Nooran Sisters from India in https://www.youtube.com/watch?v=mi106DZJhuQ

I stumbled across something almost equally great from Pakistan, Nusrat Fateh Ali Khan: https://www.youtube.com/watch?v=aZYG-9usGPI

It’s a banger! The girls are unmatched, though.

@zvava@twtxt.net Not much of a known fact these days, but thereused to be a Yarn phone app (https://git.mills.io/yarnsocial/app), last version released 5 or so years ago, but it still suggests, it has to be somewhat feasable, to make another one. I don’t think anyone tried since, because the web version works well on phones, but I’m still hoping, we get a more native phone experience, one day.

@lyse@lyse.isobeef.org i dont mind if the hash is not backward compatible but im not sure if this is the right way to proceed because the added complexity dealing with two hash versions isnt justified

regular end users wont care to understand how twt hashes are formed, they just want to use twtxt! so i guess i could work in protecting users from themselves by disallowing post edits on old posts or posts with replies, but i’m not fond of this either really. if they want to break a thread, they can just delete the post (though i’ve noticed yarn handling post deletes dubiously…)

on activitypub i do genuinely find myself looking through several month or even year old posts sometimes and deciding to edit/reword them a little to be slightly less confusing, this should be trivial to handle on twtxt which is an infinitely simpler specification

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

@bender@twtxt.net yeah i’ve noticed yarn being very strange with edits, deletes haven’t worked since i joined here

@quark@ferengi.one ooh, thanks for catching that! i forgot abt the caddy example when adding the config example

nick is nick bc it is parsed as a nickname just for the instance, though calling it instance_nick would probably be less confusing

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

@zvava@twtxt.net love the direction this is heading, hope this soon evolves into a basic Android app, usable with any instance.

What a crazy color temperature this yellow orange was in person! Sick lighting this evening: https://lyse.isobeef.org/abendhimmel-2025-09-15/

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

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

mobile navigation bar :3

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

im unable to figure out why bbycll is not generating posts hashes for @lyse@lyse.isobeef.org’s feed correctly (or at least different from the ones generated by yarn)

i’m pretty sure the timezone is stripped off the offset correctly (2025-09-14T12:45:00+02:00 → 2025-09-14T12:45:00Z) though messing with how the hash is generated i can’t get it to make one that matches…but all other hashes for all other feeds seem to be correct? does yarn use a different canonical url for lyse internally? is there a bug in the libraries im using? bwehhh

@lyse@lyse.isobeef.org 🙈😂

@prologic@twtxt.net im unsure how i feel about the hash v2 proposal, given it is completely backward incompatible with hash v1 it doesn’t really solve any of the problems with it. it only delays collisions, and still fragments threads on post edits

i skimmed through discussions under other the proposals — i agree humans are very bad at keeping the integrity of the web in tact, but hashes in done in this way make it impossible even for systems to rebuild threads if any post edits have occurred prior to their deployment

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

@bender@twtxt.net just a heads up im thinking of rewriting the database schema with hash v2 in mind >.<

@lyse@lyse.isobeef.org the problem is that i can not easily show both

Can’t resist.

https://movq.de/v/2a7918d719/a.jpg

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

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

@zvava@twtxt.net The first version of what is now yarnd was built over a weekend 😀

@zvava@twtxt.net Herw you go: https://git.mills.io/yarnsocial/twtxt.dev/pulls/28

@zvava@twtxt.net For the time being, just show both.

@prologic@twtxt.net i just added timeline refresh to bbycll and it is so convincing i almost replied to you from there hehe, can i get a link pretty please :o

@zvava@twtxt.net we have to amend the spec and increase the hash length. We just haven’t done so yet 😆

ok so i have found a genuine twt hash collision. what do i do.

internally, bbycll relies on a post lookup table with post hashes as keys, this is really fast but i knew i’d inevitably run into this issue (just not so soon) so now i have to either:
  1) pick the newer post over the other
  2) break from specification and not lowercase hashes
  3) secretly associate canonical urls or additional entropy with post hashes in the backend without a sizeable performance impact somehow

@prologic@twtxt.net wife is awesome 🙇‍♀️