@prologic@twtxt.net I can see the issues mentioned, but I think some can be fixed.

1. The current hash relies on a url field too, by specification, it will use the first # url = <URL> in the feed’s metadata if present, that too can be different from the fetching source, if that field changes it would break the existing hashes too, a better solution would be to use a non-URL key like # feed_id = <UNIQUE_RANDOM_STRING> with the url as fallback.

2. We can prevent duplications if the reference uses that same url field too or the client “collapse” any reference of all the urls defined in the metadata.

3. I agree that hashing based on content is good, but we still use the URL as part of the hashing, which is just a field in the feed, easily replicable by a bot, also noting that edits can also break the hash, for this issue an alternative solution (E.g. a private key not included in the feed) should be considered.

4. For offline reading the source would be downloaded already, the fetching of non followed feeds would fill the gap in the same way mentions does, maybe I’m missing some context on this one.

5. To prevent collisions there was a discussion on extending the hash (forgot if that was already fixed or not), but without a fallback that would break existing clients too, we should think of a parallel format that maintains current implementations unchanged, we are already backward compatible with the original that don’t use threads at all, a mention style format for that could be even more user-friendly for those clients.

We should also keep in mind that the current mention format is already location based (@<example https://example.com/twtxt.txt>) so I’m not that worried about threads working the same way.

Hope to see some other thought about this matter. 🤓

@thecanine@twtxt.net Thanks!

Looking forward to it!✌️

@alexonit@twtxt.alessandrocutolo.it @lyse@lyse.isobeef.org i really don’t understand why this was not the solution in the first place, given how simple twtxt is (mean to be), a reply should be as simple as #<https://example.com/twtxt.txt#2025-09-22T06:45Z> with the timestamp in an anchor link. the need for a mention is avoided like this as well since it’s already linking to the replied-to feed!

🐀💭 i should just implement it into bbycll and force it into existence

@kat@yarn.girlonthemoon.xyz Mine shows 1/1 of 14 Twts 😆 I think this is a bug 🤯

@itsericwoodward@itsericwoodward.com any news about this? I am, at the very least, curious!

@bender@twtxt.net hehe

@alexonit@twtxt.alessandrocutolo.it I took it down mostly because of continued abuse and spam:l. I intend to fix I and improve the drive and its sister at Summer point 🤞

@alexonit@twtxt.alessandrocutolo.it thank you and welcome back to Yarn! The somewhat plushie-like look is intentional, so I’m glad it was noticed.

Only have 2 sizes of him in this pose, as well as most other sitting poses, but if there’s ever a sitting pose, shared by more than 2 of them, I’ll be sure to make a matrioska edit.

@lyse@lyse.isobeef.org Yeah, the format is just an idea of how it could work.

The order of SOURCE > POST does make more sense indeed.

@prologic@twtxt.net thanks, I already follow @important_dev_news@n8n.andros.dev too.

BTW, the feed on https://feeds.twtxt.net/ seem down? It says it’s in maintenance.

@alexonit@twtxt.alessandrocutolo.it Love this 😍

@alexonit@twtxt.alessandrocutolo.it Yeah same 🤣 There’s also this @news-minimalist@feeds.twtxt.net feed that shows up the most important shit™ anyway (when/if that happens).

@alexonit@twtxt.alessandrocutolo.it Personally, I find the reversed order of URL first and then timestamp more natural to reference something. Granted, URL last would be kinda consistent with the mention format. However, the timestamp doesn’t act as a link text or display text like in a mention, so, it’s some different in my opinion. But yeah.

@prologic@twtxt.net Me neither, if there’s any important news others usually tell me anyway. 😌

@bender@twtxt.net Seriously I have zero clue 🤣 I don’t read or watch any news so I have no idea 🤦‍♂️

@bender@twtxt.net <3

The big QR code canine, has been one of my favourites - because even after a few months, I still find the pose really cute. Always thought a chibi version is a necessary addition and now I finally drew it.

@prologic@twtxt.net I know you were away, but were you under a rock?! 😅

@prologic@twtxt.net Yes, no doubt. There’s always something somewhere.

@lyse@lyse.isobeef.org Some stuff is actually more reliable, that’s true. It’s also waaaaaaaaaaay more expensive, though … :-)

