🛠️ Hacker News Tools

[Database] Show HN: S2-lite, an open source Stream Store S2 was on HN for our intro blog post a year ago (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42480105">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42480105</a>). S2 started out as a serverless API — think S3, but for streams.<p>The idea of streams as a cloud storage primitive resonated with a lot of folks, but not having an open source option was a sticking point for adoption – especially from projects that were themselves open source! So we decided to build it: <a href="https:&#x2F;&#x2F;github.com&#x2F;s2-streamstore&#x2F;s2" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;s2-streamstore&#x2F;s2</a><p>s2-lite is MIT-licensed, written in Rust, and uses SlateDB (<a href="https:&#x2F;&#x2F;slatedb.io" rel="nofollow">https:&#x2F;&#x2F;slatedb.io</a>) as its storage engine. SlateDB is an embedded LSM-style key-value database on top of object storage, which made it a great match for delivering the same durability guarantees as s2.dev.<p>You can specify a bucket and path to run against an object store like AWS S3 — or skip to run entirely in-memory. (This also makes it a great emulator for dev&#x2F;test environments).<p>Why not just open up the backend of our cloud service? s2.dev has a decoupled architecture with multiple components running in Kubernetes, including our own K8S operator – we made tradeoffs that optimize for operation of a thoroughly multi-tenant cloud infra SaaS. With s2-lite, our goal was to ship something dead simple to operate. There is a lot of shared code between the two that now lives in the OSS repo.<p>A few features remain (notably deletion of resources and records), but s2-lite is substantially ready. Try the Quickstart in the README to stream Star Wars using the s2 CLI!<p>The key difference between S2 vs a Kafka or Redis Streams: supporting tons of durable streams. I have blogged about the landscape in the context of agent sessions (<a href="https:&#x2F;&#x2F;s2.dev&#x2F;blog&#x2F;agent-sessions#landscape">https:&#x2F;&#x2F;s2.dev&#x2F;blog&#x2F;agent-sessions#landscape</a>). Kafka and NATS Jetstream treat streams as provisioned resources, and the protocols&#x2F;implementations are oriented around such assumptions. Redis Streams and NATS allow for larger numbers of streams, but without proper durability.<p>The cloud service is completely elastic, but you can also get pretty far with lite despite it being a single-node binary that needs to be scaled vertically. Streams in lite are &quot;just keys&quot; in SlateDB, and cloud object storage is bottomless – although of course there is metadata overhead.<p>One thing I am excited to improve in s2-lite is pipelining of writes for performance (already supported behind a knob, but needs upstream interface changes for safety). It&#x27;s a technique we use extensively in s2.dev. Essentially when you are dealing with high latencies like S3, you want to keep data flowing throughout the pipe between client and storage, rather than go lock-step where you first wait for an acknowledgment and then issue another write. This is why S2 has a session protocol over HTTP&#x2F;2, in addition to stateless REST.<p>You can test throughput&#x2F;latency for lite yourself using the `s2 bench` CLI command. The main factors are: your network quality to the storage bucket region, the latency characteristics of the remote store, SlateDB&#x27;s flush interval (`SL8_FLUSH_INTERVAL=..ms`), and whether pipelining is enabled (`S2LITE_PIPELINE=true` to taste the future).<p>I&#x27;ll be here to get thoughts and feedback, and answer any questions!

[API/SDK] Show HN: SpeechOS – Wispr Flow-inspired voice input for any web app Hi Hacker News! I’m David Huie. I’m launching SpeechOS, a drop-in voice input SDK for web apps.<p>I was inspired by Wispr Flow and wanted the same workflow inside business apps (CRMs, docs, forms, support tools), not just a standalone tool. It’s saved me a massive amount of time vs typing.<p>How it works: add a couple lines of JS plus an API key, and SpeechOS shows a small mic widget on every text field.<p>Live demo: <a href="https:&#x2F;&#x2F;www.speechos.ai&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.speechos.ai&#x2F;</a><p>(Click a text box and the mic widget appears; click the gear icon to see settings, custom vocabulary, and snippet configuration.)<p>Users can:<p>- Dictate: speak naturally, real-time voice to polished text (punctuation, no filler&#x2F;typos)<p>- Edit: say “make it shorter”, “fix grammar”, “translate...”<p>- Command: define Siri-style app actions (for example, “submit form”, “mark complete”), and we match intent to your commands<p>It also supports:<p>- Custom vocabulary: domain terms and names (product names, acronyms, jargon) so they transcribe correctly<p>- Text snippets: saved reusable blocks of text you can insert by voice (for example, “my signature”, “disclaimer”, “my address”)<p>Why: text entry speed and accuracy still matter for productivity tools. A large-scale text entry dataset with 37,370 participants showed an average typing speed of 36.2 WPM and ~2.3% uncorrected errors. In speech research, speech recognition was about 3× faster than keyboard input and had ~20.4% lower error rate for English text entry. (<a href="https:&#x2F;&#x2F;hci.stanford.edu&#x2F;research&#x2F;speech&#x2F;" rel="nofollow">https:&#x2F;&#x2F;hci.stanford.edu&#x2F;research&#x2F;speech&#x2F;</a>)<p>SpeechOS is currently in beta and free for now. Sign up at <a href="https:&#x2F;&#x2F;app.speechos.ai&#x2F;accounts&#x2F;signup&#x2F;" rel="nofollow">https:&#x2F;&#x2F;app.speechos.ai&#x2F;accounts&#x2F;signup&#x2F;</a> and enter this HN-only beta code: HN-JFc74cVC (please don’t share outside HN).<p>Links:<p>SDK repo: <a href="https:&#x2F;&#x2F;github.com&#x2F;speechos-org&#x2F;speechos-client" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;speechos-org&#x2F;speechos-client</a><p>Demo: <a href="https:&#x2F;&#x2F;www.speechos.ai&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.speechos.ai&#x2F;</a><p>Signup (code: HN-JFc74cVC): <a href="https:&#x2F;&#x2F;app.speechos.ai&#x2F;accounts&#x2F;signup&#x2F;" rel="nofollow">https:&#x2F;&#x2F;app.speechos.ai&#x2F;accounts&#x2F;signup&#x2F;</a><p>I’d love feedback on:<p>1) Where this is most valuable in your stack (notes? docs? CRM entry? support macros?)<p>2) What you’d want from voice commands&#x2F;snippets configuration<p>3) What would make you comfortable shipping this (privacy&#x2F;security, latency, pricing)<p>If you’re building anything in voice AI&#x2F;dictation, I’d be happy to swap notes (david@speechos.ai).

[Other] Show HN: See the carbon impact of your cloud as you code Hey folks, I’m Hassan, one of the co-founders of Infracost (<a href="https:&#x2F;&#x2F;www.infracost.io">https:&#x2F;&#x2F;www.infracost.io</a>). Infracost helps engineers see and reduce the cloud cost of each infrastructure change before they merge their code. The way Infracost works is we gather pricing data from Amazon Web Services, Microsoft Azure and Google Cloud. What we call a ‘Pricing Service’, which now holds around 9 million live price points (!!). Then we map these prices to infrastructure code. Once the mapping is done, it enables us to show the cost impact of a code change before it is merged, directly in GitHub, GitLab etc. Kind of like a checkout-screen for cloud infrastructure.<p>We’ve been building since 2020 (we were part of YC W21 batch), and iterating on the product, building out a team etc. However, back in 2020 one of our users asked if we can also show the carbon impact alongside costs.<p>It has been itching my brain since then. The biggest challenge has always been the carbon data. The mapping of carbon data to infrastructure is time consuming, but it is possible since we’ve done it with cloud costs. But we need the raw carbon data first. The discussions that have happened in the last few years finally led me to a company called Greenpixie in the UK. A few of our existing customers were using them already, so I immediately connected with the founder, John.<p>Greenpixie said they have the data (AHA!!) And their data is verified (ISO-14064 &amp; aligned with the Greenhouse Gas Protocol). As soon as I talked to a few of their customers, I asked my team to see if we can actually finally do this, and build it.<p>My thinking is this: some engineers will care, and some will not (or maybe some will love it and some will hate it!). For those who care, cost and carbon are actually linked; meaning if you reduce the carbon, you usually reduce the cost of the cloud too. It can act as another motivation factor.<p>And now, it is here, and I’d love your feedback. Try it out by going to <a href="https:&#x2F;&#x2F;dashboard.infracost.io&#x2F;">https:&#x2F;&#x2F;dashboard.infracost.io&#x2F;</a>, create an account, set up with the GitHub app or GitLab app, and send a pull request with Terraform changes (you can use our example terraform file). It will then show you the cost impact alongside the carbon impact, and how you can optimize it.<p>I’d especially love to hear your feedback on if you think carbon is a big driver for engineers within your teams, or if carbon is a big driver for your company (i.e. is there anything top-down about carbon).<p>AMA - I’ll be monitoring the thread :)<p>Thanks

[Other] A verification layer for browser agents: Amazon case study A common approach to automating Amazon shopping or similar complex websites is to reach for large cloud models (often vision-capable). I wanted to test a contradiction: can a ~3B parameter local LLM model complete the flow using only structural page data (DOM) plus deterministic assertions?<p>This post summarizes four runs of the same task (search → first product → add to cart → checkout on Amazon). The key comparison is Demo 0 (cloud baseline) vs Demo 3 (local autonomy); Demos 1–2 are intermediate controls.<p>More technical detail (architecture, code excerpts, additional log snippets):<p><a href="https:&#x2F;&#x2F;www.sentienceapi.com&#x2F;blog&#x2F;verification-layer-amazon-case-study" rel="nofollow">https:&#x2F;&#x2F;www.sentienceapi.com&#x2F;blog&#x2F;verification-layer-amazon-...</a><p>Demo 0 vs Demo 3:<p>Demo 0 (cloud, GLM‑4.6 + structured snapshots) success: 1&#x2F;1 run tokens: 19,956 (~43% reduction vs ~35k estimate) time: ~60,000ms cost: cloud API (varies) vision: not required<p>Demo 3 (local, DeepSeek R1 planner + Qwen ~3B executor) success: 7&#x2F;7 steps (re-run) tokens: 11,114 time: 405,740ms cost: $0.00 incremental (local inference) vision: not required<p>Latency note: the local stack is slower end-to-end here largely because inference runs on local hardware (Mac Studio with M4); the cloud baseline benefits from hosted inference, but has per-token API cost.<p>Architecture<p>This worked because we changed the control plane and added a verification loop.<p>1) Constrain what the model sees (DOM pruning). We don’t feed the entire DOM or screenshots. We collect raw elements, then run a WASM pass to produce a compact “semantic snapshot” (roles&#x2F;text&#x2F;geometry) and prune the rest (often on the order of ~95% of nodes).<p>2) Split reasoning from acting (planner vs executor).<p>Planner (reasoning): DeepSeek R1 (local) generates step intent + what must be true afterward. Executor (action): Qwen ~3B (local) selects concrete DOM actions like CLICK(id) &#x2F; TYPE(text). 3) Gate every step with Jest‑style verification. After each action, we assert state changes (URL changed, element exists&#x2F;doesn’t exist, modal&#x2F;drawer appeared). If a required assertion fails, the step fails with artifacts and bounded retries.<p>Minimal shape:<p>ok = await runtime.check( exists(&quot;role=textbox&quot;), label=&quot;search_box_visible&quot;, required=True, ).eventually(timeout_s=10.0, poll_s=0.25, max_snapshot_attempts=3)<p>What changed between “agents that look smart” and agents that work Two examples from the logs:<p>Deterministic override to enforce “first result” intent: “Executor decision … [override] first_product_link -&gt; CLICK(1022)”<p>Drawer handling that verifies and forces the correct branch: “result: PASS | add_to_cart_verified_after_drawer”<p>The important point is that these are not post‑hoc analytics. They are inline gates: the system either proves it made progress or it stops and recovers.<p>Takeaway If you’re trying to make browser agents reliable, the highest‑leverage move isn’t a bigger model. It’s constraining the state space and making success&#x2F;failure explicit with per-step assertions.<p>Reliability in agents comes from verification (assertions on structured snapshots), not just scaling model size.

[Other] Show HN: ChartGPU – WebGPU-powered charting library (1M points at 60fps) Creator here. I built ChartGPU because I kept hitting the same wall: charting libraries that claim to be &quot;fast&quot; but choke past 100K data points.<p>The core insight: Canvas2D is fundamentally CPU-bound. Even WebGL chart libraries still do most computation on the CPU. So I moved everything to the GPU via WebGPU:<p>- LTTB downsampling runs as a compute shader - Hit-testing for tooltips&#x2F;hover is GPU-accelerated - Rendering uses instanced draws (one draw call per series)<p>The result: 1M points at 60fps with smooth zoom&#x2F;pan.<p>Live demo: <a href="https:&#x2F;&#x2F;chartgpu.github.io&#x2F;ChartGPU&#x2F;examples&#x2F;million-points&#x2F;" rel="nofollow">https:&#x2F;&#x2F;chartgpu.github.io&#x2F;ChartGPU&#x2F;examples&#x2F;million-points&#x2F;</a><p>Currently supports line, area, bar, scatter, pie, and candlestick charts. MIT licensed, available on npm: `npm install chartgpu`<p>Happy to answer questions about WebGPU internals or architecture decisions.

[API/SDK] Show HN: UltraContext – A simple context API for AI agents with auto-versioning Hey HN! I&#x27;m Fabio and I built UltraContext, a simple context API for AI agents with automatic versioning.<p>After two years building AI agents in production, I experienced firsthand how frustrating it is to manage context at scale. Storing messages, iterating system prompts, debugging behavior and multi-agent patterns—all while keeping track of everything without breaking anything. It was driving me insane.<p>So I built UltraContext. The mental model is git for context:<p>- Updates and deletes automatically create versions (history is never lost)<p>- Replay state at any point<p>The API is 5 methods:<p><pre><code> uc.create() &#x2F;&#x2F; new context (can fork from existing) uc.append() &#x2F;&#x2F; add message uc.get() &#x2F;&#x2F; retrieve by version, timestamp, or index uc.update() &#x2F;&#x2F; edit message → creates version uc.delete() &#x2F;&#x2F; remove message → creates version </code></pre> Messages are schema-free. Store conversation history, tool calls, system prompts—whatever shape you need. Pass it straight to your LLM using any framework you&#x27;d like.<p>What it&#x27;s for:<p>- Persisting conversation state across sessions<p>- Debugging agent behavior (rewind to decision point)<p>- Forking contexts to test different flows<p>- Audit trails without building audit infrastructure<p>- Multi-agent and sub-agent patterns<p>What it&#x27;s NOT:<p>- Not a memory&#x2F;RAG system (no semantic search)<p>- Not a vector database<p>- Not an Orchestration&#x2F;LLM framework<p>UltraContext handles versioning, branching, history. You get time-travel with one line.<p>Docs: <a href="https:&#x2F;&#x2F;ultracontext.ai&#x2F;docs" rel="nofollow">https:&#x2F;&#x2F;ultracontext.ai&#x2F;docs</a><p>Early access: <a href="https:&#x2F;&#x2F;ultracontext.ai" rel="nofollow">https:&#x2F;&#x2F;ultracontext.ai</a><p>Would love feedback! Especially from anyone who&#x27;s rolled their own context engineering and can tell me what I&#x27;m missing.

[Other] Nested Code Fences in Markdown

[Other] Show HN: Generate animated solar system timelapse videos for any date range A fork of Solar System Live that generates animated videos showing planetary orbits over any date range. Tracks orbital statistics (how many times Earth was lapped by Mercury&#x2F;Venus, or lapped outer planets) and overlays dates&#x2F;ages on each frame.<p>Example: Einstein&#x27;s lifetime (1879-1955) showing 76 years of solar system evolution. Built with Python + Pillow + ffmpeg, runs locally with Lighttpd.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;simondorfman&#x2F;solar_system_live" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;simondorfman&#x2F;solar_system_live</a>

[Other] Show HN: macOS native DAW with Git branching model I am working on building (and have made my first prerelease) for a Digital Audio Workstation with git like branching version control.<p>It&#x27;s free for local use and paid for cloud syncing or collaboration.

[Other] Claude Chill: Fix Claude Code's flickering in terminal

[CLI Tool] Show HN: Fence – Sandbox CLI commands with network/filesystem restrictions Hi HN!<p>Fence wraps any command in a sandbox that blocks network by default and restricts filesystem writes. Useful for running semi-trusted code (package installs, build scripts, unfamiliar repos) with controlled side effects, or even just blocking tools that phone home.<p>&gt; fence curl <a href="https:&#x2F;&#x2F;example.com" rel="nofollow">https:&#x2F;&#x2F;example.com</a> # -&gt; blocked<p>&gt; fence -t code -- npm install # -&gt; template with registries allowed<p>&gt; fence -m -- npm install # -&gt; monitor mode: see what gets blocked<p>One use-case is to use it with AI coding agents to reduce the risk of running agents with fewer interactive permission prompts:<p>&gt; fence -t code -- claude --dangerously-skip-permissions<p>You can import existing Claude Code permissions with `fence import --claude`.<p>Fence uses OS-native sandboxing (macOS sandbox-exec, Linux bubblewrap) + local HTTP&#x2F;SOCKS proxies for domain filtering.<p>Why I built this: I work on Tusk Drift, a system to record and replay real traffic as API tests (<a href="https:&#x2F;&#x2F;github.com&#x2F;Use-Tusk&#x2F;tusk-drift-cli" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Use-Tusk&#x2F;tusk-drift-cli</a>). I needed a way to sandbox the service under test during replays to block localhost outbound connections (Postgres, Redis) and force the app to use mocks instead of real services. I quickly realized that this could be a general purpose tool that would also be useful as a permission manager across CLI agents.<p>Limitations: Not strong containment against malware. Proxy-based filtering requires programs to respect `HTTP_PROXY`.<p>Curious if others have run into similar needs, and happy to answer any questions!

[API/SDK] Show HN: Mastra 1.0, open-source JavaScript agent framework from the Gatsby devs Hi HN, we&#x27;re Sam, Shane, and Abhi.<p>Almost a year ago, we first shared Mastra here (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43103073">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43103073</a>). It’s kind of fun looking back since we were only a few months into building at the time. The HN community gave a lot of enthusiasm and some helpful feedback.<p>Today, we released Mastra 1.0 in stable, so we wanted to come back and talk about what’s changed.<p>If you’re new to Mastra, it&#x27;s an open-source TypeScript agent framework that also lets you create multi-agent workflows, run evals, inspect in a local studio, and emit observability.<p>Since our last post, Mastra has grown to over 300k weekly npm downloads and 19.4k GitHub stars. It’s now Apache 2.0 licensed and runs in prod at companies like Replit, PayPal, and Sanity.<p>Agent development is changing quickly, so we’ve added a lot since February:<p>- Native model routing: You can access 600+ models from 40+ providers by specifying a model string (e.g., `openai&#x2F;gpt-5.2-codex`) with TS autocomplete and fallbacks. - Guardrails: Low-latency input and output processors for prompt injection detection, PII redaction, and content moderation. The tricky thing here was the low-latency part. - Scorers: An async eval primitive for grading agent outputs. Users were asking how they should do evals. We wanted to make it easy to attach to Mastra agents, runnable in Mastra studio, and save results in Mastra storage. - Plus a few other features like AI tracing (per-call costing for Langfuse, Braintrust, etc), memory processors, a `.network()` method that turns any agent into a routing agent, and server adapters to integrate Mastra within an existing Express&#x2F;Hono server.<p>(That last one took a bit of time, we went down the ESM&#x2F;CJS bundling rabbithole, ran into lots of monorepo issues, and ultimately opted for a more explicit approach.)<p>Anyway, we&#x27;d love for you to try Mastra out and let us know what you think. You can get started with `npm create mastra@latest`.<p>We&#x27;ll be around and happy to answer any questions!

[API/SDK] Show HN: Ocrbase – pdf → .md/.json document OCR and structured extraction API

[Other] Workspaces and Monorepos in Package Managers

[Code Quality] Show HN: LangGraph architecture that scales (hexagonal pattern, 110 tests) I kept hitting the same wall with LangGraph: tutorials show you how to build a graph, not how to maintain one when you have 8 nodes, 3 agents, and shared state across subgraphs.<p>So I built a reference architecture with: - Platform layer separation (framework-independent core) - Contract validation on every state mutation - 110 tests including architecture boundary enforcement - Patterns that AI coding agents can&#x27;t accidentally break<p>Repo: <a href="https:&#x2F;&#x2F;github.com&#x2F;cleverhoods&#x2F;sagecompass" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cleverhoods&#x2F;sagecompass</a> Wrote about the patterns: <a href="https:&#x2F;&#x2F;dev.to&#x2F;cleverhoods&#x2F;from-prompt-to-platform-architecture-rules-i-use-59gp" rel="nofollow">https:&#x2F;&#x2F;dev.to&#x2F;cleverhoods&#x2F;from-prompt-to-platform-architect...</a><p>It&#x27;s MIT licensed. Would love feedback on the approach - especially from anyone who&#x27;s scaled LangGraph past the tutorial stage.

[Other] Linux kernel framework for PCIe device emulation, in userspace

[Other] KAOS – The Kubernetes Agent Orchestration System

[Other] Show HN: Txt2plotter – True centerline vectors from Flux.2 for pen plotters I’ve been working on a project to bridge the gap between AI generation and my AxiDraw, and I think I finally have a workflow that avoids the usual headaches.<p>If you’ve tried plotting AI-generated images, you probably know the struggle: generic tracing tools (like Potrace) trace the <i>outline</i> of a line, resulting in double-strokes that ruin the look and take twice as long to plot.<p>What I tried previously:<p>- Potrace &#x2F; Inkscape Trace: Great for filled shapes, but results in &quot;hollow&quot; lines for line art.<p>- Canny Edge Detection: Often too messy; it picks up noise and creates jittery paths.<p>- Standard SDXL: Struggled with geometric coherence, often breaking lines or hallucinating perspective.<p>- A bunch of projects that claimed to be txt2svg but which produced extremely poor results, at least for pen plotting. (Chat2SVG, StarVector, OmniSVG, DeepSVG, SVG-VAE, VectorFusion, DiffSketcher, SVGDreamer, SVGDreamer++, NeuralSVG, SVGFusion, VectorWeaver, SwiftSketch, CLIPasso, CLIPDraw, InternSVG)<p>My Approach:<p>I ended up writing a Python tool that combines a few specific technologies to get a true &quot;centerline&quot; vector:<p>1. Prompt Engineering: An LLM rewrites the prompt to enforce a &quot;Technical Drawing&quot; style optimized for the generator.<p>2. Generation: I&#x27;m using Flux.2-dev (4-bit). It seems significantly better than SDXL at maintaining straight lines and coherent geometry.<p>3. Skeletonization: This is the key part. Instead of tracing contours, I use Lee’s Method (via scikit-image) to erode the image down to a 1-pixel wide skeleton. This recovers the actual stroke path.<p>4. Graph Conversion: The pixel skeleton is converted into a graph to identify nodes and edges, pruning out small artifacts&#x2F;noise.<p>5. Optimization: Finally, I feed it into vpype to merge segments and sort the paths (TSP) so the plotter isn&#x27;t jumping around constantly.<p>You can see the results in the examples inside the Github repo.<p>The project is currently quite barebones, but it produces better results than other options I&#x27;ve tested so I&#x27;m publishing it. I&#x27;m interested in implementing better pre&#x2F;post processing, API-based generation, and identifying shapes for cross-hatching.

[Other] Show HN: Subth.ink – write something and see how many others wrote the same Hey HN, this is a small Haskell learning project that I wanted to share. It&#x27;s just a website where you can see how many people write the exact same text as you (thought it was a fun idea).<p>It&#x27;s built using Scotty, SQLite, Redis and Caddy. Currently it&#x27;s running in a small DigitalOcean droplet (1 Gb RAM).<p>Using Haskell for web development (specifically with Scotty) was slightly easier than I thought, but still a relatively hard task compared to other languages. One of my main friction points was Haskell&#x27;s multiple string-like types: String, Text (&amp; lazy), ByteString (&amp; lazy), and each library choosing to consume a different one amongst these. There is also a soft requirement to learn monad transformers (e.g. to understand what liftIO is doing) which made the initial development more difficult.

[Other] Show HN: Pipenet – A Modern Alternative to Localtunnel Hey HN!<p>localtunnel&#x27;s server needs random ports per client. That doesn&#x27;t work on Fly.io or behind strict firewalls.<p>We rewrote it in TypeScript and added multiplexing over a single port. Open-source and 100% self-hostable.<p>Public instance at *.pipenet.dev if you don&#x27;t want to self-host.<p>Built at Glama for our MCP Inspector, but it&#x27;s a generic tunnel with no ties to our infra.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;punkpeye&#x2F;pipenet" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;punkpeye&#x2F;pipenet</a>