I asked ChatGPT what it knows about Twtxt 😂 And surprisingly it’s rather accurate:

Twtxt is a minimalist, decentralized microblogging format introduced by John Downey in 2016. It uses plain text files served over HTTP—no accounts, databases, or APIs.
In 2020, James Mills (@prologic@twtxt.net) launched Yarn.social, an extended, federated implementation with user discovery, threads, mentions, and a full web UI.
Both share the same .twtxt.txt format but differ in complexity and social features.

@kat@yarn.girlonthemoon.xyz It’s more like a cache, it stores things like “timestamp of the most recent twt we’ve seen per feed” or “last modification date” (to be used with HTTP’s if-modified-since header). You can nuke these files at any time, it might just result in more traffic (e.g., always getting a full response instead of just “HTTP 304 nope, didn’t change”).

@quark@ferengi.one Yes, I often write a couple of twts, don’t publish them, then sometimes notice a mistake and want to edit it. You’re right, as soon as stuff is published, threads are going to break/fork by edits.

@quark@ferengi.one No editing old Twts that are the root of a thread with replies in the ecosystem. Just results in a fork. Unless the client has an implementation that does not store Twts keyed by Hash.

Show HN: HN Watercooler – listen to HN threads as an audio conversation
Comments ⌘ Read more

@movq@www.uninformativ.de this settles it then. Hopefully @andros@twtxt.andros.dev can make slight corrections, and broken threads will be a thing of the past! Thanks!

@andros@twtxt.andros.dev maybe @movq@www.uninformativ.de, @lyse@lyse.isobeef.org, @prologic@twtxt.net, and @xuu@txt.sour.is can explain what’s going on here, or which approach is the right one. One thing seems to be happening: your approach is breaking “conversations” (threads), as the other clients seemingly do not agree.

The case of the UI thread that hung in a kernel call
Comments ⌘ Read more

@david@collantes.us Yeah, we’ve been debugging that a bit yesterday. Looks like the wrong input (sometimes) gets fed to the hash function → broken threads.

@david@collantes.us Ah, yes, the hardware might not. As I just said in the other thread: No problem, you can keep the same installation. I did so many times on my PC/laptop at work.

@prologic@twtxt.net The threads’ broken for me, I can’t find znf6csa. 🤔

@bender@twtxt.net i had to go to your instance to see the root post because I ACCIDENTALLY MUTED THE THREAD LMFAOOOOO but interesting re: unfollowing!

@kat@yarn.girlonthemoon.xyz I MUTED MY OWN THREAD this is what happens when i post at 7am

We should look at this thread
https://github.com/snarfed/bridgy-fed/issues/1873
#twtxt

Multi-threading is always the wrong design
Comments ⌘ Read more

For anyone following the proposals to improve replies and threads in twtxt, the voting period has started and will be open for a week.
https://eapl.me/rfc0001/

Please share the link with the twtxt community, and leave your vote on your preferred proposals, which will be used to gauge the perceived benefits.

Also, the conversation is open to discuss implementation concerns or anything aimed at making twtxt better.

@prologic@twtxt.net Gemini has an answer for you:

This is a conversation thread from a twtxt network, detailing a user’s (movq) frustration with the Mastodon “export data” feature and their consideration of self-hosting a fediverse alternative. Here’s a summary:

• movq’s initial issue:
  
  • movq is concerned about the volatility of their data on their current Mastodon instance due to a broken “export data” feature.
    
  • They contacted the admins, but the issue remains unresolved.
    
  • This led them to contemplate self-hosting.
    
• Alternative fediverse software suggestions:
  
  • kat suggests gotosocial as a lightweight alternative to Mastodon.
    
  • movq agrees, and also mentions snac as a potential option.
    
• movq’s change of heart:
  
  • movq ultimately decides that self-hosting any fediverse software, besides twtxt, is too much effort.
    
• Resolution and compromise:
  
  • The Mastodon admins attribute the export failure to the size of movq’s account.
    
  • movq decides to set their Mastodon account to auto-delete posts after approximately 180 days to manage data size.
    
  • Movq also mentions that they use auto-expiring links on twtxt to reduce data storage.

@eapl.me@eapl.me Cool!

