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

Here’s an example of X11/Xlib being old and archaic.

X11 knows the data type “cardinal”. For example, the window property _NET_WM_ICON (which holds image data for icons) is an array of “cardinal”. I am already not really familiar with that word and I’m assuming that it comes from mathematics:

https://en.wikipedia.org/wiki/Cardinal_number

(It could also be a bird, but probably not: https://en.wikipedia.org/wiki/Cardinalidae)

We would probably call this an “integer” today.

EWMH says that icons are arrays of cardinals and that they’re 32-bit numbers:

https://specifications.freedesktop.org/wm-spec/latest-single/#id-1.6.13

So it’s something like 0x11223344 with 0x11 being the alpha channel, 0x22 is red, and so on.

You would assume that, when you retrieve such an array from the X11 server, you’d get an array of uint32_t, right?

Nope.

Xlib is so old, they use char for 8-bit stuff, short int for 16-bit, and long int for 32-bit:

https://x.org/releases/current/doc/libX11/libX11/libX11.html#Obtaining_and_Changing_Window_Properties

That is congruent with the general C data types, so it does make sense:

https://en.wikipedia.org/wiki/C_data_types

Now the funny thing is, on modern x86_64, the type long int is actually 64 bits wide.

The result is that every pixel in a Pixmap, for example, is twice as large in memory as it would need to be. Just because Xlib uses long int, because uint32_t didn’t exist, yet.

And this is something that I wouldn’t know how to fix without breaking clients.

It annoys me when I clone a git repository A in order to build and self-host some software, only to realize later that I also needed to clone repos B, C and D. I’m not saying that’s a bad thing–logical separation of code between, say, a client and a server is very handy–but some projects do not communicate very well when you need multiple tools to get it running independently.

OpenBSD has the wonderful pledge() and unveil() syscalls:

https://www.youtube.com/watch?v=bXO6nelFt-E

Not only are they super useful (the program itself can drop privileges – like, it can initialize itself, read some files, whatever, and then tell the kernel that it will never do anything like that again; if it does, e.g. by being exploited through a bug, it gets killed by the kernel), but they are also extremely easy to use.

Imagine a server program with a connected socket in file descriptor 0. Before reading any data from the client, the program can do this:

unveil("/var/www/whatever", "r");
unveil(NULL, NULL);
pledge("stdio rpath", NULL);

Done. It’s now limited to reading files from that directory, communicating with the existing socket, stuff like that. But it cannot ever read any other files or exec() into something else.

I can’t wait for the day when we have something like this on Linux. There have been some attempts, but it’s not that easy. And it’s certainly not mainstream, yet.

I need to have a closer look at Linux’s Landlock soon (“soon”), but this is considerably more complicated than pledge()/unveil():

https://landlock.io/

@movq@www.uninformativ.de Me too 😅 – Speaking of which i know you’ve lost a bit of “mojo” or “energy” (so have i of late), rest assured, I want to keep the status quo here with what we’ve built, keep it simple and change very little. What we’ve built has worked very well for 5+ years and we have at least 3 very strong clients (maybe 4 or 5?).

The Software Design I See: Thick–Thin Clients
Comments ⌘ Read more

How Let’s Encrypt reduced the impact of zombie clients
Comments ⌘ Read more

How One Path Traversal in Grafana Unleashed XSS, Open Redirect and SSRF (CVE-2025–4123)

Image

Abusing Client Path Traversal to Chain XSS, SSRF and Open Redirect in Grafana

[Continue rea … ⌘ Read more

How to Play Fortnite on Mac with FnMacAssistant & Sideloadly
Gamers everywhere are happy that Fortnite is back for iPhone and iPad users, but there’s no Mac client in sight (yet anyway). But that doesn’t mean you can’t play Fortnite on the Mac, because if you have an Apple Silicon Mac, and you’re comfortable running some mods and tweaks, you can get the iOS/iPadOS version … [Read More](https://osxdaily.com/2025/05/31/how-to-play-fortnite-on-mac-with-fnmacassistant-sidel … ⌘ Read more

First version of Elicitation to the MCP draft specification
Comments ⌘ Read more

$750 Bounty: for HTTP Request Smuggling on Data.gov

Image

How a cleverly crafted desync attack revealed a hidden path to client-side compromise, JS injection and potential cookie theft

[Continue reading on InfoSec Write-ups »](https://infosecwriteups.com/ … ⌘ Read more

Ending TLS Client Authentication Certificate Support in 2026
Comments ⌘ Read more

HMPL v3.0: Small template language for displaying UI from server to client
Comments ⌘ Read more

#<2025-05-10T19:34:00+00:00 https://andros.dev/texudus.txt> Nice:) And is this implemented in your client as well? I’ve started to brainstorm on how to parse texudus in php, but I guess it could snatch some code from you?

GitHub for Beginners: Building a React App with GitHub Copilot
Follow along and build a frontend client using React and Copilot Chat.

The post GitHub for Beginners: Building a React App with GitHub Copilot appeared first on The GitHub Blog. ⌘ Read more

MCP 超強源碼解讀！Streamable HTTP 如何實現服務端向客戶端通信
在最新的 Model Context Protocol（MCP，模型上下文協議）版本（2025-03-26）[1] 中引入了 Streamable HTTP 的通信方式，取代了舊版本中的 SSE 通信方式，成爲了新的遠程 MCP 調用標準。Streamable HTTP 通信下的 client 向 server 的請求不需要像之前必須保持 SSE 的長連接，而是通過 client 發起 HTTP ⌘ Read more

UUIDs: A False Sense Of Security

Image

Hi Hunters, would you like to learn about a broken access control vulnerability that I discovered recently for a client.

[Continue reading on InfoSec Write-ups »](https://infosecwriteups.com/uuids-a-false-sense-of-security-10467497daae?source=rss—-7b7 … ⌘ Read more

@sorenpeter@darch.dk Unfortunately it does break all clients, because the original spec stated:

Mentions are embedded within the text in either @ or @ format

@bender@twtxt.net My point was that the suggested syntax for extending mentions to point to a specific message (@<nick url timestamp>) and having location based treading this way, might not break older clients, since they might just igonore the last value within the brackets.

@sorenpeter@darch.dk you wrote:

“This might even be backward compatible with older (pre-yarn) clients.”

Yarnd is as backwards compatible with older clients as this. I dare to say, even more so. 😅

@andros@twtxt.andros.dev Thanks for consolidating a lot of good ideas. Especially how you have deiced to just extend the mention syntax for location-based treads. This might even be backward compatible with older (pre-yarn) clients.
What about using Z for UTC +00:00- is that allowed in your specs?
Regarding url = I would suggest to only allow one and the maybe add url_old = or url_alt = !?
I’m still not a fan of a DM feature, even thou it helps that i have now been split out into a separate feed file. Instead if would suggest a contact = field for where people can put an email or other id/link for an established chat protocol like signal or matrix.

@andros@twtxt.andros.dev @eapl.me@eapl.me Still lots of bugs in my client. 🥴 I’ll try to fix it next week.

And yes, using the same timestamp twice will very likely break threads.

@andros@twtxt.andros.dev I set up a test feed here:

https://www.uninformativ.de/texudus.txt

I made some preliminary adjustments to my client so that it can work with the different threading model. (And I totally get the concerns, this can be quite a bit of work. Especially in a large code base like Yarn.)

@movq@www.uninformativ.de I think we can make this work 👌 As long as it’s just a client hint.

@movq@www.uninformativ.de If we’re focusing on solving the “missing roots” problems. I would start to think about “client recommendations”. The first recommendation would be:

1. Replying to a Twt that has no initial Subject must itself have a Subject of the form (hash; url).
   

This way it’s a hint to fetching clients that follow B, but not A (in the case of no mentions) that the Subject/Root might (very likely) is in the feed url.

從 0 開始實現 MCP-Client
什麼是 MCP-Client？MCP-Client是Model Context Protocol（模型上下文協議）架構中的一個重要組件，用於連接AI模型（如Claude、GPT等大型語言模型）與外部數據源、工具和服務的橋樑。MCP（Model Context Protocol）是由Anthropic公司在 2024 年底首次提出並開源的一種開放標準協議，旨在解決大語言模型（LLM）與外部世界的連接 ⌘ Read more

@lyse@lyse.isobeef.org likewise I don’t have the energy for a fundamental shift in any of our specifications that would inevitably cause a lot of toil and try and change in our clients implementations and unforeseen problems that we haven’t really fully understood:

@lyse@lyse.isobeef.org Hahahaha 🤣 I mean it’s “okay” every now and then, but what’s the point of having good clients and tools if we don’t use ‘em 🤣