@prologic@twtxt.net ah, I was wondering! Hoping you are having a good time, mate! Christening the new RV? :-)
Working on a project that does Augmented Reality and computer vision object detection and QR code and image recognition inside a Web application. Pretty neat what can be done today with a few thousand lines of JavaScript.
Iâm out of town folks and away until tomorrow (have been all week)
https://andros.dev/texudus.txt
, its url doesn't correspond to the feed either
I know it doesnât need to be said, but âTexudusâ is not twtxt. It is an attempt to create a, arguably, âbetter wayâąïžâ. đ€
https://andros.dev/texudus.txt
, its url doesn't correspond to the feed either
@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
/^([-_\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)
@zvava@twtxt.net which Texodus feed? That I know of, there is only one, or am I wrong?
nick
s? i remember reading somewhere whitespace should not be allowed, but i don't see it in the spec on twtxt.dev â in fact, are there any other resources on twtxt extensions outside of twtxt.dev?
@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
Sometimes, I wonder how my desktop looks to other people. Normal sighted people, I mean. For me, everything is much smaller and always slightly blurry (almost antialiased) because of my eyesight.
Maybe it does look horribly pixelated and super ugly to other people, and thatâs why everyone prefers smoothed fonts and UIs and all that ⊠? đ
nick
s? i remember reading somewhere whitespace should not be allowed, but i don't see it in the spec on twtxt.dev â in fact, are there any other resources on twtxt extensions outside of twtxt.dev?
@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. đ„Ž
@arne@uplegger.eu Hm, noch nie gemacht. đ€ Machst du das von Hand oder mit Code?
nick
s? i remember reading somewhere whitespace should not be allowed, but i don't see it in the spec on twtxt.dev â in fact, are there any other resources on twtxt extensions outside of twtxt.dev?
@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.
is there consensus on what characters should(nât) be allowed in nick
s? i remember reading somewhere whitespace should not be allowed, but i donât see it in the spec on twtxt.dev â in fact, are there any other resources on twtxt extensions outside of twtxt.dev?
For what I can gather, kind of a waste of time, not a good solution. I might be missing bits, or may havenât grasp the entire âstoryâ.
@kat@yarn.girlonthemoon.xyz, see this one, regarding âAnubisâ (which I believe you use, right?): https://github.com/eternal-flame-AD/pow-buster
@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.
Warum ist es nur so kniffelig ein Sudoku-RĂ€tsel zu erstellen?
Ich meine nicht, das Erstellen eines komplett ausgefĂŒllten Sets, sondern das Leeren der Felder so, dass ein einigermaĂen herausforderndes Sudoku mit nur einer Lösungsmöglichkeit entsteht. đ€
@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 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! đ
@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. đ
[2025/09/11 12:56:01.816] â please set config.host
when trying to run "bbycll". How to bypass that tiny hurdle?
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?
[2025/09/11 12:56:01.816] â please set config.host
when trying to run "bbycll". How to bypass that tiny hurdle?
Hmm, twtxt Yarn is misbehaving. Canât even edit, nor delete. Oh well.
[2025/09/11 12:56:01.816] â please set config.host
when trying to run "bbycll". How to bypass that tiny hurdle?
On the configuration topic, the example at the repo reads like this:
â
Hmm, not experiencing that. Using Zen (Firefox), under Linux, with uBlock Origin.
@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.
Next level poop: Canât log in to reddit anymore with adblock enabled. It says invalid usename or password.
mobile navigation bar :3
sed -i s/⊠$(find âŠ)
. Clearly, I found too many files. That's the signal to go to bed.
@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. âïž
wait why are so many of my post hashes not generating correctly ;w;
edit: i read the spec wrong :3 only +/-00:00 is stripped, not the entire timezone offset >.<
@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! đ
I corrupted my SQLite test database with sed -i s/⊠$(find âŠ)
. Clearly, I found too many files. Thatâs the signal to go to bed.
Canât resist.