Which actively maintained Yarn/twtxt clients are there at the moment? Client authors raise your hands! 🙋

And regarding those broken URLs: I once speculated that these bots operate on an old dataset, because I thought that my redirect rules actually were broken once and produced loops. But a) I cannot reproduce this today, and b) I cannot find anything related to that in my Git history, either. But it’s hard to tell, because I switched operating systems and webservers since then …

But the thing is that I’m seeing new URLs constructed in this pattern. So this can’t just be an old crawling dataset.

I am now wondering if those broken URLs are bot bugs as well.

They look like this (zalgo is a new project):

https://www.uninformativ.de/projects/slinp/zalgo/scksums/bevelbar/

When you request that URL, you get redirected to /git/:

$ curl -sI https://www.uninformativ.de/projects/slinp/zalgo/scksums/bevelbar/
HTTP/1.0 301 Moved Permanently
Date: Sat, 22 Nov 2025 06:13:51 GMT
Server: OpenBSD httpd
Connection: close
Content-Type: text/html
Content-Length: 510
Location: /git/

And on /git/, there are links to my repos. So if a broken client requests https://www.uninformativ.de/projects/slinp/zalgo/scksums/bevelbar/, then sees a bunch of links and simply appends them, you’ll end up with an infinite loop.

Is that what’s going on here or are my redirects actually still broken … ?

Thunderbird Pro Enters Production Testing Ahead of $9/Month Launch
Thunderbird Pro has moved its Thundermail email service into production testing as the open-source email client’s subscription bundle of additional services prepares for an Early Bird beta launch at $9 per month that will include email hosting, encrypted file sharing through Send, and scheduling via Appointment.

Internal team members are now tes … ⌘ Read more

When I have to explain to the client that we can’t use their Excel 2010 file as a database ⌘ Read more

@arne@uplegger.eu @lukas@lukasthiel.de In fact, Yarn.social’s yarnd client implementation actually uses (or did, still kinda does today) PicoCSS 🤟 It was/is a good CSS library! 👍

MLPerf Client 1.5 Introduces Experimental Linux Support
MLPerf Client as MLCommons’ machine language inferencing benchmark for client form factors / PCs now has a Linux build. MLPerf Client 1.5 was released yesterday with an experimental Linux build but for now at least is not nearly as full-featured as this AI benchmark on Windows and macOS… ⌘ Read more

The fortune-teller, the Dover Heights mansion and the alleged $70m fraud
The feng shui master predicted riches for her clients, police allege. Now, detectives investigating Sydney’s Penthouse Syndicate have swooped. ⌘ Read more

The fortune-teller, the Dover Heights mansion and the alleged $70m fraud
The feng shui master predicted riches for her clients, police allege. Now, detectives investigating Sydney’s Penthouse Syndicate have swooped. ⌘ Read more

I should work on my client again and add some new features. Like adding a new feed directly in the client and not having to go to the config first. And showing a preview of a feed before actually adding it. Also, a search would be something to add. And finally combining my User-Agent analyzer with my subscription list to spot new feeds automatically.

GTK Adds “Reduced Motion” Accessibility Option To Follow macOS, Windows & Others
In addition to GNOME’s Mutter compositor removing its X11 back-end support to focus exclusively on Wayland while keeping around XWayland client support, another notable GNOME change this week was the GTK toolkit adding a “reduced motion” accessibility option… ⌘ Read more

Automattic Inc. Claims It Owns the Word ‘Automatic’
An anonymous reader shares a report: Automattic, the company that owns WordPress.com, is asking Automatic.CSS – a company that provides a CSS framework for WordPress page builders – to change its name amid public spats between Automattic founder Matt Mullenweg and Automatic.CSS creator Kevin Geary. Automattic has two T’s as a nod to Matt.

“As you know, our client owns and … ⌘ Read more

bluetui and restterm: two beautiful TUI applications
There’s something incredibly enticing and retrofuturistic about a well-designed TUI, or text-based user interface. There’s an endless list number of these, but two crossed my path these past few days, and I found them particularly appealing. First, we’ve got bluetui, an application for managing Bluetooth connections on Linux systems with bluez installed. The second is resterm. Resterm is a terminal-first client for working with … ⌘ Read more

Perfetto: Swiss Army Knife for Linux Client Tracing
Comments ⌘ Read more

When the client is about to click on a button that isn’t implemented ⌘ Read more

