First of all, I’m still using it – and so are a couple of other people. Not a lot, it’s very niche, but from time to time someone new shows up. On the other hand, the original twtxt community appears to have died. I don’t really see anyone who was around before 2020 still post new twts. I’m not entirely sure about the reasons and don’t want to speculate about it.
I’ve changed my opinion on a couple of things since the last blog post.
As for twtxt “registries”, I now think this concept has failed, especially when you consider that there’s not one central registry. So, the problem simply shifts. Do I have to query multiple registries all the time to see if someone mentioned me? How do I know which registries exist, do we need a meta registry?
Instead, grepping your
access.log for special user agents is much
better. Or running special server-side software that tracks who accessed
your feed. It’s the general idea of doing a “pingback” (obviously, this
only works if the user wishes to disclose their identity). That, of
course, means you cannot really participate in the twtxt community after
all by hosting a twtxt feed on GitHub or something like that. You really
either need an actual server with access to your
access.log or you
need to use a special twtxt server implementation (admittedly, there is
only one implementation right now that I know of, namely that of
twtxt.net, see below). Also, Gopher doesn’t work well, either – because
it has no concept of user agents or even request headers.
Yes, you can always send me an e-mail and tell me that you follow me. But, really, we can just have a conversation via e-mail then and skip twtxt. This also doesn’t scale.
James Mills’ twtxt.net – which is where most development around twtxt happens these days – is currently in the process of being rebranded to Yarn.social. There was just too much confusion about what “twtxt” is. Is it James’ software? Or buckket’s original reference client? Or the protocol itself? On top of that, Yarn.social made a couple of extensions which the original twtxt clients know nothing about.
Threading is probably the most important extension. It takes twtxt from being basically a radically simplified RSS feed to an actual “social media platform”. Yes, this matters after all. I want to be able to reply to people. It has to be a two-way kind of communication. If it’s restricted to one-way (or if it’s too complicated to do two-way stuff), then we can just all run blogs and watch our RSS feeds – or hop on IRC instead. I’m probably being a bit too dramatic here, but you get the basic idea.
Support for threading is problematic, though. None of the old clients understand it. The current twtxt community makes extensive use of them, so … we’re basically starting from scratch with regards to clients. Threading also complicates the clients: The old clients could be implemented by looping over a list of feeds (the ones that you follow), fetch each feed, display new items. Simple. Now, you have to build a tree of twts and display that tree in a meaningful way. This is much more involved. Doable, of course, but more complicated.
(The current threading model is somewhat fragile, as it relies on the URL that a feed is available under. For example, if one person follows my feed via https and another one via Gopher, then threading will break. This issue is being addressed, though.)
I threw away my previous client and rewrote it from scratch in Python 3:
It still just stores the twts in a Maildir, which you then have to view using a mail client. jenny comes with a very short example configuration file for mutt, so it’s not that hard to use. You don’t need any kind of preexisting mutt setup.
I hope that there will be more clients that support threading. twtxt is still a minimalistic thing and hasn’t really lost much of that appeal. It is still very much decentralised and you are not forced to use someone else’s server. You can run it on your own one with little effort. You can hack your own client in a weekend or maybe two. It’s really neat.