@movq@www.uninformativ.de It’s the “Lyse types the entire HTML by hand” generator. Yes, no kidding. I write articles so rarely, that I can do that once in a while. It’s fun to some degree, but also not.

After some time, I finally recorded some Vim macros to insert <b>…</b>, <var>…</var>, <span class=s>…</span> etc. around the tokens. This helped a little bit. But I was still questioning my mental state doing it like that. I also had to fix a bunch of the end tags by hand, because the word movement wasn’t enough or the end movement went too far. Quite the annoying process for sure.

But I think the HTML looks a wee bit nicer and is maybe even semantically a little bit better than having only <span>s everywhere. I find the <span class="whatever"> just soo awfully long. Of course, I never look at the code again, but knowing, that e.g. there is a <b> and it saves so many bytes in comparison, makes me happy. It is a more elegant solution in my opinion. Not by much, but better nonetheless. It’s a matter of simplicity. Admittedly, even I can’t avoid the <span>s alltogether. Oh well. On the other hand, I’m sure that this does not make any difference whatsoever. I bet, nobody and nothing, like a screenreader, analyzes the HTML for that, where this would be truly useful.

Oh! Maybe text browsers, though. It just occurred to me while composing this reply. :-) Haha, I lost my bet quickly. w3m picks up at least the <b> for keywords and builtin types, <u> for filenames and <i> for comments. Yey. No different styles for <var> and <mark>, unfortunately. elinks only renders the bold. It’s cool that I had the right intuition right from the beginning, despite being unable to pinpoint it. :-)

All the <span> hell with common syntax highlighters is a downer for me that keeps me from looking more into them. If I wrote more articles, I might rig something up with Pygments. At least that’s somehow positively connotated in my brain. Not sure if it actually deserves it, but I dealt with that in some loose form (can’t even remember) years and years ago. Apparently, it wasn’t too terrible.

To prepare the table of contents, I used grep and sed with some manual intervention in the end. The entire process can be improved. Absolutely.

You wrote your own site generator, didn’t you?

@lyse@lyse.isobeef.org Thanks! There are a few points in there that I’ll add to my list.

Your very first point is obviously crucial. “Writing code” is just the means to an end for many people and they don’t really care about it or like it, so they love AI. I had this in another draft (it refers to the other list I posted):

https://movq.de/v/614f14c3ef/ramble.txt

And this right here is so important:

simplicity is the real art and much harder to achieve.

Finding an elegant, simple solution is waaaaaaaaaaaaaaaaaay harder than anything else. And here’s the thing: I don’t get why nerds/techies don’t get “nerd-sniped” by this. A lot of people love building big stuff and then brag about being clever/competent because they were able to build that big thing – but once you realize that this approach is the lazy one, shouldn’t you make finding the elegant solution your goal? Doesn’t that give you more bragging rights?

(Am I being clear? Do you understand what I mean? 😅)

Of course, @movq@www.uninformativ.de! Most of my points are also included in your list.

First of all, programming is what I really do enjoy the most. So, it doesn’t make any sense at all to not do this anymore. “But you could use your now free time to do something much cooler and more valuable!”, others might reply. Fuck no, I don’t want to waste my time with other shit that doesn’t fulfill me, why on earth would I want to do that?

All this hallucination reduces quality badly. In my experience, it’s also happening much more rapidly than I expected. Even though developers are still supposed to own and understand whatever has been generated under their name and even be responsible for that, the sad reality is that teammates often blindly trust the AI output. “But I asked the AI and it told me that $this was impossible”, “I’ve no idea either, but the AI just generated it” are responses I get more often. What really makes my angry is when I point out a flaw and suggest an alternative and this is the reaction. It happened several times that just trying it out and seeing it clearly work to proof my point only took me half a minute, but people still did something handwavy else instead.

The learning effect is drastically reduced. The more time I spend on a topic, the better the odds that whatever I learned actually makes it over into long-term memory. It’s like if a collegue just says “do it like that” or “this solves your problem”, but neither explains the why or how. Somehow, people are still convinced that it’s a completely different story when you replace the human counterpart with a computer program in this equation.

Skills are unlearned. It’s like with automation in general, just much worse. You end up in a state where you’ve no clue how anything works under the hood or how to actually find out important information that are needed to solve your problem. You’re screwed when a process breaks out of the blue. Even though it can become also rather terrible, with classical automation you’re typically still be able to decipher how exactly the thing was supposed to do something.

