🧮 USERS:1 FEEDS:2 TWTS:1337 ARCHIVED:87027 CACHE:2787 FOLLOWERS:22 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1336 ARCHIVED:87006 CACHE:2816 FOLLOWERS:22 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1335 ARCHIVED:86994 CACHE:2814 FOLLOWERS:22 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1334 ARCHIVED:86974 CACHE:2839 FOLLOWERS:22 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1333 ARCHIVED:86968 CACHE:2847 FOLLOWERS:22 FOLLOWING:14

In other words, why didn’t you all do the same that @movq@www.uninformativ.de did, and setup a completely different feed for this?

But Yarn does not like it: https://twtxt.net/twt/yoatzwa

🧮 USERS:1 FEEDS:2 TWTS:1332 ARCHIVED:86951 CACHE:2881 FOLLOWERS:22 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1331 ARCHIVED:86912 CACHE:2874 FOLLOWERS:22 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1330 ARCHIVED:86883 CACHE:2892 FOLLOWERS:22 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1329 ARCHIVED:86868 CACHE:2902 FOLLOWERS:22 FOLLOWING:14

@lyse@lyse.isobeef.org Kind of, but on the other hand: This twt right here refers to 3rvya6q and your feed, but your feed certainly does not include that particular twt (it comes from my feed).

But my proposal probably isn’t very helpful, either. We have this flat conversation model, so … this twt right here, what should it refer to? Your twt? My root twt? I don’t know.

@prologic@twtxt.net Don’t include this just yet. I need to think about this some more (or drop the idea).

🧮 USERS:1 FEEDS:2 TWTS:1328 ARCHIVED:86845 CACHE:2901 FOLLOWERS:22 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1327 ARCHIVED:86834 CACHE:2905 FOLLOWERS:22 FOLLOWING:14

@prologic@twtxt.net Not sure I’d attach any if clauses to this. My point is: Every time I see a hash, I’d like to have a hint as to where to find the corresponding twt.

@movq@www.uninformativ.de If we’re focusing on solving the “missing roots” problems. I would start to think about “client recommendations”. The first recommendation would be:

1. Replying to a Twt that has no initial Subject must itself have a Subject of the form (hash; url).
   

This way it’s a hint to fetching clients that follow B, but not A (in the case of no mentions) that the Subject/Root might (very likely) is in the feed url.

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.

🧮 USERS:1 FEEDS:2 TWTS:1326 ARCHIVED:86801 CACHE:2903 FOLLOWERS:22 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1325 ARCHIVED:86778 CACHE:2902 FOLLOWERS:22 FOLLOWING:14

Finally I propose that we increase the Twt Hash length from 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

