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

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

@movq@www.uninformativ.de ok, I have included a small modification in the documentation to allow you to reply in your own thread: https://texudus.readthedocs.io/en/latest/
You can see my reply: https://andros.dev/texudus.txt
Don’t delete anything and give me time to make my modifications to the client.

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

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

just for the record I didn’t say I was leaving the twtxt ‘community’ (did I?) but than I have other priorities to focus on in the following months. Please don’t be condescending, is not cool.

Development of Timeline (PHP client) has been stale for some reasons, a few of them in my side, so I think it won’t be updated to the new thread model, at least pretty soon.
So is not that I’ll stop using twtxt, just the client I use won’t be compatible with the new model in July.

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://yarn.girlonthemoon.xyz/search?q=%23123467">#123467</a>) hello foo bar

you would have

(<a href="https://yarn.girlonthemoon.xyz/search?q=%23123467">#123467</a> http://foo.com/tw.txt) hello foo bar

or maybe even:

(<a href="https://yarn.girlonthemoon.xyz/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.

@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” 🤣

@bender@twtxt.net Nah it’s there but it’s a reply to a thread that isn’t found here hmmm 🤔

@abucci@anthony.buc.ci Haha you’ll have to forgive me, this thread is over a week old now and I’m a bit lost now 🤣 even though I can now see the entire thread, what are we saying was messed up and is garbled? 🤔

hehe, just catching up on this thread! I’ve replied in another that using periods/dots sounds good to me as it’s usual in domains, but perhaps some agreement would be needed. For now I think any character is valid as long as it is not a space.
For example we are using this for PHP twtxt.php#L153

I open a discussion thread: why didn’t the registers work? Will they work later?
#twtxt

After reading you, @eapl.me@eapl.me, I’ll tell you my point of view.
In my opinion, a feed does not have to be equivalent to a timeline. A timeline is a representation of the feed adapted to a user. You may not be interested in seeing other people’s threads or DMs. But perhaps they are interested in seeing mentions or DMs directed at them. It is important not to fall into the trap. With that clarification…
I insist, this is my point of view, it is not an absolute truth: I don’t think extensions should be respectful of customers who are no longer maintained.
We cannot have a system that is simple, backwards compatible and extensible all at the same time. We have to give up some of the 3 points. I would not like to give up simplicity because it will then make it harder to maintain the customers who do stay. Therefore, I think it is better to give up backwards compatibility and play with new formulas in the extensions. I don’t think it’s a good idea to make a hash keep so much load: a hashtag, a thread and also a DM.

@bender@twtxt.net Hehe, thanks for fixing this (was) broken thread 🧵 Haha 🤣

Am I the only one that’s confused by the discussions, and then the voting we had on the whole threading model? 🤔 I’m not even sure what I voted for, but I know it wasn’t the one that won haha 🤣 (which I’m still very much against for based on an intuition, experience and lots of code writing lately).

@prologic@twtxt.net Shit like what? References/threads? 😅

Timeline of Evolution of Twtxt/Yarn.social:

• 2016 – Twtxt created by John Downey: plain text + HTTP = minimalist microblogging
  
• 2017–2019 – Community builds CLI tools, but adoption remains niche
  
• 2020 – Yarn.social launched by @prologic@twtxt.net with federation, threading, UI
  
• 2021–2023 – Pods sync, user mentions, blocking, search, and media support added
  
• 2024+ – Yarn.social becomes the reference Twtxt platform, with active federated pods

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

Video

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.

Video

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