movq @www.uninformativ.de
 (19h ago)

Sometimes, I wonder how my desktop looks to other people. Normal sighted people, I mean. For me, everything is much smaller and always slightly blurry (almost antialiased) because of my eyesight.

Maybe it does look horribly pixelated and super ugly to other people, and thatā€™s why everyone prefers smoothed fonts and UIs and all that ā€¦ ? šŸ˜‚

#p4hoasq
lyse @lyse.isobeef.org
 (19h ago)

(#fzmmn2q) @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:

https://lyse.isobeef.org/tmp/screenshot-2025-09-17-21-30-25.png

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

https://lyse.isobeef.org/tmp/screenshot-2025-09-17-21-20-39.png

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

#77wyfrq
lyse @lyse.isobeef.org
 (2d ago)

(#dvw775q) @zvava@twtxt.net There would be only one hash for a message. Some to be defined magic date selects which hash to use. If the message creation timestamp is before this epoch, hash it with v1, otherwise hammer it through v2. Eventually, support for v1 could be dropped as nobody interacts with the old stuff anymore. But Iā€™d keep it around in my client, because why not.

If users choose a client which supports the extensions, they donā€™t have to mess around with v1 and v2 hashing, just like today.

As for the school of thought, personally, Iā€™d prefer something else, too. Iā€™m in camp location-based addressing, or whatever it is called. There more I think about it, a complete redesign of twtxt and its extensions would be necessary in my opinion. Retrofitting has its limits. Of course, this is much more work, though.

#tu6eela
lyse @lyse.isobeef.org
 (2d ago)

(#nzs23fa) @zvava@twtxt.net It is just completely impossible to make v2 backwards-compatible with v1.

Well, breaking threads on edits is considered a feature by some people. I reckon the only approach to reasonably deal with that property is to carefully review messages before publishing them, thus delaying feed updates. Any typos etc., that have been discovered afterwards, are just left alone. Thatā€™s what I and some others do. I only risk editing if the feed has been published very few seconds earlier. More than 20 seconds and I just ignore it. Works alright for the most part.

#axrtzga
lyse @lyse.isobeef.org
 (5d ago)

Great. Yet another messed up plain text e-mail part. The URL was actually HTML-escaped. Took me five attempts to figure this out, because of course it had to be several kilometers long. In fact, the e-mail stated: ā€œPlease do not be surprised that the link is particularly long. It contains your personal configuration.ā€

A normal person is completely lost (thatā€™s why I got involved). Visting the broken URL opens a popup dialog suggesting to deactivate script blockers. Which I had already done upfront as a matter of prudence.

Fun bonus on top: The JWT in the link has identical iat (issued at) and exp (expiry) claims. The expiry is definitely not checked, itā€™s well in the past.

Medical software just has to be horrible. Itā€™s a law.

#zm264za