@prologic@twtxt.net Whoop whoop 🥳
@lyse@lyse.isobeef.org Xfce is nice, but it’s also mostly GTK. I don’t really know the answer yet. For now, I’ll just avoid anything that uses GTK4.
For my own programs, I might have a closer look at Tkinter. I was complaining recently that I couldn’t find a good file manager, so it might be an interesting excercise to write one in Python+Tkinter. 🤔 (Or maybe that’s too much work, I don’t know yet.)
@movq@www.uninformativ.de I was never a fan of GTK, because coming from KDE, it didn’t offer remotely as much of customizability. What are you switching to, Xfce?
@zvava@twtxt.net feeds are fetched at least every 5m (if they’ve changed)
@zvava@twtxt.net yarnd fetches the feeds roughly every ten minutes:
grep twtxt.net www/logs/twtxt.log | cut -d ' ' -f1 | tail -n 20
2025-10-04T07:00:45+02:00
2025-10-04T07:10:26+02:00
2025-10-04T07:22:43+02:00
2025-10-04T07:30:45+02:00
2025-10-04T07:40:48+02:00
2025-10-04T07:52:59+02:00
2025-10-04T08:00:07+02:00
2025-10-04T08:13:33+02:00
2025-10-04T08:23:13+02:00
2025-10-04T08:31:22+02:00
2025-10-04T08:41:29+02:00
2025-10-04T08:53:25+02:00
2025-10-04T09:03:31+02:00
2025-10-04T09:11:42+02:00
2025-10-04T09:23:11+02:00
2025-10-04T09:29:49+02:00
2025-10-04T09:36:17+02:00
2025-10-04T09:46:33+02:00
2025-10-04T09:58:40+02:00
2025-10-04T10:06:54+02:00
I suspect that the timing was just right. Or wrong, depending on how you’re looking at it. ;-)
@itsericwoodward@itsericwoodward.com @bender@twtxt.net this is vaguely concerning…does yarn refresh feeds every minute or two? or is there some special “notify twtxt.net to refresh my feed” that i don’t know about
@bender@twtxt.net Wow, you’re good.
It was an edit, within a minute or two of posting. I didn’t think anyone would notice.
That’s what I call on it. 😀
@prologic@twtxt.net woohoo! Take that, micro.crap! :-D
@movq@www.uninformativ.de exactly! 🤣
@bender@twtxt.net Who?
@bender@twtxt.net I don’t think so, but I might give it a shot when the “official” drivers no longer work at all.
@itsericwoodward@itsericwoodward.com hmmm, what was this, an edit, a deletion?

