Show HN for August 22, 2025

(spoiler: its XSLT)

I've been working on a little demo for how to avoid copy-pasting header/footer boilerplate on a simple static webpage. My goal is to approximate the experience of Jekyll/Hugo but eliminate the need for a build step before publishing. This demo shows how to get basic templating features with XSL so you could write a blog post which looks like

  <?xml version="1.0"?>
  <?xml-stylesheet type="text/xsl" href="/template.xsl"?>
  <page>
      <title>My Article</title>
      <content>
          some content
          <ul>
              <li>hello</li>
              <li>hello</li>
          </ul>
      </content>
  </page>

Some properties which set this approach apart from other methods:

  - no build step (no need to setup Jekyll on the client or configure Github/Gitlab actions)
  - works on any webserver (e.g. as opposed to server-side includes, actions)
  - normal looking URLs (e.g. `example.com/foobar` as opposed to `example.com/#page=foobar`)

There's been some talk about removing XSLT support from the HTML spec [0], so I figured I would show this proof of concept while it still works.

[0]: https://news.ycombinator.com/item?id=44952185

See also: grug-brain XSLT https://news.ycombinator.com/item?id=44393817

Hi HN – we're the founders of BrowserOS.com (YC S24), and we're building an open-source agentic web browser. We're a fork of Chromium and our goal is to let non-developers create and run useful agents locally on their browser.

--- When we launched a month ago, we thought we had the right approach: a "one-shot" agent where you give it a high-level task like "order toothpaste from Amazon," and it would figure out the plan and execute it.

But we quickly ran into a problem that we've been struggling with ever since: the user experience was completely hit-or-miss. Sometimes it worked like magic, but other times the agent would get stuck, generate a wrong plan, or just wander off course. It wasn't reliable enough for anyone to trust it.

This forced us to go back to the drawing board and question the UX. We spent the last few weeks experimenting with three different ways a user could build an agent:

A) Drag-and-drop workflows: Similar to tools like n8n. This approach creates very reliable agents, but we found that the interface felt complex and intimidating for new users. One tester (my wife) said: "This is more work than just doing the task myself." Building a simple workflow took 20+ minutes of configuration.

B) The "one-shot" agents: This was our starting point. You give the agent a high-level goal and it does the rest. It feels magical when it works, but it's brittle, and smaller local models really struggle to create good plans on their own.

C) Plan-follower agents: A middle ground where a human provides a simple, high-level plan in natural language, and the LLM executes each step. The LLM doesn't have to plan; it just has to follow instructions, like a junior employee.

--- After building and trying all three, we've landed on C) as the best trade-off between reliability and ease of use. Here's the demo https://youtu.be/ulTjRMCGJzQ

For example, instead of just saying "order toothpaste," the user provides a simple plan:

1. Navigate to Amazon

2. Search for Sensodyne toothpaste

3. Select 1 pack of Sensodyne toothpaste from the results

4. Add the selected toothpaste to the cart

5. Proceed to checkout

6. Verify that there is only one item in the cart. If there is more than one item, alert me

7. Finally place the order

With this guidance, our success rate jumped from 30% to ~80%, even with local models. The trade-off: users spend 30 seconds writing a plan instead of just stating a goal. But they get reliability in return. Note that our agent builder gives a good starting plan, and then the user has to just edit/customize it.

--- You can try out our agent builder and let us know what you think. We're big proponents of privacy, so we have first-class support for local LLMs. You can try GPT-OSS via Ollama or LMStudio and it works great!

I'll be hanging around here most of the day, happy to answer any questions!

I built AIMless, a ridiculously minimalistic, browser native chat app that fits entirely into one HTML file (10 KB). It’s decentralized, P2P, and has no build tools, no server, and no frameworks. Just you, your browser, and a copy/pasted blob or two.

I’m proposing AICF (AI Changefeed) — a minimal, web-native way for sites to expose append-only change events. Instead of crawlers or RAG systems re-embedding everything, they can refresh only the sections that changed.

Discovery: a /.well-known/ai-changefeed JSON points to a feed.

Feed: an append-only NDJSON file with just 4 required fields (id, action, url, time) plus optional hints (anchor, checksum, note).

Goal: cut wasted crawling/embedding while keeping docs/pricing/policy pages fresh for AI/agents.

Spec & examples here: https://github.com/mnswdhw/AICF/blob/main/spec/AICF-v0.1.md

Would love feedback: is the minimal core (anchors only, no chunks/vectors/push yet) the right starting point? Would you use this in your docs/RAG stack?

It’s been one month since I launched CopyMagic, a smarter clipboard manager for macOS that makes sure you never lose anything you copy.

Instead of digging through endless items, you can type things like “URL from Slack”, “flight information”, or “crypto rate” and it instantly finds what you meant.

