↳
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
»
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
»
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
»
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. :-)
↳
In-reply-to
»
The original twt is unavailable. It may have been edited or deleted, or is from an unknown or muted feed.
⤋ Read More
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.
↳
In-reply-to
»
The original twt is unavailable. It may have been edited or deleted, or is from an unknown or muted feed.
⤋ Read More
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.
↳
In-reply-to
»
The original twt is unavailable. It may have been edited or deleted, or is from an unknown or muted feed.
⤋ Read More
@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.
↳
In-reply-to
»
The original twt is unavailable. It may have been edited or deleted, or is from an unknown or muted feed.
⤋ Read More
@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.
PEP 803: Stable ABI for Free-Threaded Builds
Version 3.15 of the Stable ABI will be compatible with both free-threaded and GIL-enabled builds. To allow this, the PyObject internal structure and related APIs will be removed from version 3.15 of the Limited API, requiring migration to new API for common tasks like defining modules and most classes. ⌘ Read more
↳
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
↳
In-reply-to
»
@kat I don’t like Golang much either, but I am not a programmer. This little site, Go by example might explain a thing or two.
⤋ Read More
One of the nicest things about Go is the language itself, comparing Go to other popular languages in terms of the complexity to learn to be proficient in:
- Go:
25keywords (Stack Overflow); CSP-style concurrency (goroutines & channels)
- Python 2:
30keywords (TutorialsPoint); GIL-bound threads & multiprocessing (Wikipedia)
- Python 3:
35keywords (Initial Commit); GIL-bound threads,asyncio& multiprocessing (Wikipedia, DEV Community)
- Java:
50keywords (Stack Overflow); threads +java.util.concurrent(Wikipedia)
- C++:
82keywords (Stack Overflow);std::thread, atomics & futures (en.cppreference.com)
- JavaScript:
38keywords (Stack Overflow); single-threaded event loop &async/await, Web Workers (Wikipedia)
- Ruby:
42keywords (Stack Overflow); GIL-bound threads (MRI), fibers & processes (Wikipedia)
Banana Pi BPI-Forge1 Is a Low-Cost RK3506J-Based SBC Compatible with RT-Thread
Banana Pi’s BPI-Forge1 is a compact single-board computer based on the Rockchip RK3506J SoC, designed for digital multimedia processing, intelligent voice interaction, and real-time audio applications. The board supports a range of embedded use cases through its integrated audio and display subsystems, peripheral connectivity, and small form factor. The RK3506J features a triple-core Arm … ⌘ Read more
PEP 793: PyModExport: A new entry point for C extension modules
In this PEP, we propose a new entry point for C extension modules, by which one can define a module using an array of PyModuleDef_Slot structures without an enclosing PyModuleDef structure. This allows extension authors to avoid using a statically allocated PyObject, lifting the most common obstacle to making one compiled library file usable with both regular and free-threaded builds of CPython. ⌘ Read more
(Updated) ESP32-C5-DevKitC-1 with 240MHz RISC-V Processor, Zigbee, and Thread Connectivity
The ESP32-C5-DevKitC-1 is another upcoming entry-level development board designed for IoT applications, featuring the ESP32-C5-WROOM-1 module. This board supports key wireless protocols, including Wi-Fi 6 (2.4 GHz and 5 GHz), Bluetooth LE 5, Zigbee, and Thread. The ESP32-C5-WROOM-1 module is equipped with a 32-bit RISC-V single-core processor running at 240 MHz along … ⌘ Read more
↳
In-reply-to
»
The original twt is unavailable. It may have been edited or deleted, or is from an unknown or muted feed.
⤋ Read More
@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.
↳
In-reply-to
»
The original twt is unavailable. It may have been edited or deleted, or is from an unknown or muted feed.
⤋ Read More
@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.)
↳
In-reply-to
»
@kat That's what I was going for at first, I already have my compose file to go
⤋ Read More
up -d, but then I took a look at a couple of #Snac instances at the last second and they looked pretty dope! Now I'm stuck in my own head 😅
@bender@twtxt.net Mainly the bsd.cafe ones. I like how the minimalist single column profiles look. Image embeds are full width and reading through threads feels nice (as in it doesn’t feel like pealing layers upon layers of a fresh onion).
If we must stick to hashes for threading, can we maybe make it mandatory to always include a reference to the original twt URL when writing replies?
Instead of
(<a href="https://we.loveprivacy.club/search?q=%23123467">#123467</a>) hello foo bar
you would have
(<a href="https://we.loveprivacy.club/search?q=%23123467">#123467</a> http://foo.com/tw.txt) hello foo bar
or maybe even:
(<a href="https://we.loveprivacy.club/search?q=%23123467">#123467</a> 2025-04-30T12:30:31Z http://foo.com/tw.txt) hello foo bar
This would greatly help in reconstructing broken threads, since hashes are obviously unfortunately one-way tickets. The URL/timestamp would not be used for threading, just for discovery of feeds that you don’t already follow.
I don’t insist on including the timestamp, but having some idea which feed we’re talking about would help a lot.
↳
In-reply-to
»
Finally I propose that we increase the Twt Hash length from
⤋ Read More
7 to 12 and use the first 12 characters of the base32 encoded blake2b hash. This will solve two problems, the fact that all hashes today either end in q or a (oops) 😅 And increasing the Twt Hash size will ensure that we never run into the chance of collision for ions to come. Chances of a 50% collision with 64 bits / 12 characters is roughly ~12.44B Twts. That ought to be enough! -- I also propose that we modify all our clients and make this change from the 1st July 2025, which will be Yarn.social's 5th birthday and 5 years since I started this whole project and endeavour! 😱 #Twtxt #Update
@eapl.me@eapl.me I honestly believe you are overreacting here a little bit 🤣 I completely emphasize with you, it can be pretty tough to feel part of a community at times and run a project with a kind of “democracy” or “vote by committee”. But one thing that life has taught me about open source projects and especially decentralised ecosystems is that this doesn’t really work.
It isn’t that I’ve not considered all the other options on the table (which can still be), it’s just that I’ve made a decision as the project lead that largely helped trigger a rebirth of the use of Twtxt back in July 1 2020. There are good reasons not to change the threading model right now, as the changes being proposed are quite disruptive and don’t consider all the possible things that could go wrong.
@bmallred@staystrong.run Hehe, @bender@twtxt.net is gonna be upset with you for “making up a thread/subject” 🤣
↳
In-reply-to
»
The original twt is unavailable. It may have been edited or deleted, or is from an unknown or muted feed.
⤋ Read More
@bender@twtxt.net Nah it’s there but it’s a reply to a thread that isn’t found here hmmm 🤔