/~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~\

Title: Twtxt Changes
Date: April 30, 2025
Written On: VIM on 2009 MacBook Pro (Mac OS 10.6.8)

|~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~|

  While I don't use Twtxt anymore, I keep an eye on the
community there since it's mostly in my circle of offline-
first and permacomputing interests. I'm not cut out for
social media anymore, but I'd rather be able to recommend
a better alternative to ActivityPub for people who like it,
and Twtxt checks all my boxes...kinda. At least, it looks
like it'll essentially be the /original/ Twtxt[0] v1 that
ticks those boxes.

  The v1 specification by Buckket is very simple, and
mostly focused around the main file just being a feed. Then
there's the more modern Twtxt spec led by James Mills[1],
which has a number of quality of life extensions that make
things more complex, but give users things that clients can
take advantage of. Things like threading, created via a
unique hash made from the original poster's Twtxt url, and
the timestamp of the post, with a blake2b hash. Thing is,
that's going to change *just* a bit, but it's enough to
break backward compatibility[2].

  My only problem is how this change came about, and it's
making me question whether Twtxt/Yarn (or v2, or whatever
it may be called) actually still fits what I want to
support with a recommendation. See, there was talk about
the changes on their git repo, and James Mills (@prologic)
kinda made the decision to not only push things ahead, but
to give a hard deadline for all of the clients to make this
change: July 1, 2025. That's do-able, but it wasn't
entirely a community decision.

  However, it's one part of their response[3] in the
original thread[4] that kinda made me think that Twtxt/Yarn
isn't what I want be my first recommendation:

> I also fundamentally do not believe in the notion that
> Twtxt should be readable and writable by humans. We’ve
> thrown this “argument” around in support of some of the
> proposals, and I just don’t buy it (sorry). As an
> analogy, nobody writes Email by hand and transmits them
> to mail servers vai SMTP by hand. We use tools to do
> this. Twtxt/Yarn should be the same IMO.

  I'm not saying that this is wrong in any way. It's just
that Twtxt v1 holds the idea of making the file readable
and manually writable by the owner, and *that* is a quality
I hold as something I'd want to recommend. No, people don't
typically write email and transmit them to the server "by
hand", but it's *possible* to do so if one wanted to. It's
less about "Will you do it?" and more about "Can you do
it?".

  Yeah, that might be a petty complaint, but it's also just
my personal opinion on the matter. I'm just one being, and
I don't even use Twtxt anymore. I shouldn't have a say in
what that community does for their project, nor would I
expect to.

  Of course, I'm still going to keep track of things going
on over in Twtxt/Yarn land. I'm enthusiastic about seeing
their solutions to any problems they face, since those
could potentially help anyone who would stick with Twtxt v1
as well. Plus, it's offline-friendly tech, and I won't just
dismiss it for something so small when it's something that
could promote the ideas of offline-first and permacomputing
to people who might be interested. Even if it doesn't meet
my own needs, it can meet the needs of others.

\~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~/

[0]: https://twtxt.readthedocs.io/en/latest/
[1]: https://twtxt.dev/
[2]: https://git.mills.io/yarnsocial/twtxt.dev/src/commit/030d91b4d2f7c1b22a83fa3f841b86fce09481f3/exts/twt-hash-v2.md#implementation-timeline
[3]: https://twtxt.net/twt/s6pkqlq
[4]: https://twtxt.net/conv/ceripcq