I called it a day, yes. \o/

@movq@www.uninformativ.de But it’s so reliable and they have all the experts, they know what they’re doing! And don’t forget, it’s way cheaper! Just think of the 34 cents saved every year on paper, the business dude calculated!

Enjoy your weekend! (I hope, you just called it a day and don’t have to drive to the office or silly shenanigans like that.)

@lyse@lyse.isobeef.org Yep! Super fast and efficient! 😃

@kiwu@twtxt.net awwww! 😢

long month

@prologic@twtxt.net welcome back! 🥳🥳🥳

@movq@www.uninformativ.de That’s transparency hardware support!

While working on the Discoverability for my twtxt client (it runs client-side) I found out that Chrome doesn’t allow to set a custom user agent. 🙃

I thought it was a general thing for browsers, but it that was actually allowed in a newer specification, yet it’s still not implemented in Chrome, it does work in Firefox though.

@zvava@twtxt.net In tt, I recognize umlauts in nicks, but they cannot include whitespace, @, !, #, (, ), [, ], <, >, " (but ' is okay). Whitespace also acts as a separator between nick and URL. @<Hello World http://example.com> ends up exactly like that and is not a mention.

@zvava@twtxt.net I kinda fixed the issue by not stripping the timestamp at all.

Seems that more feeds work correctly this way. 🤔

@thecanine@twtxt.net With a progressive web app (PWA) you can have a native like experience without having to trouble yourself with building a second project that act as a client.

You can even “wrap” it into a packaged installation and publish it on stores, theres even projects to streamline it https://www.pwabuilder.com/.

@zvava@twtxt.net @lyse@lyse.isobeef.org I also think a location based reference might be better.

A thread is a single post of a single feed as a root, but the hash has the drawback of not referencing the source, in a distributed network like twtxt it might leave some people out of the whole conversation.

I suggest a simpler format, something like: (#<TIMESTAMP URL>)

This solves three issues:

• Easier referencing: no need to generate a hash, just copy the timestamp and url, it’s also simpler to implement in a client without the rish of collisions when putting things together
  
• Fetchable source: you can find the source within the reference and construct the thread from there
  
• Allow editing: If a post is modified the hash becomes invalid since it depends on [ timestamp, url, content ]

@zvava@twtxt.net @lyse@lyse.isobeef.org @movq@www.uninformativ.de I also was wondering how to handle this.

Currently my regex is like this: /@<((?<nick>[^\s]+)\s)?(?<url>\w+:\/\/[^>]+)>/g

It takes everything until the space and the nick is optional.

Hello everyone! 👋

After a long while away, I’m back on twtxt with this new feed.

Some of you might remember me as justamoment@twtxt.net, that was a test account I made for trying things out, but I ended up keeping it more than planned.

I also tried other social platforms in search of a place that felt right for me.

In the end twtxt was the one that ticked all of my boxes:

• Slow social: it act more like a feed reader and I really appreciate that there’s no flood of content that I can’t keep up with.
  
• No server needed: I absolutely love to have total control over my content, I tend to avoid having moving parts that might break, plus you can put your feed under version control and it’s all backed up.
  
• Ownership: I can put my feed anywhere I want and nobody can decide if I can access it or not.
  
• For hackers: a single .txt file allows me to join a community, how cool is that!
  

This is why I decided to build my own twtxt client, one that allows you to decide how the feed is presented on your “instance”.

It’s still in the making but I’ll try to share a bit of it once I defined how things should work.

Coincidentally, I discovered that @itsericwoodward@itsericwoodward.com and @zvava@twtxt.net were also building a twtxt client, seems like twtxt is set to grow!

Apologies if I’ve been spamming anyone out there in twtxt-land today.

I’ve been working on a couple of twtxt-related projects, and one of them is a reader (tentatively called twtstrm) written in JS. I used dummy data for the first few stages of development, but now I’m at the point where I need some real data, and that meant hitting up my actual following list.

Of course, it didn’t help that I had a typo in my If-Modified-Since headers, but all that has since been resolved.

Anyways, if I accidentally spammed you with requests today, I am sorry, and it shouldn’t happen anymore.

We thank you for your patience, and apologize for the inconvenience.

Apologies if I’ve been spamming anyone out there in twtxt-land today.

I’ve been working on a couple of twtxt-related projects, and one of them is a reader (tentatively called twtstrm) written in JS. I used dummy data for the first few stages of development, but now I’m at the point where I need some real data, and that meant hitting up my actual following list.

Of course, it didn’t help that I had a typo in my If-Modified-Since headers, but all that has since been resolved.

Anyways, if I accidentally spammed you with requests today, I am sorry, and it shouldn’t happen anymore.

We thank you for your patience, and apologize for the inconvenience.

@bender@twtxt.net Soon soon🤣

@prologic@twtxt.net ah! Well, keeping fingers crossed for you and family on that RV, for sure! 🤞🏻

@bender@twtxt.net I wish 🤣 Nah work on-site thingy😆

@prologic@twtxt.net ah, I was wondering! Hoping you are having a good time, mate! Christening the new RV? :-)

