@bender@twtxt.net Sadly my earlier Twt back in ~2020 is now gone from at least this pod’s cache 🤣 – It might still exist in other pods though? 🤔 It does! https://txt.sour.is/twt/o6dsrga

Happy 1st Twtxt~iversary to me … I guess. It feels like it was 5 years since my first twt 😅

I’m also thinking that some kind of tag might be needed to automatically hide twts from unknown extensions. For example our client doesn’t support DMs and always shows the !<nick url><encrypted_message> syntax which is meaningless.

@bender@twtxt.net Yes! I deleted those repeated twts because it was poor execution by my client. They are currently not present in my feed.
Maybe it would be interesting to check if any twt has disappeared?

Oops, I think this pod (twtxt.net) just sync ~1k missing root twts with god only knows which peers 🤦‍♂️ I forgot a couple of important key things:

• Only coverage with a subset of peers
  
• Only converge with trusted peers
  

Fuck me 🤣 Ooops. Sorry!

@andros@twtxt.andros.dev can you see the screenshot on my first twtxt? Here: https://twtxt.net/twt/mrccg4q

Good quote: «Corrects in private and congratulates in public».
Or…: «Corrects in direct message and congratulates in twt» 😜

I was trying to optimize the SQL query used for the Compact FrontPage (anonymous view for Discovery when the Admin/Operator chooses “one twt per feed”).

@thecanine@twtxt.net Did you see my revelation earlier today? 🤔

Hmm, Yarnd is duplicating the rendering of /twt/5jlfuua. That’s quite odd.

Anyway. this was a good use for search btw. I couldn’t find my Twt, so I just quickly searched for it, snap, bingo I found it in a snap! 🫰

@prologic@twtxt.net I’m not sure if that’s an intended behaviour but twtxt.net’s home page doesn’t load more than 13 twts, no more pagination/infinite scrolling…

Page 1/1 of 13 Twts

See:

Image

Doesn’t look like it Hmmm

sqlite> select * from twts where content LIKE '%Linux installation%';
    hash = znf6csa
feed_url = https://www.uninformativ.de/twtxt.txt
 content = I wonder if my current Linux installation will actually make it to 20 years:

    $ head -n 1 /var/log/pacman.log
    [2011-07-07 11:19] installed filesystem (2011.04-1)

It’s not toooo far into the future.