And speaking of Twtxt (See: #xushlda, feeds should be treated as append-only. Your client(s) should be appending Twts to the bottom of the file. Edits should never modify the timestamp of the Twt being edited, nor should a Twt that was edited by deleted, unless you actually intended to delete it (but that’s more complicated as it’s very hard to control or tell clients what to do in a truely decentralised ecosystem for the deletion case). #Twtxt #Client #Recommendations

Just like we don’t write emails by hand anymore (See: #a3adoka), we don’t manually write Twts or update our twtxt.txt feeds. Instead, we use modern Twtxt clients that conform to the specifications at Twtxt.dev for a seamless, automated experience. #Twtxt #Twt #UserExperience

@bender@twtxt.net Hehe good sleuthing 🤣 I swear it was an edit ✍️ Haha 😂 yarnd now “sees” both every single time, where-as before it would just obliterate the old Twt, but remain in archive. Now you get to see both 😅 Not sure if that’s a good thing or not, but it certainly makes it much clearer how to write “code logic” for detecting edits and doing something more UX(y) about ‘em 🤔

🧮 USERS:1 FEEDS:2 TWTS:1324 ARCHIVED:86731 CACHE:2910 FOLLOWERS:22 FOLLOWING:14

I have a great idea for fixing the US economy. Get rid of all the nuclear weapons 🤣

🧮 USERS:1 FEEDS:2 TWTS:1323 ARCHIVED:86698 CACHE:2903 FOLLOWERS:22 FOLLOWING:14

$ bat https://twtxt.net/twt/edgwjcq | jq '.subject'
"(#yarnd)"

hahahahaha 🤣 Does your client allow you to do this or what? 🤔

@aelaraji@aelaraji.com I replied to this twtxt with https://twtxt.net/twt/yqrdx4q, and it created its own, totally unconnected.

Related Twt

@bender@twtxt.net allow me to try and explain over several Twts…

🧮 USERS:1 FEEDS:2 TWTS:1321 ARCHIVED:86594 CACHE:2833 FOLLOWERS:21 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1320 ARCHIVED:86540 CACHE:2803 FOLLOWERS:21 FOLLOWING:14

@bender@twtxt.net Wild. The twts look garbled. Like The Thing.

I’m thinking of building a hardened peering protocol for Yarn.social’s yarnd: pods establish cryptographic identities, exchange signed /info and /twt payloads with signature verification, ensuring authenticity, integrity, and spoof-proof identity validation across the distributed network.

🧮 USERS:1 FEEDS:2 TWTS:1319 ARCHIVED:86501 CACHE:2810 FOLLOWERS:21 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1317 ARCHIVED:86476 CACHE:2798 FOLLOWERS:20 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1316 ARCHIVED:86446 CACHE:2799 FOLLOWERS:20 FOLLOWING:14

@andros@twtxt.andros.dev Haha 🤣 We’ve explored this idea in the past and we decided that it’s actually a good idea to have an “append-only” feed for various reasons. We’ve also explored the idea of using Range requests, but opted instead to just archive/rotate our feeds periodically 😅 There really isn’t much point in having a feed in reverse chronological order, except (maybe?) so a human read view the new twts at the top of the file?! 🤣

See:

<textarea id="text" name="text" placeholder="Hi! 👋 Don't forget to post a Twt today!" rows="4" maxlength="576" required="true" aria-required="true"></textarea>

So, 576?

🧮 USERS:1 FEEDS:2 TWTS:1315 ARCHIVED:86386 CACHE:2781 FOLLOWERS:20 FOLLOWING:14

Hmmm there’s a bug somewhere in the way I’m ingesting archived feeds 🤔

sqlite> select * from twts where content like 'The web is such garbage these days%';
      hash = 37sjhla
  feed_url = https://twtxt.net/user/prologic/twtxt.txt/1
   content = The web is such garbage these days 😔 Or is it the garbage search engines? 🤔
   created = 2024-11-14T01:53:46Z
created_dt = 2024-11-14 01:53:46
   subject = #37sjhla
  mentions = []
      tags = []
     links = []
sqlite>

Btw @andros@twtxt.andros.dev ; The automated feed you put together for Hacker News… Does it at any point rewrite parts of the feed as it goes along? 🤔 I’ve had to unfollow it because I’ve found in practise it makes a twt, then seems to modify that same twt (observed by content manually) at least twice. This ends up becoming effectively an “Edit” and essentially duplicate (looking) posts 😢

🧮 USERS:1 FEEDS:2 TWTS:1314 ARCHIVED:86338 CACHE:2754 FOLLOWERS:20 FOLLOWING:14

@prologic@twtxt.net This shi_ is as fun as it is frustrating! 😆 the bot is poking at me from a different ASN now, Alibaba’s.

1. Short term solution: I’ve geo-locked my Timeline instance since I’m the only one using it (and I only do so for reading twts when I’m away from terminal).
   
2. Long term: I took a look at your Caddy WAF but couldn’t figure things out on my own; until then, I’ll be poking at Caddy-Defender, maybe throw in a Crowdsec for lols… #FUN

Some A hole has been trying to pull every single Twtxt feed that existed/still exists since forever. How do I know? Welp’ They’ve been querying my Timeline™ instance for all of it, every single twtxt file and twt Hash they can find. 😆🤦 It must have been going on for days and I have just noticed… + it’s all coming from the same ASN AS136907 HWCLOUDS-AS-AP HUAWEI CLOUDS

Thank you Huawei for the DDos you sons of Glitches!!!

🧮 USERS:1 FEEDS:2 TWTS:1311 ARCHIVED:86261 CACHE:2761 FOLLOWERS:18 FOLLOWING:14

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

🧮 USERS:1 FEEDS:2 TWTS:1310 ARCHIVED:86237 CACHE:2746 FOLLOWERS:18 FOLLOWING:14

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

jenny really isn’t well equipped to handle edits of my own twts.

For example, in 2021, this change got introduced:

https://www.uninformativ.de/git/jenny/commit/6b5b25a542c2dd46c002ec5a422137275febc5a1.html

This means that jenny will always ignore my own edits unless I also manually edit its internal “json database”. Annoying.

That change was requested by a user who had the habit of deleting twts or moving them to another mailbox or something. I think that person is long gone and I might revert that change. 🤔