The energy consumption is sooo high, I absolutely do not want to be a part in burning down our planet. I’m sure I find (and probably have long found without knowing) other ways to contribute to worsen our climate crisis.

The scraper part is already covered in detail in your list. :-)

I’m convinced that license and copyright violations are only played down or even refused entirely because companies want to make big money quickly. With the work of others of course. Their double standards are obvious, they still try to actively keep their own stuff secret and out of any training sets. At most for internal use only. Virtually noone in charge is interested in good long-term solutions. Short-term for the win, when disaster eventually strikes, the causers are long gone, the responsibilities in other hands.

Vendor lock-in is something that lots of folks are only realizing very slowly. It’s completely crazy to me. This drug dealer routine should be well-known by now. It’s fucking everywhere. Yet, people are always surprised when they found themselves caught in it.

Adding new AI stuff only increases complexity. But complexity is the enemy that everybody should fear and reduce as much as possible. Of course, this is not limited to AI at all. And everywhere I look around, people in charge looooove to make things way more complicated than they ever need to be. Yet, simplicity is the real art and much harder to achieve.

I don’t understand why we have to go back full force to the ambiguity of natural languages. This alone should be more than enough to realize what a stupid idea all that is. Linked to that is that the “instruction set” is interpreted differently with newer model versions. I mean, is has to be. Why else would somebody want to upgrade in the first place than to get more Powerful™ Features™?

Some people argue that with AI the democratization is empowered. However, in my view, the exact opposite is the case. Models are getting so large that you can basically not run them locally or even train them. So, you have to rely on whatever the vendor offers you and runs for you. In the end, this only gives the owners more power, the multi billionaires. Not exactly what I understand by democratization.

Finally, technology assessments are missing completely. Or they are faked such that mostly only the (questionable) benefits are listed. But all the negative impact is just ignored.

Let’s keep some popcorn around for when this all explodes. :-)

@zvava@twtxt.net agreed. I think display_name will be redundant, and add to the “busy” factor. That is, the opposite of simplicity.