It would be crazy … 20 years without reinstalling once … phew. 🥴
 created = 2025-04-07T19:59:51Z
 subject = (#znf6csa)
mentions = []
    tags = []
   links = []

@movq@www.uninformativ.de Apparently you wrote it :D The hash doesn’t lie? 🤣 https://twtxt.net/twt/znf6csa

@prologic@twtxt.net What happened here – did I edit my twt or is this hash wrong? 🥴

guys help how do i unmute a twt i accidentally hit the wrong button

Is it just me or is there a display bug for “Yarn”(s) that are duplicating the root twt? 🤔

I need to get Peering working again on this branch! That will drag in many Twts Twts I now no longer have 😭

i can see your twts here: https://watcher.sour.is/?uri=https://eapl.me/tw.txt

@david@collantes.us.. i see this one but it says its dead. https://watcher.sour.is/?uri=https://ferengi.one/twtxt.txt

@andros@twtxt.andros.dev sha256 hash of twt in json. Look at converter script

thanks for sharing @xuu@txt.sour.is!

Checking for example https://watcher.sour.is/api/plain/twt or https://registry.twtxt.org/api/plain/tweets, I don’t know whether this syntax is being used by clients or by people. Is it integrated on Yarn in any way? Genuinely asking to know more about it.

If I might throw a quick thought to those working on the registries, it would be nice to have an endpoint with a valid twtxt output (perhaps cached or dumped to a static file) which a client could point to, helping to discover it’s content in a way which is compatible with the twtxt spec.

Taking the first twt I found in https://watcher.sour.is/api/plain/twt as an example:
reddit_world_news https://feeds.twtxt.net/Reddit_World_News/twtxt.txt 2025-03-28T00:29:25Z **China bans US logs. 3 billion dollar[...])
it would be something like
TIME <@NICK URL> TWT
2025-03-28T00:29:25Z <@reddit_world_news https://feeds.twtxt.net/Reddit_World_News/twtxt.txt> **China bans US logs. 3 billion dollar[...])

That way you could watch the latest twts with your client, something similar to what we find on Mastodon: https://mastodon.online/public/local

Some support from the clients to separate these ‘discovery’ content, from your following timeline might be required. 🤔

@eapl.me@eapl.me I am currently working on Implementing a registry that is also a crawler. It finds any feeds that are mentioned or in the follows header.

https://watcher.sour.is/api/plain/twt

https://watcher.sour.is/api/plain/users

I think @prologic@twtxt.net is also working on one.

somehow I forgot that existed.

Perhaps it was its mention of being a demo implementation here:
https://twtxt.readthedocs.io/en/latest/user/registry.html#registry
So I though it wasn’t really active.

Anyway, I think that’s a good idea.

Is there something similar available on Yarn? Sorry for for asking if that was mentioned recently.

I think that the clients may help you to submit your URL to these directories, and also to get a view of the twts in them.

@eapl.me@eapl.me this “directory” is actually named registry. You can see users at https://registry.twtxt.org/api/plain/users and his twts at https://registry.twtxt.org/api/plain/tweets

thanks andros!

instead of adding the new twt at the end of the feed, do it at the beginning
The PHP client did that originally, although I didn’t see a real benefit if you use… a client.
It could help if you read the .txt file through a browser or something. Also, not many clients are prepared to cut the request, and you can’t rely on the file being organized that way, so finally we dropped that feature.

@bender@twtxt.net I taught the whole ecosystem 😁
@prologic@twtxt.net @eapl.me@eapl.me The question I was asked the most was: How do I discover people?
Someone came up with a fantastic idea, instead of adding the new twt at the end of the feed, do it at the beginning. So you can paginate by cutting the request every few lines.

neat! my watcher is currently sitting at about 75 MB following over 1500 feeds. only about 200 are currently somewhat active.

-rw-r--r--. 1 xuu  xuu   69M Mar 25 20:46 twt.db
-rw-r--r--. 1 xuu  xuu   32K Mar 25 21:34 twt.db-shm
-rw-r--r--. 1 xuu  xuu  5.6M Mar 25 21:34 twt.db-wal

sqlite> select state, count(*) n from feeds group by 1;
hot|7
warm|8
cold|183
frozen|743
permanantly-dead|857

I have applied your comments, and I tried to add you as an editor but couldn’t find your email address. Please request editing access if you wish.

Also, could you elaborate on how you envision migrating with a script? You mean that the client of the file owner could massively update URLs in old twts ?

@prologic@twtxt.net We can’t agree on this idea because that makes things even more complicated than it already is today. The beauty of twtxt is, you put one file on your server, done. One. Not five million. Granted, there might be archive feeds, so it might be already a bit more, but still faaaaaaar less than one file per message.

Also, you would need to host not your own hash files, but everybody else’s as well you follow. Otherwise, what is that supposed to achieve? If people are already following my feed, they know what hashes I have, so this is to no use of them (unless they want to look up a message from an archive feed and don’t process them). But the far more common scenario is that an unknown hash originates from a feed that they have not subscribed to.

Additionally, yarnd’s URL schema would then also break, because https://twtxt.net/twt/<hash> now becomes https://twtxt.net/user/prologic/<hash>, https://twtxt.net/user/bender/<hash> and so on. To me, that looks like you would only get hashes if they belonged to this particular user. Of course, you could define rules that if there is a /user/ part in the path, then use a different URL, but this complicates things even more.

Sorry, I don’t like that idea.

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.

it seems to be confused with the subject right next to it.. it works better at the end of the twt string.
Yarn won’t display anything. but the parser does add it to the AST in a way that you can parse it out using twt.Attrs().Get("lang")

https://git.mills.io/yarnsocial/go-lextwt/src/branch/main/ast.go#L1270-L1272

https://git.mills.io/yarnsocial/go-types/src/branch/main/twt.go#L473-L478

lang=en @xuu@txt.sour.is gotcha!
From that PR #17 I think it was reverted? We could discuss about metadata later this month, as it seems that I’m the only person using it.

I’ve added a [lang=en] to this twt to see current yarn behaviour.

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.

looks good to me!

About alice’s hash, using SHA256, I get 96473b4f or 96473B4F for the last 8 characters. I’ll add it as an implementation example.
The idea of including it besides the follow URL is to avoid calculating it every time we load the file (assuming the client did that correctly), and helps to track replies across the file with a simple search.

Also, watching your example I’m thinking now that instead of {url=96473B4F,id=1} which is ambiguous of which URL we are referring to, it could be something like:
{reply_to=[URL_HASH]_[TWT_ID]} / {reply_to=96473B4F_1}
That way, the ‘full twt ID’ could be 96473B4F_1.

True. Though if the idea turns out to be better.. then community will adopt it.

if you look at the subject for that twt you will see that it uses the extended hash format to include a URL address.

@andros@twtxt.andros.dev Oh, this system has an edit button so I can just update the twt as needed. It’s a custom implementation so just kind of through it in when I was building it out.

@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 was on the hunt for new twts and found what I was looking for. Welcome to my timeline:
@javivf@adn.org.es @lafe@tilde.club @melyanna@tilde.club @nff@www.noizhardware.com @shreyan@twtxt.net

@andros@twtxt.andros.dev I believe you have just reproduced the bug… it looks like you’ve replayed to a twt but the hash is wrong. I can see the hash here from Jenny, but it doesn’t look like it corresponds to any{twt,thing}. if you check it out on any yarn instance it won’t look like a replay.

My hypothesis about that thing breaking my twts is that it might have something to do with the parenthesis surrounding the root twt hash in the replay twt-A when I replay to it with fork-twt-B; I imagine elisp interpreting those as a s-expression thus breaking the generation precess of hash (#twt-A) before prepending it to for-twt-B … but then I’m too ignorant to figure out how to test my theory (heck I couldn’t even recalculate the hashes myself correctly in bash xD). I’ll keep trying tho.

@andros@twtxt.andros.dev yes, that usually happens when twts get edited and we just made a gentlemen agreement to avoid edits as much as possible (at least for the time being). But the thing is, That is not what’s happening with my broken twts’ hashes. Since I’ve bee mostly replaying to my own twts as a test and I know for sure that I haven’t edited any. (I usually fork-replay instead of edit a twt when needed)

@prologic@twtxt.net Agreed! But clients can hallucinate and generate wrong hashes aka Lies 🤣 Also, If you chheck your own twt on twtxt.net, it looks like a root twt instead of a replay.

@andros@twtxt.andros.dev Here’s that twtxt-el test replay to my last twt! let’s see how it goes.

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

@prologic@twtxt.net Are you sure? xD … it was supposed to be a replay to another twt, but the twt hash is wrong (I think).

I really like the concept of “twt”. It’s the perfect blend of txt and twtxt. An abbreviated form. Even though it’s the name given to posts, I personally find it very nice.
#twtxt

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.

@andros@twtxt.andros.dev is it me or twtxt-el generates a wrong twt hash when I use the [ ↳ Reply to twt ] button?

among these options, 3

Although I like it more “twt”, without the dot and with a t at the end