@movq@www.uninformativ.de Mit Code. Aber ich habe da echt so einen knoten im Kopf. Die Beispiele in meiner Filterblase helfen mir auch nicht.
Dann kommt das eben in die Kiste mit den unfertigen Dingen.

I know it doesn’t need to be said, but “Texudus” is not twtxt. It is an attempt to create a, arguably, “better way™️”. 🤭

@zvava@twtxt.net ah, yes, that’s the only Texudus feed. It also seems it is a one way only feed.

@bender@twtxt.net https://andros.dev/texudus.txt, its url doesn’t correspond to the feed either

@zvava@twtxt.net which Texodus feed? That I know of, there is only one, or am I wrong?

@lyse@lyse.isobeef.org @movq@www.uninformativ.de bbycll’s nickname regex is /^([-_\p{N}\p{L}])+$/iu because i don’t like how english-centric only allowing ascii letters/numbers is though this only applies to local users as of now, currently all nicknames are tolerated when parsing remote feeds and i just do mentions how yarn does (just the feed url)

in the wild, i’ve noticed a texedus feed with spaces in the nick (where its spec explicitly disallows whitespace in the nick) and feeds with other symbols in the nick too. honestly, i think we should just tolerate arbitrary nicknames for sake of user expression (while stripping or converting unreasonable characters) and just leave them out of mentions

@zvava@twtxt.net @movq@www.uninformativ.de I’m not entirely sure about the spaces, but maybe they were omitted to simplify parsing of mentions in the form of @<nick url>. If the next token after the @<nick does not look like a URL, it’s not a mention but regular text. This is just wild guessing, though.

Looking at the regex and tests in the original twtxt reference implementation seems to confirm that theory in the sense as it relies on whitespace as the delimiter:

Another thing about nicks is that the original twtxt reference implementation converts nicks to all lowercase:

You probably know this already, the original twtxt file format specification can be found here: https://twtxt.readthedocs.io/en/latest/user/twtxtfile.html

As for extensions, I don’t know of anything outside of twtxt.dev that has actually been (partially) implemented. However, there is also the issue tracker of the official reference implementation. You might wanna dig through that. For example, there is an alternative suggestions of multiline messages: https://github.com/buckket/twtxt/issues/157

@arne@uplegger.eu Hm, noch nie gemacht. 🤔 Machst du das von Hand oder mit Code?

@zvava@twtxt.net Good question. This is the spec, I think:

https://twtxt.dev/exts/metadata.html#nick

It doesn’t say much. 🤔

In the wild, I’ve only seen “traditional” nick names, i.e. ASCII 0x21 thru 0x7E.

My client removes anything but r'[a-zA-Z0-9]' from nick names.

is there consensus on what characters should(n’t) be allowed in nicks? i remember reading somewhere whitespace should not be allowed, but i don’t see it in the spec on twtxt.dev — in fact, are there any other resources on twtxt extensions outside of twtxt.dev?

@kat@yarn.girlonthemoon.xyz, see this one, regarding “Anubis” (which I believe you use, right?): https://github.com/eternal-flame-AD/pow-buster