@movq Gemini liked your opinion very much. Here is how it countered:

1. The User Perspective (Untrustworthiness)

The criticism of AI as untrustworthy is a problem of misapplication, not capability.

• AI as a Force Multiplier: AI should be treated as a high-speed drafting and brainstorming tool, not an authority. For experts, it offers an immense speed gain, shifting the work from slow manual creation to fast critical editing and verification.
• The Rise of AI Literacy: Users must develop a new skill—AI literacy—to critically evaluate and verify AI's probabilistic output. This skill, along with improving citation features in AI tools, mitigates the "gaslighting" effect.

2. The Moral/Political Perspective (Skill Erosion)

The fear of skill loss is based on a misunderstanding of how technology changes the nature of work; it's skill evolution, not erosion.

• Shifting Focus to High-Level Skills: Just as the calculator shifted focus from manual math to complex problem-solving, AI shifts the focus from writing boilerplate code to architectural design and prompt engineering. It handles repetitive tasks, freeing humans for creative and complex challenges.
• Accessibility and Empowerment: AI serves as a powerful democratizing tool, offering personalized tutoring and automation to people who lack deep expertise. While dependency is a risk, this accessibility empowers a wider segment of the population previously limited by skill barriers.

3. The Technical and Legal Perspective (Scraping and Copyright)

The legal and technical flaws are issues of governance and ethical practice, not reasons to reject the core technology.

• Need for Better Bot Governance: Destructive scraping is a failure of ethical web behavior and can be solved with better bot identification, rate limits, and protocols (like enhanced robots.txt). The solution is to demand digital citizenship from AI companies, not to stop AI development.

Pretty happy with my zs-blog-template starter kit for creating and maintaining your own blog using zs 👌 Demo of what the starter kit looks like here -- Basic features include:

• Clean layout & typography
• Chroma code highlighting (aligned to your site palette)
• Accessible copy-code button
• “On this page” collapsible TOC
• RSS, sitemap, robots
• Archives, tags, tag cloud
• Draft support (hidden from lists/feeds)
• Open Graph (OG) & Twitter card meta (default image + per-post overrides)
• Ready-to-use 404 page

As well as custom routes (redirects, rewrites, etc) to support canonical URLs or redirecting old URLs as well as new zs external command capability itself that now lets you do things like:

$ zs newpost

to help kick-start the creation of a new post with all the right "stuff"™ ready to go and then pop open your $EEDITOR 🤞

#awesome #zs

TNO Threading (draft):
Each origin feed numbers new threads (tno:N). Replies carry both (tno:N) and (ofeed:<origin-url>). Thread identity = (ofeed, tno).

• Roots: (tno:N) (implicit ofeed=self).
• Replies: (tno:N) (ofeed:<url>).
• Clients: increment tno locally for new threads, copy tags on reply.
• Subjects optional, not required.

...

First draft of yarnd 0.16 release notes. 📝 -- Probably needs some tweaking and fixing, but it's sounding alright so far 👌 #yarnd

also I've made a draft of a voting page to receive preferences on each proposal https://eapl.me/rfc0001/

Help me to play with it a bit and report any vulnerability or bug. Also any idea is welcome.

Hi everyone, I've drafted a Request for Comments (RFC) to improve how threads work in twtxt: https://git.mills.io/yarnsocial/twtxt.dev/issues/18

I’d love your feedback! Please share your thoughts on anything that could be better explained, check if the proposed dates work for everyone, and I invite you to join the discussion...

I made a draft of an "encrypted public messenger", which was basically a Feed for an address derivate from the public ket, let's say 'abcd..eaea'

Anyone could check, "are there any messages for my address?" and you get a whole list of timestamps and encrypted stuff.

Inside the encrypted message is a signature from the sender. That way you 'could' block spam.

Only the owner of the private key could see who sent what, and so...

And even with that my concussion was that users expectations for a private IM might be far away from my experiment.

I've started a draft over at: https://git.mills.io/yarnsocial/twtxt.dev/src/branch/main/exts/webfinger.md

I just "published" a #draft on my blog about "How I've implemented #webmentions for twtxt" (http://darch.dk/mentions-twtxt), so I wanted to know from you guys if you see yourself doing a similar thing with yarnd @prologic or others with custom setups?