I think i may have fixed threading too but can’t easily test now as i’ve left for my
holiday and don’t really use Mastodon 😂
↳
In-reply-to
»
Hey @prologic 👋
⤋ Read More
@therealprologic@bridge.twtxt.net Sweet! Mentions are fixed! 👌 Now just have to fix threading!
↳
In-reply-to
»
@c350a5e5fb9d9457 Does this mean we'res starting to work, this whole Twtxt <-> ActivityPub bridge thingy? 🤔
⤋ Read More
@therealprologic@bridge.twtxt.net Okay so the mention translation is. busted and umm the threading is busted. But other than that, so far so good 😊
↳
In-reply-to
»
There are no really good GUI toolkits for Linux, are there?
⤋ Read More
FTR, I see one (two) issues with PyQt6, sadly:
- The PyQt6 docs appear to be mostly auto-generated from the C++ docs. And they contain many errors or broken examples (due to the auto-conversion). I found this relatively unpleasent to work with.
- (Until Python finally gets rid of the Global Interpreter Lock properly, it’s not really suited for GUI programs anyway – in my opinion. You can’t offload anything to a second thread, because the whole program is still single-threaded. This would have made my fractal rendering program impossible, for example.)
↳
In-reply-to
»
Hello World! Testing 1 2 3
⤋ Read More
@therealprologic@bridge.twtxt.net It works! 🤣 Now I’m quite sure we haven’t got threads working yet 🤔
↳
In-reply-to
»
Hmmm all these
⤋ Read More
tilde.club feeds have no # nick and is messing with yarnd's behavior 😅
@prologic@twtxt.net And none of them use Yarn-style threading. I don’t think they’re aware of us, they’re probably using plain twtxt. Other than one hit by @threatcat@tilde.club a few days ago, I’ve seen no traffic from them. 🤔
GTK2 about to be removed from the official Arch repos: https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.org/thread/2BDHYLEFSYQBDTMUOZT5J6AFTA5M3FO6/
It’ll probably all be dropped to the AUR, so I can build this myself, because I still have some stuff that depends on it (and will never receive further updates).
Python 3.14.0 released
Version\
3.14.0 of the Python language has been released. There are a lot of
changes this time around, including official support for free threading, template string literals, and much more; see
the announcement for details. ⌘ Read more
Hello again everyone! A little update on my twtxt client.
I think it’s finally shaping a bit better now, but… ☝️
As I’m trying to put all the parts together, I decided to build multiple parallel UIs, to ensure I don’t accidentally create a structure that is more rigid than planned.
I already decided on a UI that I would want to use for myself, it would be inspired by moshidon, misskey and some other “social feeds” mock-ups I found on dribbble.
I also plan on building a raw HTML version (for anyone wanting to do a full DIY client).
I would love to get any suggestions of what you would like to see (and possibly use) as a client, by sharing a link, app/website name or even a sketch made by you on paper.
I think I’ll pick a third and maybe a fourth design to build together with the two already mentioned.
For reference, the screens I think of providing are (some might be optional or conditionally/manually hidable):
- Global / personal timeline screen
- Profile screen (with timeline)
- Thread screen
- Notifications screen or popup (both valid)
- DM list & chat screens (still planning, might come later)
- Settings screen (it’ll probably be a hard coded form, but better mention it)
- Publish / edit post screen or popup (still analysing some use cases, as some “engines” might not have direct publishing support)
I also plan on adding two optional metadata fields:
display_name: To show a human readable alternative for a nick, it fallback tonickif not defined
banner: Using the same format asavatarbut the image expected is wider, inspired by other socials around
I also plan on supporting any metadata provided, including a dynamically parsable regex rule format for those extra fields, this should allow anyone to build new clients that don’t limit themselves to just the social aspect of twtxt, hoping to see unique ways of using twtxt! 🤞
↳
In-reply-to
»
is the first
⤋ Read More
url metadata field unequivocally treated as the canon feed url when calculating hashes, or are they ignored if they're not at least proper urls? do you just tolerate it if they're impersonating someone else's feed, or pointing to something that isn't even a feed at all?
@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).
↳
In-reply-to
»
is the first
⤋ Read More
url metadata field unequivocally treated as the canon feed url when calculating hashes, or are they ignored if they're not at least proper urls? do you just tolerate it if they're impersonating someone else's feed, or pointing to something that isn't even a feed at all?
@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://txt.sour.is/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
»
@zvava @lyse I also think a location based reference might be better.
⤋ 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
»
@zvava @lyse I also think a location based reference might be better.
⤋ 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
»
@lyse i dont mind if the hash is not backward compatible but im not sure if this is the right way to proceed because the added complexity dealing with two hash versions isnt justified
⤋ Read More
@zvava@twtxt.net @lyse@lyse.isobeef.org I also think a location based reference might be better.
A thread is a single post of a single feed as a root, but the hash has the drawback of not referencing the source, in a distributed network like twtxt it might leave some people out of the whole conversation.
I suggest a simpler format, something like: (#<TIMESTAMP URL>)
This solves three issues:
- Easier referencing: no need to generate a hash, just copy the timestamp and url, it’s also simpler to implement in a client without the rish of collisions when putting things together
- Fetchable source: you can find the source within the reference and construct the thread from there
- Allow editing: If a post is modified the hash becomes invalid since it depends on
[ timestamp, url, content ]
↳
In-reply-to
»
@prologic im unsure how i feel about the hash v2 proposal, given it is completely backward incompatible with hash v1 it doesn't really solve any of the problems with it. it only delays collisions, and still fragments threads on post edits
⤋ Read More
@lyse@lyse.isobeef.org i dont mind if the hash is not backward compatible but im not sure if this is the right way to proceed because the added complexity dealing with two hash versions isnt justified
regular end users wont care to understand how twt hashes are formed, they just want to use twtxt! so i guess i could work in protecting users from themselves by disallowing post edits on old posts or posts with replies, but i’m not fond of this either really. if they want to break a thread, they can just delete the post (though i’ve noticed yarn handling post deletes dubiously…)
on activitypub i do genuinely find myself looking through several month or even year old posts sometimes and deciding to edit/reword them a little to be slightly less confusing, this should be trivial to handle on twtxt which is an infinitely simpler specification
↳
In-reply-to
»
@prologic im unsure how i feel about the hash v2 proposal, given it is completely backward incompatible with hash v1 it doesn't really solve any of the problems with it. it only delays collisions, and still fragments threads on post edits
⤋ 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
»
@zvava Herw you go: https://git.mills.io/yarnsocial/twtxt.dev/pulls/28
⤋ Read More
@prologic@twtxt.net im unsure how i feel about the hash v2 proposal, given it is completely backward incompatible with hash v1 it doesn’t really solve any of the problems with it. it only delays collisions, and still fragments threads on post edits
i skimmed through discussions under other the proposals — i agree humans are very bad at keeping the integrity of the web in tact, but hashes in done in this way make it impossible even for systems to rebuild threads if any post edits have occurred prior to their deployment
search page, bookmarks page, improved thread view (that i will probably improve further), as well as a logo and a whole ui redesign. it is truly all coming together…were i to mark any items off the roadmap :p
replies and following implemented! next step is further parsing of post contents, rendering threads, and then maybe i can finally start adding remote feeds…! though i kinda wanna redo the whole ui ^^’
↳
In-reply-to
»
It might just be my client, but it seems that I cannot track multiple URLs at once. As such, all three of my twtxt URLs will work for following, but mentions will only reach me at my HTTPS URL (https://hashnix.club/~dce/twtxt.txt). If there is a client that can cope with twtxt mirrors, I would love to know about it.
⤋ 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.
↳
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
Even More iPhone Safety Tips You Should Know
Last week, we shared a list of iPhone safety tools that every iPhone owner should know about, from Emergency SOS and Medical ID to Safety Check and Check In. MacRumors readers had more suggestions on safety information we should highlight, so we have a follow-up … ⌘ 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
»
I've just released version 1.0 of twtxt.el (the Emacs client), the stable and final version with the current extensions. I'll let the community maintain it, if there are interested in using it. I will also be open to fix small bugs.
I don't know if this twt is a goodbye or a see you later. Maybe I will never come back, or maybe I will post a new twt this afternoon. But it's always important to be grateful. Thanks to @prologic @movq @eapl.me @bender @aelaraji @arne @david @lyse @doesnm @xuu @sorenpeter for everything you have taught me. I've learned a lot about #twtxt, HTTP and working in community. It has been a fantastic adventure!
What will become of me? I have created a twtxt fork called Texudus (https://texudus.readthedocs.io/). I want to continue learning on my own without the legacy limitations or technologies that implement twtxt. It's not a replacement for any technology, it's just my own little lab. I have also made a fork of my own client and will be focusing on it for a while. I don't expect anyone to use it, but feedback is always welcome.
Best regards to everyone.
#twtxt #emacs #twtxt-el #texudus
⤋ Read More
@sorenpeter@darch.dk Yes, there are interesting things that can be incorporated to see how they work.
The issue of allowing the use of Z for UTC is interesting. I think I should add a brief explanation.
The url issue is for a debate :D . Maybe an issue could be opened. My opinion is that it is necessary to leave it as it is right now because otherwise the thread system, or replies, may have problems (404s). It’s all a matter of discussion.
I like your idea of contact. I will add it.
Thanks to you for your feedback!!!
↳
In-reply-to
»
I've just released version 1.0 of twtxt.el (the Emacs client), the stable and final version with the current extensions. I'll let the community maintain it, if there are interested in using it. I will also be open to fix small bugs.
I don't know if this twt is a goodbye or a see you later. Maybe I will never come back, or maybe I will post a new twt this afternoon. But it's always important to be grateful. Thanks to @prologic @movq @eapl.me @bender @aelaraji @arne @david @lyse @doesnm @xuu @sorenpeter for everything you have taught me. I've learned a lot about #twtxt, HTTP and working in community. It has been a fantastic adventure!
What will become of me? I have created a twtxt fork called Texudus (https://texudus.readthedocs.io/). I want to continue learning on my own without the legacy limitations or technologies that implement twtxt. It's not a replacement for any technology, it's just my own little lab. I have also made a fork of my own client and will be focusing on it for a while. I don't expect anyone to use it, but feedback is always welcome.
Best regards to everyone.
#twtxt #emacs #twtxt-el #texudus
⤋ 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.