Of course we still have to fix the hashing algorithm and length.

I would personally rather see something like this:

2025-09-25T22:41:19+10:00	Hello World
2025-09-25T22:41:19+10:00	(#kexv5vq https://example.com/twtxt.html#:~:text=2025-09-25T22:41:19%2B10:00) Hey!

Preserving both content-based addressing as well as location-based addressing and text fragment linking.

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.

@alexonit@twtxt.alessandrocutolo.it Holy fuck! 🤣 I just realized how bad my typing was in my reply before 🤣 🤦‍♂️ So sorry about that haha 😆 I blame the stupid iPhone on-screen keyboard ⌨️

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

@lyse@lyse.isobeef.org I don’t think there’s any point in continuing the discussion of Location vs. Content based addressing.

I want us to preserve Content based addressing.

Let’s improve the user experience and fix the hash commission problems.

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.

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.

@kat@yarn.girlonthemoon.xyz Mine shows 1/1 of 14 Twts 😆 I think this is a bug 🤯

@alexonit@twtxt.alessandrocutolo.it I took it down mostly because of continued abuse and spam:l. I intend to fix I and improve the drive and its sister at Summer point 🤞

@alexonit@twtxt.alessandrocutolo.it Love this 😍

@alexonit@twtxt.alessandrocutolo.it Yeah same 🤣 There’s also this @news-minimalist@feeds.twtxt.net feed that shows up the most important shit™ anyway (when/if that happens).

@bender@twtxt.net Seriously I have zero clue 🤣 I don’t read or watch any news so I have no idea 🤦‍♂️

Did something bad happen in the world today? 🧐

Hello 👋 I’m back!

@bender@twtxt.net Soon soon🤣

@bender@twtxt.net I wish 🤣 Nah work on-site thingy😆