Fevela.me – A newsreader-like client for the Nostr social network
I created Fevela, a fork of the great Jumble, because I wanted a Nostr social client that would give me back full control of my attention and time. So I designed an interface similar to that of old good newsreaders, which for me is perfect to encourage exploration of interesting content rather than doomscrolling. I then added some ad hoc filters that can help reduce noise and improve the signal.

Unlike traditional social media that’s designed to maximize your time on t … ⌘ Read more

When I show up at a new client after being sold as an expert by sales ⌘ Read more

When the client tells me I should’ve handled responsiveness even though it was never in scope ⌘ Read more

When the sales guy starts talking in a client meeting ⌘ Read more

Show HN: Halloy – the modern IRC client I hope will outlive me
Comments ⌘ Read more

When I know the client and tell the new guy to comment out code instead of deleting it ⌘ Read more

I keep getting this email occadionally:

Your iCloud storage is almost full

Now for various reasons, I don’t want my children to be using iCloud to store data, files, photos or any of the sort. They’re free to use iMessages, and other Apple services like the App Store, etc, but not storage.

So I’ve set about blocking iCloud Storage API(s) via AdGuard Home tonight as well as ensuring that my local network (client users) cannot bypass DNS policies and get out other sneaky ways, because some applications will just use other DNS servers, or DOH or DOT.

Client ID Metadata Document Adopted by the OAuth Working Group
The IETF OAuth Working Group has adopted the Client ID Metadata Document specification! ⌘ Read more

My open letter, to the European Commission digital markets act team:

Hello,

I am joining other developers, concerned about Googles new plan, to approve every app and effectively destroy most of the competing 3rd party stores this way. The biggest one of these alternative stores, most known for their focus on user and developer privacy, already states, this would make it impossible for them to operate: https://f-droid.org/cs/2025/09/29/google-developer-registration-decree.html
Even communities like the XDA forum, where new developers are often introduced to the world of Android development, would likely be strongly impacted, as making, publishing and installing Android apps is made less accessible.

I am not just writing on their behalf, I run a small website myself (https://thecanine.ueuo.com/), that both provides legal modifications, for some android apps - for example adding an amoled dark theme, to the most popular XMPP chat client for Android, or increasing one of Androids keyboard apps height. This all comes after Googles previous changes to the Android operating system, that prevent users from installing old apps (old to Google, can mean only a couple of months, without an update - https://developer.android.com/google/play/requirements/target-sdk and the target version gets increased every year). I rely on apps developed by a single developer, even for things like making the pixel art presented on my website and sideloading as a way to make these apps work, before developers can catch up to Google’s new requirements - if Google is allowed to slowly kill these options, us digital artists will soon lose the tools we need to create digital art.

nmail: Terminal-based email client for Linux and macOS
Comments ⌘ Read more

Germany must stand firmly against client-side scanning in Chat Control [pdf]
Article URL: https://signal.org/blog/pdfs/germany-chat-control.pdf

Comments URL: https://news.ycombinator.com/item?id=45464921

Points: 586

# Comments: 132 ⌘ Read more

Of course, all things optional is fine. Like, it will be ignored (just like banner would) for clients having no knowledge of it.

@zvava@twtxt.net

(#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?)

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

Great to see so many new clients popping up. 👌

Exactly, @zvava@twtxt.net, I agree. (Although, in my client at least, I wouldn’t use hashes anywhere.)

Put another way, what you are proposing/pushing for requires hundreds of lines of code to change across a half dozen or so clients and lots of breaking changes, not to mention unknowns.

What I want us to do is make only a few half dozen or so lines of code changes to our clients and minimize the breaking changes and unknowns.

@zvava@twtxt.net Going to have to hard disagree here I’m sorry. a) no-one reads the raw/plain twtxt.txt files, the only time you do is to debug something, or have a stick beak at the comments which most clients will strip out and ignore and b) I’m sorry you’ve completely lost me! I’m old enough to pre-date before Linux became popular, so I’m not sure what UNIX principles you think are being broken or violated by having a Twt Subject (Subject) whose contents is a cryptographic content-addressable hash of the “thing”™ you’re replying to and forming a chain of other replies (a thread).

I’m sorry, but the simplest thing to do is to make the smallest number of changes to the Spec as possible and all agree on a “Magic Date” for which our clients use the modified function(s).

@prologic@twtxt.net considering other alternatives we have seeing (of which I have lost track already), yes. Why don’t you guys (client makers) take a step at a time and, for now, increase the hash length to deal with the collisions. Then location-based addressing can be added… or not, you know. 😅

TNO Threading (draft):
Each origin feed numbers new threads (tno:N). Replies carry both (tno:N) and (ofeed:<origin-url>). Thread identity = (ofeed, tno).