And I need to make something absolutely clear as well here. Twtxt was completely and utterly dead back in {Aug 2020](https://yarn.social/about.html) when I came across the spec and its simplicity and realised the lost opportunity. Since then we’ve continued to grow a small but thriving community. The extensions we’ve built over time have stood and lasted the test of time for the past ~5 years. We need not break things too badly, because what we have today and was designed years ago actually works quite well™ (despite some flaws).

@kingdomcome@yarn.girlonthemoon.xyz Yeah, it’s all about simplicity. That’s what got me hooked. In its original form without the extensions, you can even read the raw feed and it doesn’t feel all that bad.

@movq@www.uninformativ.de This is a really good example of “simplicity” but achieves the intent and goals 👌

(Now, I don’t know if your screen reader can work with this. Let me know if it doesn’t.)

I don’t use a screen reader fortunately (actually they’re pretty garbage). So all good 👍 (I juse use full-screen zoom).

@movq@www.uninformativ.de yes, I think:

<!--[if !IE]><!-->
<link rel="stylesheet" href="../simplicity.css”>
<!--<![endif]-->

Should work, but I haven’t tested it.

i switched my bookmarks site from espial (unmaintained project) to linkding, and while i’ll miss espial’s simplicity, i do appreciate linkding’s power and the provided API.

at first i got auth working with my SSO (authelia) and was happy, but i want my public bookmarks available without login… and i couldn’t configure my proxy to make that work, because of issues with sub paths, which sucks. so i switched to linkding’s built-in auth. inconvenient, but worth it to share my bookmarks.

https://bookmarks.4-walls.net/bookmarks/shared

@lyse@lyse.isobeef.org that’s alright haha! i don’t expect anyone to listen/watch in full or with full attention bc it’s so long lmao

the thing with PHP for me is that i… feel like it hits a kind of simplicity that i can understand? it’s so plain but can be very powerful. i quite like that. as much as i can learn something infinitely more powerful, PHP hits a comfortable thing where i can handle things like backend sqlite DBs AND how a page is rendered, without requiring a complex frontend with its own quirks (like ruby on rails, which as much as i know and love it, can be heavy).

but i totally get you! PHP security is very scary. i’m always worried that i’m messing something up. it’s why the PHP application i’m working on i have dockerized by default for a small but extra layer of protection

i’ll try to not get discouraged tysm for your advice

@prologic@twtxt.net genuinely the sickest shit i’ve ever seen webdev is saved

by commenting out DMs are you giving up on simplicity? See the Metadata extension holding the data inside comments, as the client doesn’t need to show it inside the timeline.

I don’t think that commenting out DMs as we are doing for metadata is giving up on simplicity (it’s a feature already), and it helps to hide unwanted DMs to clients that will take months to add it’s support to something named… an extension.

For some other extensions in https://twtxt.dev/extensions.html (for example the reply-to hash #abcdfeg or the mention @ < example http://example.org/twtxt.txt >) is not a big deal. The twt is still understandable in plain text.
For DM, it’s only interesting for you if you are the recipient, otherwise you see an scrambled message like 1234567890abcdef=. Even if you see it, you’ll need some decryption to read it. I’ve said before that DMs shouldn’t be in the same section that the timeline as it’s confusing.

So my point stands, and as I’ve said before, we are discussing it as a community, so let’s see what other maintainers add to the convo.

After reading you, @eapl.me@eapl.me, I’ll tell you my point of view.
In my opinion, a feed does not have to be equivalent to a timeline. A timeline is a representation of the feed adapted to a user. You may not be interested in seeing other people’s threads or DMs. But perhaps they are interested in seeing mentions or DMs directed at them. It is important not to fall into the trap. With that clarification…
I insist, this is my point of view, it is not an absolute truth: I don’t think extensions should be respectful of customers who are no longer maintained.
We cannot have a system that is simple, backwards compatible and extensible all at the same time. We have to give up some of the 3 points. I would not like to give up simplicity because it will then make it harder to maintain the customers who do stay. Therefore, I think it is better to give up backwards compatibility and play with new formulas in the extensions. I don’t think it’s a good idea to make a hash keep so much load: a hashtag, a thread and also a DM.

What makes Slackware different?
I’m not entirely sure how to link to this properly, but what we have here is a simple, to-the-point text file describing some of the benefits of Slackware, the oldest still maintained Linux distribution. It’s still run by Patrick Volkerding, and focuses on conservative choices and simplicity over ease. I doubt I have to explain the benefits of Slackware to the average OSNews reader, but this simple little text file does serve as a great marketing tool. The fact it’s a … ⌘ Read more

FreeDOS: history, legacy, and a valuable resource for old machines
FreeDOS is a free and open‐source operating system designed to be compatible with MS‑DOS. Developed to keep the DOS experience alive even after Microsoft ended support for MS‑DOS, FreeDOS has grown into a complete environment that not only preserves classic DOS functionality but also introduces modern enhancements. Its simplicity and low resource requirements have made it a cherished resource for retro … ⌘ Read more

@nff@www.noizhardware.com Nice! Yeah, it’s all about having fun. :-) The simplicity got me hooked. Happy hacking!

@prologic@twtxt.net Nah, it’s really not necessary from my point of view. There’s not enough math here that would justify it. In the spirit of simplicity, I’d leave it off. O:-)

Righto, @eapl.me@eapl.me, ta for the writeup. Here we go. :-)

Metadata on individual twts are too much for me. I do like the simplicity of the current spec. But I understand where you’re coming from.