It’s all completely offline and privacy-first (we don’t even track analytics).

We Released an independent evaluation of GPT-5 vs Claude 4 Sonnet across 200 diverse prompts.

Key insights: GPT-5 excels in reasoning and code; Claude 4 Sonnet is faster and slightly more precise on factual tasks.

This is Lumo, a tiny fluffy virtual pet that lives in your browser.

You can feed it, tickle it, or just say hi — it reacts naturally, more like a living toy than a game character.

Play here: https://yw.app/ujtA8IZ

## Why I made this

I wanted to experiment with combining AI-generated assets (image-to-video via Google Flow) and a lightweight state machine in JavaScript to simulate natural pet-like behaviors. Instead of giving direct commands, you just interact — and Lumo reacts.

## How it works

- Assets were generated with image-to-video (idle, happy, annoyed, etc.). To make the animations feel more natural, I used the Frames-to-Video mode — for example, I set both the start and end frames to the idle state, so transitions between different behaviors look smoother.

- A JS state machine switches animations and reactions. For example, the default state is the idle animation. If you touch Lumo once, it becomes curious and shows the corresponding behavior (animation). If you touch it again, it turns happy.

- Everything runs client-side in the browser.

## What’s next

This is just a small experiment right now. I’d love to hear feedback:

- What feels fun or missing in the interaction?

- What other “pet-like” behaviors could make it more alive?

- Anyone else here experimenting with AI video assets for interactive projects?

Thanks for checking it out

An AI interviewer for software engineers to practice with on-demand mock system design interviews.

Built Mudra to see if/where LLMs cite your company, and what to fix to get cited more.

hey hn, wanted to share something i've been working on for a bit.

most focus apps like opal are static. they block a list of websites and that’s it. once you start a timer, you’re locked in. can’t quit, can’t delete, can’t reason with it.

but real focus isn’t that binary. sometimes i actually need to use youtube or reddit for a task, like watching a physics lecture or checking a solution. blocking everything just doesn't work. also, sometimes "harmless" sites like wikipedia pages or news pages send me into rabbit holes. you can't realistically block every one of these.

so i tried to build something that uses the context on your screen to figure out whether you're focused.

i set a task (e.g. “studying physics – waves + optics”), describe what i’m doing, and how long i want to focus.

then the app uses my browser's context to check if i'm on-task or off-task, based on what i'm doing - not just what site i'm on.

if i'm off-task, blocks the site. even after it's blocked, you can explain to it why you really need the site - if the app thinks the reason's valid, it lets you in. this takes care of most false positives.

still early and it's only a chrome extension, but it works and it’s helped me a lot.

happy to hear feedback and would be curious to hear if people would pay for this.

there's also a demo video on the extension page for those curious.

I have been working on SFOR (Streamable Flat Object Representation) — a structured text format I built after finding that existing formats did not quite fit my needs..

- *Streamable:* Can be parsed as it arrives, without needing the entire payload in memory. - *No-backtracking:* The parser never has to "rewind" to re-interpret earlier data. - *Type-explicit:* Types are clearly defined in the stream, avoiding ambiguity. - *Minimal overhead:* Compact representation without sacrificing readability in its intermediate form.

The goal is to handle cases where formats like JSON or YAML work, but a streamable, predictable, and low-memory alternative is better suited — especially for constrained devices, large datasets, or real-time processing.

I would appreciate your thoughts on: - Potential edge cases I haven not considered. - Comparisons to similar formats you have used. - Whether the "no required backtracking" claim holds up in your experience with other formats.

*Repo:* - [SFOR Repo](https://github.com/brucekaushik/sfor)

Hello HN! I finally took the time to go from a prototype to a clean and (hopefully) scalable version of this side project.

It's a small website that you can set as the home page in your Steam overlay browser settings. It allows you to register bookmarks on a per-game basis, and search the web with the search engine of your choice.

All your Steam Bookmarks data (your settings and your bookmarks) is exclusively stored in your browser, using localStorage.

Steam Bookmarks is open-source: https://github.com/tanguyMichardiere/steam-bookmarks - it's your typical Next.js + TailwindCSS app, the most interesting file is probably src/api/player-summary.ts, in which I implemented a non-trivial cache with Redis to avoid hitting the Steam Web API rate limit.

Cheers!

AgentState to solve a problem I kept running into: managing state for multi-agent AI systems is surprisingly hard.

When you have multiple AI agents that need to coordinate, persist their state, and query each other's status, you typically end up with a mess of Redis/Postgres setups, custom queuing, and manual synchronization code.

The whole thing is ~3MB, written in Rust for performance and safety, runs in Docker, and handles 1000+ ops/sec. I've been running it in production for AI workflows and it's been rock solid.