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

@prologic@twtxt.net Of course you don’t notice it when yarnd only shows at most the last n messages of a feed. As an example, check out mckinley’s message from 2023-01-09T22:42:37Z. It has “[Scheduled][Scheduled][Scheduled]“… in it. This text in square brackets is repeated numerous times. If you search his feed for closing square bracket followed by an opening square bracket (][) you will find a bunch more of these. It goes without question he never typed that in his feed. My client saves each twt hash I’ve explicitly marked read. A few days ago, I got plenty of apparently years old, yet suddenly unread messages. Each and every single one of them containing this repeated bracketed text thing. The only conclusion is that something messed up the feed again.

@eapl.me@eapl.me Yeah, you need some kind of storage for that. But chances are that there’s already a cache in place. Ideally, the client remembers etags or last modified timestamps in order to reduce unnecessary network traffic when fetching feeds over HTTP(S).

A newsreader without read flags would be totally useless to me. But I also do not subscribe to fire hose feeds, so maybe that’s a different story with these. I don’t know.

To me, filtering read messages out and only showing new messages is the obvious solution. No need for notifications in my opinion.

There are different approaches with read flags. Personally, I like to explicitly mark messages read or unread. This way, I can think about something and easily come back later to reply. Of course, marking messages read could also happen automatically. All decent mail clients I’ve used in my life offered even more advanced features, like delayed automatic marking.

All I can say is that I’m super happy with that for years. It works absolutely great for me. The only downside is that I see heaps of new, despite years old messages when a bug causes a feed to be incorrectly updated (https://twtxt.net/twt/tnsuifa). ;-)

Definitely something going on with replies. This one was replying to the wrong twt and even when I got clever and pasted the right hash it didn’t work.

@prologic@twtxt.net the code block is the cause of https://txt.sour.is/twt/zn2kg7q

and the second? i get POST errors when i try to submit the webform.

@mckinley@twtxt.net And there is the bracketed text duplication bug again… Actually with lots of twts. Did you edit a twt? Do you remember? /cc @prologic@twtxt.net

Well, that’s another bug: The search https://twtxt.net/search?q=%22LOOOOL%2C+great+programming+tutorial+music%22 yields the wrong hash. It should have been poyndha instead.

alert the twt police!!

I have a paper deadline coming up, so will everyone please stop writing twts for the next 48 hours, thanks.

@andros@twtxt.andros.dev Sweeeeet! Just gave it a try, you’ve done a wonderful work 🫡 I wanted to replay from there but couldn’t go past the first page of the feed. It kept freezing on me and complaining about some bad Url (as mentioned on the test twt), so I’ll have to dig through my follow list and see where I effed up this time. 😅

Here’s a twt from @andros@twtxt.andros.dev ’s new version of Twtxt-el 🥳 It feels WAaaaaY better! although it freezes on me as soon as I navigate to the next page complaining about some bad url, but the chronological sorting of the feed as well as the navigation buttons (links?) are a great addition. Looking forward to the next update already! 😁 🥳🥳🥳

Ok, it’s really spam account: https://twtxt.net/twt/xu3u7zq . Damn spammers. Can you delete this?

https://twtxt.net/twt/nbl4xfq

@lyse@lyse.isobeef.org @prologic@twtxt.net 😆 There was something weird going on with my #Timeline instance, the text input box was visible even though I was logged out and I was able to twt from it … It has to do with cache because it wouldn’t disappear unless I whip my website’s cache from the browser.

Poke @sorenpeter@darch.dk and @eapl.me@eapl.me I have no Idea how to reproduce this.

It seems related to us poor single user pods not getting the trust to share twts.. which it seems to still untrust on restart for me.

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

Or using the same twt hash method, but only for the URL, to generate the nick, if it doesn’t exist, like so, @5vxo4ia@twtxt.net

Lol why you and bender twts are rendered but my with simular content are skipp3d? Upd: nevermind, i’m dumb, my twt are created in future because i type date -iS and replaces +03:00 with Z: https://twtxt.net/twt/yctmi7a

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

I’m still making progress with the Emacs client. I’m proud to say that the code that is responsible for reading the feeds is almost finished, including: Twt Hash Extension, Twt Subject Extension, Multiline Extension and Metadata Extension. I’m fine-tuning some tests and will soon do the first buffer that displays the twts.