Discussion Thread - Ask, Share, and Discuss Anything About Cats. ⌘ Read more
@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).
@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.
↳
In-reply-to
»
I would personally rather see something like this:
⤋ Read More
@alexonit@twtxt.alessandrocutolo.it Well we have to really use the same spec or threading doesn’t really work in a truly decentralized manner 😉
↳
In-reply-to
»
@bender Really? 🤔
⤋ Read More
@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).
↳
In-reply-to
»
I would personally rather see something like this:
⤋ Read More
@alexonit@twtxt.alessandrocutolo.it My problem is I don’t see a world where we don’t employ some form of cryptography to use as keys for threads in databases and other such things honestly. I’m not going to use url#timestamp as keys.
↳
In-reply-to
»
TNO Threading (draft):
Each origin feed numbers new threads
⤋ Read More
Each origin feed numbers new threads
(tno:N). Replies carry both (tno:N) and (ofeed:<origin-url>). Thread identity = (ofeed, tno).
@prologic@twtxt.net That’s a completely flat threading model (you can’t reply to replies). Is that intentional?
↳
In-reply-to
»
TNO Threading (draft):
Each origin feed numbers new threads
⤋ Read More
Each origin feed numbers new threads
(tno:N). Replies carry both (tno:N) and (ofeed:<origin-url>). Thread identity = (ofeed, tno).
This is possibly the only other threading model I can come up with for Twtxt that I think I can get behind.
↳
In-reply-to
»
TNO Threading (draft):
Each origin feed numbers new threads
⤋ Read More
Each origin feed numbers new threads
(tno:N). Replies carry both (tno:N) and (ofeed:<origin-url>). Thread identity = (ofeed, tno).
Example:
Alice starts thread href=”https://we.loveprivacy.club/search?q=%2342:”>#42:**
2025-09-25T12:00:00Z (tno:42) Launching storage design review.
Bob replies:
2025-09-25T12:05:00Z (tno:42) (ofeed:https://alice.example/twtxt.txt
) I think compaction stalls under load.
Carol replies to Bob:
2025-09-25T12:08:00Z (tno:42) (ofeed:https://alice.example/twtxt.txt
) Token bucket sounds good.
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)(implicitofeed=self).
- Replies:
(tno:N) (ofeed:<url>).
- Clients: increment
tnolocally for new threads, copy tags on reply.
- Subjects optional, not required.
…
↳
In-reply-to
»
(#altkl2a) Here is just a small list of things™ that I'm aware will break, some quite badly, others in minor ways:
⤋ Read More
I was trying to say (badly):
That’s kind of my position on this. If we are going to make significant changes in the threading model, let’s keep content based addressing, but also improve the user experience. Answering your question, yes I think we can do some combination of both.
↳
In-reply-to
»
(#altkl2a) Here is just a small list of things™ that I'm aware will break, some quite badly, others in minor ways:
⤋ Read More
@alexonit@twtxt.alessandrocutolo.it Yhays kind of love you!! Stance and position on this. If we are going to make chicken changes in the threading model, let’s keep content based addressing, but also improve the use of experience. So in fact, in order to answer your question, I think yes, we can do some kind of combination of both.
↳
In-reply-to
»
(#altkl2a) Here is just a small list of things™ that I'm aware will break, some quite badly, others in minor ways:
⤋ Read More
@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:
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.
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.
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?
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.
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:
- 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.
- Duplication & forks: mirrors/relays produce multiple valid locations for the same post; readers see several “parents” and split the thread.
- 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.
- Offline/cached reading: without the original URL being reachable, readers can’t resolve anchors; with hashes they can match against local caches/archives.
- 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.
We’ve been discussing the idea of changing the threading model from Content-based Addressing to Location-based addressing for years now. The problem is quite complex, but I feel I have to keep reminding y’all of the potential perils of changing this and the pros/cons of each model:
With content-addressed threading, a reply points at something that’s intrinsically identified (hash of author/feed URI + timestamp + content). That ID never changes as long as the content doesn’t. Switching to location-based anchors makes the reply target extrinsic—it now depends on where the post currently lives. In a pull-based, decentralised network, locations drift. The moment they do, thread identity fragments.
@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.
@movq@www.uninformativ.de Yeah, we’ve seen how this plays out in practice 🤣 @dce@hashnix.club My advice, do what @movq@www.uninformativ.de has hinted at and don’t change the 1st # url = field in your feed. I’m not sure if you had already, but the first url field is kind of important in your feed as it is used as the “Hashing URI” for threading.
↳
In-reply-to
»
OpenBSD has the wonderful
⤋ Read More
pledge() and unveil() syscalls:
@lyse@lyse.isobeef.org Multi-Threading. Is. Hard. 🤯 And yes, that blog is great. 👌
https://threadreaderapp.com/thread/1935344122103308748.html Interesting article on how ChatGPT is rotting your brain 🤣
When was the last time you broke production and how?
Inspired by this post on senior engineers telling junior engineers about their mistakes, I am asking you all to share your stories or even existing posts about a situation where you royally fucked something up.
(Bonus points for every story that is turned into a blog post just for this thread) ⌘ Read more