@movq@www.uninformativ.de can’t you use generic drivers? I did that for an enterprise copier/printer/scanner we used to have at work, and it worked just fine!
@zvava@twtxt.net agreed. I think display_name will be redundant, and add to the “busy” factor. That is, the opposite of simplicity.
@lyse@lyse.isobeef.org lol 😅
@alexonit@twtxt.alessandrocutolo.it i dont think display_name is worthwhile, since nick is functionally a display name
@lyse@lyse.isobeef.org Bahahahaha 🤣😆
Sieht ganz so aus, als hätte die gute @kat@yarn.girlonthemoon.xyz ihre Büchse mit in den Kurort Bad Gateway genommen.
Sorry, this pun only works in German, where “Bad” means spa and is used as prefix for spa towns.
@movq@www.uninformativ.de It completely escapes me, too. I will never understand it, but people are just wired very differently.
Relevant film: https://www.youtube.com/watch?v=YYNbSuMLZZg
@movq@www.uninformativ.de Yeah, the lighting needs to be right in order to make them really pop like this. I got lucky today. :-)
@lyse@lyse.isobeef.org Awwww! I’ve never noticed their tail feathers being so green. 🤯
@lyse@lyse.isobeef.org Yeah, it’s probably not black and white. (I have no idea why you would connect a bloody light bulb to your WiFi …) But I do get the impression that there are way more “neo-luddites” that 20 years ago. 😅
Waste paper, like an opened envelope, suits a shopping list perfectly fine.
Indeed, I’m drowning in this stuff and I throw it away anyway, so I might just use it.
You’ve got a nice handwriting, I like it.
Thanks. 😅 (It used to be horrible. Gosh, the teachers scolding me in school … Bah. 😂)
@movq@www.uninformativ.de Not sure, if this observation is correct. I know so many techies who also use every latest shit and automate their homes which is scary as hell to me.
@alexonit@twtxt.alessandrocutolo.it I just checked my local hardware store next town and 4mm brass rod is the closest I find.
@lyse@lyse.isobeef.org I think you should be able to find some even in general stores in the hardware section.
@movq@www.uninformativ.de So damn true.
I have a friend that might lock himself out of his home if there’s a power outage while I keep removing apps and devices from my daily lives instead.
I recently switched from all the todo apps I used to sticky notes on my monitors and a pocket notebook for sketching and quick notes.
@thecanine@twtxt.net So cool!
It reminds me of the monsters in Heart of Darkness on PSX (just replayed the other day).
@movq@www.uninformativ.de No doubt, some things are just so much better the low-tech way. Waste paper, like an opened envelope, suits a shopping list perfectly fine. You’ve got a nice handwriting, I like it.
@thecanine@twtxt.net Oh no, the poor crocodile is struck by lightning!
@bender@twtxt.net The first format use the subject extension while the other is a new format that is inspired by mentions format, the first one should be compatible but I’m not sure, if it’s used verbatim by the client it would work, but if we consider the new proposal for it to have an optional part it wont work on clients without changes.
@movq@www.uninformativ.de While using the a frament is pretty nice, I think we can have a twtxt only format if the formatting seems to be a problem.
@lyse@lyse.isobeef.org I think will be bad if handled incorrectly.
The client must reference both properly or it would miss posts, including both this way is a bit pointless if you can’t use the hash or url separately.
Being a highly likely a breaking change anyway I think @zvava@twtxt.net proposal looks much better.
@lyse@lyse.isobeef.org i would like to ditch hash addressing but as was pointed out it would be a pain in the ass to get clients currently working off of hashv1 to suddenly switch to location-based addressing instead of just hashv2 with the option to eventually phase it out — unless we can rally together all active client developers to decide on a location-based addressing specification (i still think my original suggestion of #<https://example.com/tw.txt#yyyy-mm-ddThh:mm:ssZ> is foolproof)
@lyse@lyse.isobeef.org Finally! The end is near! Rejoice! \o/
@zvava@twtxt.net Hm, I tried with https://www.uninformativ.de/twtxt.txt#:~:text=2025-09- and my Firefox 143 didn’t like it. https://www.uninformativ.de/twtxt.txt#:~:text=2025%2D09%2D worked. 🤔
@bender@twtxt.net technically it’s still the same, but the brackets are different, and the # symbol is on the outside of the brackets, but it makes more sense with @<...> being mentions
@movq@www.uninformativ.de huh, firefox actually does seem to tolerate the dashes in the fragment. also, i did propose simply using an anchor link first, but prologic was not a fan of this :p
@thecanine@twtxt.net content warning please! I had to go home and change, if you catch my drift. LOL. Well done!
@movq@www.uninformativ.de I wish I could truly say that. :-D
url metadata field unequivocally treated as the canon feed url when calculating hashes, or are they ignored if they're not at least proper urls? do you just tolerate it if they're impersonating someone else's feed, or pointing to something that isn't even a feed at all?
(#abcdefghijkl https://example.com/tw.txt#:~:text=2025-10-01T10:28:00Z), because it can be simply hacked in to clients currently on hashv1 and provides an off-ramp to location-based addressing
I like that property (an off-ramp to location-based addressing), so I think I could live with that approach. ✅
(I’m not sure why we’re using text fragments, though. Wouldn’t that link to the first occurence of 2025-10-01T10:28:00Z? That’s not necessarily correct. And, to be proper URLs that Firefox and Chromium understand, it would also need to be written as 2025%2D10%2D01T10:28:00Z. The dash carries meaning, sadly. I think all this just creates needless complication. How about we just go with https://example.com/tw.txt#2025-10-01T10:28:00Z?)
@aelaraji@aelaraji.com, I mean to follow up here on the brief exchange we had on irc.mills.io, but I forgot. Never too late, so here it goes:
18:16 <aelaraji> quark 🙏 much appreciated but it won't be necessary, since there isn't much to miss out on in most of where I hang out, so I could just disconnect and spare everyone else the noise
18:17 *** aelaraji (aelaraji@776014f5a3edd32f1ed19658b7b85c8c655945b0feacaedd92fe60e61a3c0ae2) has quit (/ME goes "yeeeeet..!")
18:18 <quark> No noise for me.
18:18 <quark> It’s all good.
18:18 <quark> What would IRC be without on/offs?
18:19 <quark> Preeeety boring!
18:19 <quark> Ah, he was gone.
18:19 <quark> Well, I will twtxt this to him. LOL.
Thanks, @alexonit@twtxt.alessandrocutolo.it! Yeah, this classic rivet is a good, yet laborous alternative. I don’t mind the work, I just don’t have any copper at hand. I might give this some more thought, though.
url metadata field unequivocally treated as the canon feed url when calculating hashes, or are they ignored if they're not at least proper urls? do you just tolerate it if they're impersonating someone else's feed, or pointing to something that isn't even a feed at all?
@zvava@twtxt.net My clients trusts the first url field it finds. If there is none, it uses the URL that I’m using for fetching the feed.
No validation, no logging.
In practice, I’ve not seen issues with people messing with this field. (What I do see, of course, is broken threads when people do legitimate edits that change the hash.)
I don’t see a way how anyone can impersonate anybody else this way. 🤔 Sure, you could use my URL in your url field, but then what? You will still show up as zvava in my client or, if you also change your nick field, as movq (zvava).
@alexonit@twtxt.alessandrocutolo.it Hahaha, that made me laugh real good. :-D I find it always surprising what collects in a short amount of time.
(#abcdefghijkl https://example.com/tw.txt#:~:text=2025-10-01T10:28:00Z), because it can be simply hacked in to clients currently on hashv1 and provides an off-ramp to location-based addressing (though i still think the format should be changed to smth like #<abc... http://example.com/...> so it's cleaner once we finally drop hashes)
@zvava@twtxt.net Mixing both addressing schemes combines the worst of both worlds in my opinion. Please don’t do that.
url metadata field unequivocally treated as the canon feed url when calculating hashes, or are they ignored if they're not at least proper urls? do you just tolerate it if they're impersonating someone else's feed, or pointing to something that isn't even a feed at all?
@zvava@twtxt.net Yes, the specification defines the first url to be used for hashing. No matter if it points to a different feed or whatever. Just unsubscribe from malicious feeds and you’re done.
Since the first url is used for hashing, it must never change. Otherwise, it will break threading, as you already noticed. If your feed moves and you wanna keep the old messages in the same new feed, you still have to point to the old url location and keep that forever. But you can add more urls. As I said several times in the past, in hindsight, using the first url was a big mistake. It would have been much better, if the last encountered url were used for hashing onwards. This way, feed moves would be relatively straightforward. However, that ship has sailed. Luckily, feeds typically don’t relocate.
(#abcdefghijkl https://example.com/tw.txt#:~:text=2025-10-01T10:28:00Z), because it can be simply hacked in to clients currently on hashv1 and provides an off-ramp to location-based addressing (though i still think the format should be changed to smth like #<abc... http://example.com/...> so it's cleaner once we finally drop hashes)
@zvava@twtxt.net the second format (the one you think should be changed to), is it backwards compatible to what’s currently in place? I believe the first one would be.