Proposal 3 (https://git.mills.io/yarnsocial/twtxt.dev/issues/18#issuecomment-19215) has the “advantage”, that you do not have to “mention” the original author if the thread slightly diverges. It seems to be a thing here that conversations are typically very flat instead of trees. Hence, and despite being a tree hugger, I voted for 3 being my favorite one, then 2, 1 and finally 4.

All proposals still need more work to clarify the details and edge cases in my opinion before they can be implemented.

@bender@twtxt.net Yeah, as you mentioned in the other thread, @andros@twtxt.andros.dev’s hashes appear to be not quite right. 🤔

Hi! For anyone following the Request for Comments on an improved syntax for replies and threads, I’ve made a comparative spreadsheet with the 4 proposals so far. It shows a syntax example, and top pros and cons I’ve found:
https://docs.google.com/spreadsheets/d/1KOUqJ2rNl_jZ4KBVTsR-4QmG1zAdKNo7QXJS1uogQVo/edit?gid=0#gid=0

Feel free to propose another collaborative platform (for those without a G account), and also share your comments and analysis in the spreadsheet or in Gitea.

Google makes Vulkan the official graphics API for Android
Google’s biggest announcement today, at least as it pertains to Android, is that the Vulkan graphics API is now the official graphics API for Android. Vulkan is a modern, low-overhead, cross-platform 3D graphics and compute API that provides developers with more direct control over the GPU than older APIs like OpenGL. This increased control allows for significantly improved performance, especially in multi-threaded a … ⌘ Read more

well (insert stubborn emoji here) 😛, word blog comes from weblog, and microblogging could derivate from ‘smaller weblog’. https://www.wikiwand.com/en/articles/Microblogging

I’d differentiate it from sharing status updates as it was done with ‘finger’ or even a BBS. For example, being able to reply; create new threads and sharing them on a URL is something we could expect from ‘Twitter’, the most popular microbloging model (citation needed)

I like to discuss it, since conversations usually are improved if we sync on what we understand for the same words.

One of the biggest gripes of the community with the way the threading model currently works with Twtxt v1.2 (https://twtxt.dev) is this notion of:

What is this hash?
What does it refer to?

Idea: Why can’t we all agree to implement a simple URI scheme where we host our Twtxt feeds?

That is, if you host your feed at https://example.com/twtxt.txt – Why can’t or could you not also host various JSON files (let’s agree on the spec of course) at https://example.com/twt/<hash> ? 🤔

That way we solve this problem in a truly decentralised way, rather than every relying on yarnd pods alone.

Hi everyone,
I’ve drafted a Request for Comments (RFC) to improve how threads work in twtxt:
https://git.mills.io/yarnsocial/twtxt.dev/issues/18

I’d love your feedback! Please share your thoughts on anything that could be better explained, check if the proposed dates work for everyone, and I invite you to join the discussion…

I have released new updates to the twtxt.el client.

• New feature: View and interact with threads.
  
• Optimisation of ordering for long feeds.
  
• Minor fixes.
  

In the next version you will be able to see all your mentions.

Enjoy!

#emacs #twtxt #twtxtel

a few async ideas for later

The editing process needs a lot of consideration and compromises.

From one side, editing and deleting it’s necessary IMO. People will do it anyway, and personally I like to edit my texts, so I’d put some effort on make it work.
Should we keep a history of edits? Should we hash every edit to avoid abuse? Should we mark internally a twt as deleted, but keeping the replies?

I think that’s part of a more complete ‘thread’ extension, although I’d say it’s worth to agree on something reflecting the real usage in the wild, along with what people usually do on other platforms.

Hey everyone!

About the idea of improving the “thread” extension, what if we set aside March 2025 to gather proposals and thoughts from everyone? We could then vote on them at the end of the month to see if the change and migration are worth it.

The voting could include client maintainers (and maybe even users too). That way, we get a good mix of perspectives before taking a decision in a decent timelapse.

What do you think? If this sounds good, we can start agreeing on this. Let me know your thoughts!

@lyse@lyse.isobeef.org Gotcha. That makes sense. Doesn’t hurt the systems but definitely can break the thread.

@bmallred@staystrong.run Any edit automatically changes the twt hash, because the hash is built over the hash URL, message timestamp and message text. https://twtxt.dev/exts/twt-hash.html So, it is only a problem, if somebody replied to your original message with the old hash. The original message suddenly doesn’t exist anymore and the reply becomes detached, orphaned, whatever you wanna call it. Threading doesn’t break, though, if nobody replied to your message.

I have released new updates to the twtxt.el client.

• Markdown to Org mode (you need to install Pandoc).
  
• Centred column.
  
• Added new logo.
  
• Added text helper.
  

The new version I will try to finish the visual thread. You still can’t see the thread yet.

#emacs #twtxt #twtxtel

@andros@twtxt.andros.dev hmmm… pretty strange, isn’t it? replaying to threads worked perfectly, I’ve only had that problem trying to replay to a twt that was part of a thread.

As an example, this one is a Fork-Replay from Jenny. My next twt will be a replay to this exact twt but from twtxt-el as a test.
Then I’will file an issue if it doesn’t behave the way it’s supposed to. Cheers!

I don’t think so, at least the tests I did passed. If you’re pretty sure it’s a bug, please create an issue in the repository with the specific case and I’ll investigate it.
There are 2 buttons to make replicas, one makes a replica in the thread where the twt is located (this is the one that should be used the most, as it serves a thread), the other creates a replica to a specific twt.
I’ll let you know a bit about the status: I’m just now implementing the thread screen. There you can be sure where you are. It’s a bit confusing right now, sorry. I think the client is still in alpha. When I’ve finished what I’m doing, and the direct message system, I’ll freeze development and focus on creating more tests, looking for bugs and making small visual adjustments.

@eapl.me@eapl.me I like this idea. Another option would be to show a limited number of posts, with an option to see the omitted ones by user. Either way, I wonder how well that works with threading.

@lyse@lyse.isobeef.org The one in question is more like the javascript version for unwrapping errors when accessing methods.

 const value = some?.deeply?.nested?.object?.value

but for handling errors returned by methods. So if you wanted to chain a bunch of function calls together and if any error return immediately. It would be something like this:

b:= SomeAPIWithErrorsInAllCalls()
b.DoThing1() ?
b.DoThing2() ?

// Though its not in the threads I assume one could do like this to chain.
b.Chain1()?.Chain2()?.End()?

I am however infavor of having a sort of ternary ? in go.

PS. @prologic@twtxt.net for some reason this is eating my response without throwing an error :( I assume it has something to do with the CSRF. Can i not have multiple tabs open with yarn?

@prologic@twtxt.net @lyse@lyse.isobeef.org First, please leave me your comments on the repository! Even if it’s just to give your opinion on what shouldn’t be included. The more variety, the better.

Second, I’m going to try to do tests with Elliptic keys and base64. Thanks for the advice @eapl@eapl.me

Finally, I’d like to give my opinion. Secure direct messages are a feature that ActivityPub and Mastodon don’t have, to give an example. By including it as an extension, we’re already taking a significant leap forward from the competition. Does it make sense to include it in a public feed? In fact, we’re already doing that. When we reply to a user, mentioning them at the beginning of the message, it’s already a direct message. The message is within a thread, perhaps breaking the conversation. Direct messages would help isolate conversations between 2 users, as well as keeping a thread cleaner and maintaining privacy. I insist, it’s optional, it doesn’t break compatibility with any client and implementing it isn’t complex. If you don’t like it, you’re free to not use it. If you don’t have a public key, no one can send you direct messages.

@movq, @prologic@twtxt.net when navigating to a Yarn. If the head twt is missing then the whole thread is not accessible. It only returns an error. so i have no way to view any of the replies within the thread other than the end twt.

Thank you @prologic@twtxt.net , I’m pleased to be a little “thread” in the ball of yarn (Twtxt).

After I stripped off my clothes and turned around, I came to the conclusion that the plan to shower was cancelled at this moment. The faucet had broken right off and was laying in the tub. I noticed that the diameters of the hot and cold water pipes were surprisingly small, didn’t expect that. Since the pipes were broken flush with the wall, I couldn’t even determine if I had to remove the inner our outer threads, well, remains thereof, in order to attempt to repair this mess. Luckily, I was going to see a plumber mate at the christmas tree collection later anyway.

The first thing that came to mind when I woke up was that I didn’t catch the logical flaw in my dream: absolutely no water was coming out of the burst pipes. The whole scenario took place in summer, so the water couldn’t be frozen either.

although I agree that it helps, I don’t see completely correct to leave the nick definition to the source .txt. It could be wrong from the start or outdated with the time.

I’d rather prefer to get it from the mentioned .txt nick metadata (could be cached for performance).
So my vote would to make it mandatory to follow @<name url> but only using that name/nick if the URL doesn’t contain another nick.
A main advantage is that when the destination URL changes the nick, it’ll be automagically updated in the thread view (as happens with some other microblogging platforms, following the Jakob’s Law)

good morning yarn friends. we need a funny name for yarn posters. what’s something that fits the yarn theme…. i mean we quite literally have threads here. yarn threads. how epic is that. now us posters need a funny name too.

@doesnmppsflt@doesnm.p.psf.lt Not sure which bug you’re referring to. 🤔 (Did I forget?)

Those long IDs like (#113797927355322708) are simply part of that feed. Looks like the author just dumps ActivityPub IDs into twtxt. I think this used to work in the past, but the corresponding spec (https://twtxt.dev/exts/hash-tag.html) has been deprecated and jenny doesn’t support – actually, jenny never supported that.

jenny can only group threads by exactly one criterium (because it writes a Message-ID into the mail file) and that’s the regular twt hash. So, anything else, like people doing “#CoolTopic”, isn’t possible.

This is the first screenshot, a simple timeline I’m using to check the fields. Now I’m working on some details: avatar cache, relative dates, simple thread, etc. #emacs #twtxt

@prologic@twtxt.net this is epic… you’ve made a great platform!!! screw big tech we got literal threads here. X, The Everything App, wishes it had literal yarn threads smh my head. also twtxt is so cool like i love that yarn is a frontend for it but also its own thing. all plaintext… coolest shit ever

I like the cleaness and indiewebness of using just domains for handles/shorthands similar to blusky, but the situations with more users on the same domain and that people in the fediverse (threads too?) are already familiar with the syntax speaks for webfinger. And since we already got support for webfinger in both yarnd and timeline it makes sense to stick with it.

@prologic@twtxt.net yeah! If you remember I was curious about how people managed their stuff hosted on a Pubnix (this thread -> #z2ymlkq ) and I’ve just managed to join one …

Bluesky Passes Threads for Active Website Users, But Confronts ‘Scammers and Impersonators’
Bluesky now has more active website users than Threads in the U.S., according to a graph from the Financial Times. And though Threads still leads in app usage, “Prior to November 5 Threads had five times more daily active users in the U.S. than Bluesky… Now, Threads is only 1.5 times larger tha … ⌘ Read more

I share I did write up an algorithm for it at some point I think it is lost in a git comment someplace. I’ll put together a pseudo/go code this week.

Super simple:

Making a reply:

1. If yarn has one use that. (Maybe do collision check?)
   
2. Make hash of twt raw no truncation.
   
3. Check local cache for shortest without collision
   
   • in SQL: select len(subject) where head_full_hash like subject || '%'
     

Threading:

1. Get full hash of head twt
   
2. Search for twts
   
   • in SQL: head_full_hash like subject || '%' and created_on > head_timestamp
     

The assumption being replies will be for the most recent head. If replying to an older one it will use a longer hash.

I mean sure if i want to run it over on my tooth brush why not use something that is accessible everywhere like md5? crc32? It was chosen a long while back and the only benefit in changing now is “i cant find an implementation for x” when the down side is it breaks all existing threads. so…

Oh boy, I’m looking for trapezoidal (like ACME thread) screws and nuts in left hand form. The rods are already expensive, but nuts feel like a total ripoff. A hex nut for Tr20x2 being 30mm long and 30mm in “diameter” costs me 22 bucks! O_o Just a single one, made of regular steel. A meter of rod is 21€. The more common Tr20x4 hex nut is just 7€ and the rod 17€, but 4mm pitch is a bit much for a leadscrew for semi-precision work I reckon.

Well, maybe I just use metric threads. I will sleep on this.

I mean thread command but bash escapes quoted as command…

@doesnm@doesnm.p.psf.lt twt probably isn’t the best client I’m afraid. It doesn’t really cache twts by their key (hash) to display threads properly. Jenny however does 👌