lyse @lyse.isobeef.org

Follow

Block / Report User

If this user/feed is violating this Pod's (yarn.meff.me) community guidelines as set out in the Abuse Policy, please report them immediately!

You are also free to Unfollow or Mute this user or feed. Muting will also remove that user/feed's content from your view and you will no longer see content from that user/feed anywhere.

@lyse does not follow you (they may not see your replies!)

Recent Twts

Recent twts from lyse

(#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

(#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

(#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

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

(#24c3dta) @bender@twtxt.net Absolutely. My computer science teacher was really great and in a lot of aspects very similar. Especially combining the theoretical and practical parts. He’s also the main reason I ended up where I am today. I’m very grateful to him. Mr. Burger, however, takes this on a whole new level.


#jl65lta

(#ko634iq) @kat@yarn.girlonthemoon.xyz Ta. The only good use for <details> is to collapse long logs in bug analysis reports. Other than that, I find it rather annoying to expand sections manually.

As for spoilers, personally, I don’t care at all. Not the slightest bit. If there is something that I don’t wanna read, I just stop reading. ĀÆ_(惄)_/ĀÆ

But I’ve got the feeling that I’ve got an unpopular opinion on that matter. ;-)


#fhmijba

(#z25erwq) @zvava@twtxt.net I never used any of the social media platforms, that’s why I’m probably ignorant.

I don’t understand the concept of a retwt. Just quote the (relevant) parts from whereever and comment on that. Or post a link instead of a quote. Sounds simple enough. :-) That’s also has the benefit that it works with every source, no matter what. Since it’s called retwt, I’d imagine this to only work (well) with whatever messages the system itself offers. But I could be wrong. What would be the benefit of having a dedicated message type or structure for ā€œhey, look at thatā€ messages in your opinion?

Hmm, what’s a content warning?


#6atyjjq

(#s7jfiqq) @kat@yarn.girlonthemoon.xyz Ten stories or more are already very tall in my books. Not sure at which height I would start calling high rise buildings sky scrapers, but Wikipedia suggests around 150 meters, depending on region.

Oh, I just found https://upload.wikimedia.org/wikipedia/commons/f/f1/Pier_17_2018-03_jeh.jpg and this really does not look all that high. I thought that this would be at least 50 or 100 meters up. I was completely wrong. :-D


#d4u6mnq