What a giant shitshow. Things just have to burn to the ground several times.
This sketch is well done, so you countersunk the holes to make room for the heads. Makes absolutely sense. Mille grazie! <3
I've got a digital alarm clock from the Netherlands (no idea where I got this) and it always runs an hour late. No clue. I put it on a shelf in the workshop where it causes the least amount of confusion.
@bender Off you go to the magpie hunt! We wanna see Florida pies!
I learned that I don't know hardly anything and there is heaps more to explore. Tomorrow, I will do the same in Go and see how that feels.
Message-IDs.
You used the rubber hammer to fold the metal, not to set the rivets, right? :-? I glued cork on my wooden mallet some time ago. This worked quite good for bending. But rubber might be even better as it is a tad softer. I will try this next time, I think I have one deep down in a drawer somewhere.
HEAD requests, but regular GETs with If-Modified-Since request headers if possible: https://git.mills.io/yarnsocial/yarn/src/branch/main/internal/fetcher.go#L270
With the pliers wrench again, I was able to also crush down the chopped off 3mm copper nail and form a second head. That was surprisingly easy. Now, I need to figure out how to efficiently make a head on the remaining copper nail shaft, so that I can use this again.
Both are rock solid, there's absolutely no movement at all between the two sheet metal cutoffs.
https://lyse.isobeef.org/tmp/nietenexperiment/
python3-tk and a bunch more packages with extensions.
python3 -m tkinter a try, but this module doesn't exist. I was always under the wrong impression that Tkinter is bundled with Python.
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. ;-)
> Aachen has been officially certified as "Bad Aachen", but for alphabetical reasons usually declines to use the prefix
>
> — https://en.wikipedia.org/wiki/List_of_spa_towns_in_Germany#A
That made me chuckle.
Sorry, this pun only works in German, where "Bad" means spa and is used as prefix for spa towns.
Relevant film: https://www.youtube.com/watch?v=YYNbSuMLZZg
My hardware collection also includes a few brass-like looking screws that I could repurpose into rivets. But I reckon I have to upgrade my burner first. I'm not a metal worker by any means, so I could be totally wrong, but I imagine that some heat is necessary to loosen the work-hardening effect when beating on them. I will do some experiments on Saturday and report back.
Lizard or shark or something
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.
I decided against blind rivets, because they leave ugly looking and sharp backsides, which can also interfer with the contents of the box. However, they would be an easy solution to make the corners more rigid and prevent any movement from the short sides.
Unfortunately, I can't weld or solder, so that's not an option. It would be the by far best solution. I wanna learn it one day, though.
Yes, Ken is a really great dude. He's the reason I gave this a shot in the first place. :-)
I can confirm, the
User-Agent header appears to be fixed. \o/Two other things I noticed, though:
1. There's now an
OPTIONS request for my feed coming from something that claims to be Firefox, pointing to your feed URL in the query. No clue what this is about. In any case, it's rejected with a 405 Method Not Allowed.2. Not that these few requests bother me at all, but you might wanna implement caching next with either the
If-Modified-Since or If-None-Match request headers. This way, if the feed hasn't changed, the web server can reply with a 304 Not Modified and no body at all, saving unnecessary traffic. But again, this is really not an issue for me at all. I just wanted to make sure you're aware of it, that's all. It might be even already on your agenda. Or you might decide to never do anything about it, which is also fine for me. :-)
https://lyse.isobeef.org/tmp/screenshot-2025-09-27-13-56-13.png
Yes, this was a flat piece of sheet metal. It went together like a cardboard box, just much slower and with timbers clamped down to get a straight folding line. I don't have a sheet metal brake, so I just carefully hammered the piece bit by bit. Like in this video by the Sheet Metal Dude: https://www.youtube.com/watch?v=WYgEfWEMXk0
User-Agent header. Instead of the URL, the nick is repeated.
-f bestvideo[height<=?1080]+bestaudio/best
yt-dlped https://www.youtube.com/watch?v=OZTSIYkuMlU. It's only worth for an experiment, no recommendation to watch.
(WTF, asciiworld-sat-track somehow broke, but I have not changed any of the scripts at all. O_o It doesn't find the asciiworld-sat-calc anymore. How in the world!? When I use an absolute path, the .tle is empty and I get a parsing error. Gotta debug this.)
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. :-)
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.)
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.
@<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
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.
Yellow orange clouds
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.
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.
sed -i s/… $(find …). Clearly, I found too many files. That's the signal to go to bed.
A normal person is completely lost (that's why I got involved). Visting the broken URL opens a popup dialog suggesting to deactivate script blockers. Which I had already done upfront as a matter of prudence.
Fun bonus on top: The JWT in the link has identical
iat (issued at) and exp (expiry) claims. The expiry is definitely not checked, it's well in the past.Medical software just has to be horrible. It's a law.
Sunset
English version: https://youtu.be/wi_q6IythMk
German version: https://youtu.be/2Lv1MMlFDBs
Regarding the "look at this, but I don't want to add anything at all", this never happened to me. Apparently, it seems to be a thing for others.
Privacy-concerned duck in a creek
<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.
<details> is to collapse long logs in bug analysis reports. Other than that, I find it rather annoying to expand sections manually.As for spoilers, personally, I don't care at all. Not the slightest bit. If there is something that I don't wanna read, I just stop reading. ¯\_(ツ)_/¯
But I've got the feeling that I've got an unpopular opinion on that matter. ;-)_
Hahaha, I never heard of Poopgate before. :-D Poor passengers.
I don't understand the concept of a retwt. Just quote the (relevant) parts from whereever and comment on that. Or post a link instead of a quote. Sounds simple enough. :-) That's also has the benefit that it works with every source, no matter what. Since it's called retwt, I'd imagine this to only work (well) with whatever messages the system itself offers. But I could be wrong. What would be the benefit of having a dedicated message type or structure for "hey, look at that" messages in your opinion?
Hmm, what's a content warning?
Oh, I just found https://upload.wikimedia.org/wikipedia/commons/f/f1/Pier_17_2018-03_jeh.jpg and this really does not look all that high. I thought that this would be at least 50 or 100 meters up. I was completely wrong. :-D