• Roots: (tno:N) (implicit ofeed=self).
  
• Replies: (tno:N) (ofeed:<url>).
  
• Clients: increment tno locally for new threads, copy tags on reply.
  
• Subjects optional, not required.
  

…

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

Here is just a small list of things™ that I’m aware will break, some quite badly, others in minor ways:

1. Link rot & migrations: domain changes, path reshuffles, CDN/mirror use, or moving from txt → jsonfeed will orphan replies unless every reader implements perfect 301/410 history, which they won’t.
   
2. Duplication & forks: mirrors/relays produce multiple valid locations for the same post; readers see several “parents” and split the thread.
   
3. Verification & spam-resistance: content addressing lets you dedupe and verify you’re pointing at exactly the post you meant (hash matches bytes). Location anchors can be replayed or spoofed more easily unless you add signing and canonicalization.
   
4. Offline/cached reading: without the original URL being reachable, readers can’t resolve anchors; with hashes they can match against local caches/archives.
   
5. Ecosystem churn: all existing clients, archives, and tools that assume content-derived IDs need migrations, mapping layers, and fallback logic. Expect long-lived threads to fracture across implementations.

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

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

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

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

@kat@yarn.girlonthemoon.xyz I reckon the original <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.

JMP: Newsletter: (e)SIM nicknames, Cheogram Android updates, and Cheogram iOS alpha
Hi everyone!

Welcome to the latest edition of your pseudo-monthly JMP update! (it’s been 7 months since the last one 😨)

In case it’s been a while since you checked out JMP, here’s a refresher: JMP lets you send and receive text and picture messages (and calls) through a real phone number right from your computer, tablet, phone, or anything else that has a Jabber client. Among other things, JMP has these features: Y … ⌘ Read more

i know yarn has a CLI client in yarnc but ngl i wish there was a TUI client. that’d be really fun

@zvava@twtxt.net Hooray for more twtxt clients 🥳

I finally have my new (top-secret) twtxt client in a working state. Next comes the deployment, which I hope to finish tonight. Release date: TBD. Stay tuned!

@dce@hashnix.club Ah, oh, well then. 🥴

My client supports that, if you set multiple url = fields in your feed’s metadata (the top-most one must be the “main” URL, that one is used for hashing).

But yeah, multi-protocol feeds can be problematic and some have considered it a mistake to support them. 🤔

@dce@hashnix.club Twet is a far better command line client. Yea 👌

@eric@itsericwoodward.com Name change is no worries! 😉 Interesting/funnily enough my client yarnd seems to have picked it up automatically which is nice (I’ve historically always had a few bugs to iron out there 🤣)

@kat@yarn.girlonthemoon.xyz yeah it’s pretty terrible these days. Most recent trouble I had was something as simple as installing and setting up the Tailscale client. On literally all my other devices (Linux and Android) that was a cinch, but on Windows…. ohh boy, I had to mess around with reg edits and all sorts of crap and eventually bludgeoned it into working, but it was a bloody pain.

In 1996, they came up with the X11 “SECURITY” extension:

https://www.reddit.com/r/linux/comments/4w548u/what_is_up_with_the_x11_security_extension/

This is what could have (eventually) solved the security issues that we’re currently seeing with X11. Those issues are cited as one of the reasons for switching to Wayland.

That extension never took off. The person on reddit wonders why – I think it’s simple: Containers and sandboxes weren’t a thing in 1996. It hardly mattered if X11 was “insecure”. If you could run an X11 client, you probably already had access to the machine and could just do all kinds of other nasty things.

Today, sandboxing is a thing. Today, this matters.

I’ve heard so many times that “X11 is beyond fixable, it’s hopeless.” I don’t believe that. I believe that these problems are solveable with X11 and some devs have said “yeah, we could have kept working on it”. It’s that people don’t want to do it:

Why not extend the X server?

Because for the first time we have a realistic chance of not having to do that.

https://wayland.freedesktop.org/faq.html

I’m not in a position to judge the devs. Maybe the X.Org code really is so bad that you want to run away, screaming in horror. I don’t know.

But all this was a choice. I don’t buy the argument that we never would have gotten rid of things like core fonts.

All the toolkits and programs had to be ported to Wayland. A huge, still unfinished effort. If that was an acceptable thing to do, then it would have been acceptable to make an “X12” that keeps all the good things about X11, remains compatible where feasible, eliminates the problems, and requires some clients to be adjusted. (You could have still made “X11X12” like “XWayland” for actual legacy programs.)