Numbering twts in a feed is basically the attempt of generating message IDs. It’s an interesting idea, but I reckon it is not even needed. I’d simply use location based addressing (feed URL + ‘#’ + timestamp) instead of content addressing. If one really wanted to, one could hash the feed URL and timestamp, but the raw form would actually improve disoverability and would not even require a richer client. But the majority of twtxt users in the last poll wanted to stick with content addressing.

yarnd actually sends If-Modified-Since request headers. Not only can I observe heaps of 304 responses for yarnds in my access log, but in Cache.FetchFeeds(…) we can actually see If-Modified-Since being deployed when the feed has been retrieved with a Last-Modified response header before: https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/cache.go#L1278

Turns out etags with If-None-Match are only supported when yarnd serves avatars (https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/handlers.go#L158) and media uploads (https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/media_handlers.go#L71). However, it ignores possible etags when fetching feeds.

I don’t understand how the discovery URLs should work to replace the User-Agent header in HTTP(S) requests. Do you mind to elaborate?

Different protocols are basically just a client thing.

I reckon it’s best to just avoid mixing several languages in one feed in the first place. Personally, I find it okay to occasionally write messages in other languages, but if that happens on a more regularly basis, I’d definitely create a different feed for other languages.

Isn’t the emoji thing “just” a client feature? So, feed do not even have to state any emojis. As a user I’d configure my client to use a certain symbol for feed ABC. Currently, I can do a similar thing in tt where I assign colors to feeds. On the other hand, what if a user wants to control what symbol should be displayed, similar to the feed’s nick? Hmm. But still, my terminal font doesn’t even render most of emojis. So, Unicode boxes everywhere. This makes me think it should actually be a only client feature.

@prologic@twtxt.net

See https://dev.twtxt.net

Yes, that is exactly what I meant. I like that collection and “twtxt v2” feels like a departure.

Maybe there’s an advantage to grouping it into one spec, but IMO that shouldn’t be done at the same time as introducing new untested ideas.

See https://yarn.social (especially this section: https://yarn.social/#self-host) – It really doesn’t get much simpler than this 🤣

Again, I like this existing simplicity. (I would even argue you don’t need the metadata.)

That page says “For the best experience your client should also support some of the Twtxt Extensions…” but it is clear you don’t need to. I would like it to stay that way, and publishing a big long spec and calling it “twtxt v2” feels like a departure from that. (I think the content of the document is valuable; I’m just carping about how it’s being presented.)

“Everything should be made as simple as possible, but not simpler.”
– Albert Einstein

The beauty of simplicity lies in not losing the essence.

#simplicity #Einstein #wisdom

No, json is overhead. I love twtxt for simplicity where blog is just text file and not several json files where fields are repeated…

(#2024-09-24T12:39:32Z) @prologic@twtxt.net It might be simple for you to run echo -e "\t\t" | sha256sum | base64, but for people who are not comfortable in a terminal and got their dev env set up, then that is magic, compared to the simplicity of just copy/pasting what you see in a textfile into another textfile – Basically what @movq@www.uninformativ.de also said. I’m also on team extreme minimalism, otherwise we could just use mastodon etc. Replacing line-breaks with a tab would also make it easier to handwrite your twtxt. You don’t have to hardwrite it, but at least you should have the option to. Just as i do with all my HTML and CSS.

So really your argument is just that switching to a location-based addressing “just makes sense”. Why? Without concrete pros/cons of each approach this isn’t really a strong argument I’m afraid. In fact I probably need to just sit down and detail the properties of both approaches and the pros/cons of both.

I also don’t really buy the argument of simplicity either personally, because I don’t technically see it much more difficult to take a echo -e "<url>\t<timestamp>\t<content>" | sha256sum | base64 as the Twt Subject or concatenating the <url> <timestamp> – The “effort” is the same. If we’re going to argue that SHA256 or cryptographic hashes are “too complicated” then I’m not really sure how to support that argument.

@prologic@twtxt.net Some criticisms and a possible alternative direction:

1. Key rotation. I’m not a security person, but my understanding is that it’s good to be able to give keys an expiry date and replace them with new ones periodically.

2. It makes maintaining a feed more complicated. Now instead of just needing to put a file on a web server (and scan the logs for user agents) I also need to do this. What brought me to twtxt was its radical simplicity.

Instead, maybe we should think about a way to allow old urls to be rotated out? Like, my metadata could somehow say that X used to be my primary URL, but going forward from date D onward my primary url is Y. (Or, if you really want to use public key cryptography, maybe something similar could be used for key rotation there.)

It’s nice that your scheme would add a way to verify the twts you download, but https is supposed to do that anyway. If you don’t trust https to do that (maybe you don’t like relying on root CAs?) then maybe your preferred solution should be reflected by your primary feed url. E.g. if you prefer the security offered by IPFS, then maybe an IPNS url would do the trick. The fact that feed locations are URLs gives some flexibility. (But then rotation is still an issue, if I understand ipns right.)

This reminds me of this video: The Biggest Gap in Science: Complexity

However you might end up with more questions (complexity?) than answers (simplicity?)

I’ve recently parsed html and gemini, and I can say the best part of #gemini is it’s simplicity <3

For the Sake of Simplicity
⌘ Read more

@lyse@lyse.isobeef.org Yes, I often read the raw messages. But more to the point, the simplicity of the format is the bulk of the appeal.

@prologic@twtxt.net Yep! installed it yesterday. I like the simplicity of twt. I am quite happy with how little memory the pod seems to use. Mastodon and the “lightweight” Pleroma don’t work well in small VMs.