The best Hacker News stories from Show from the past day
Latest posts:
Show HN: StackScope – I crawled over 40k indie launches to see what they ship
Hey all, I built StackScope, a crawler/catalogue that looks at new product launches and shows what they were built with.<p>It watches launches from Product Hunt, Show HN, and PeerPush, then crawls the public site behind each one. The goal is to show what people actually launched with: hosting, frameworks, analytics, DNS, security headers, legal pages, AI-builder signals, and other public clues.<p>I started building it because most stack-detection sites look at the web as a whole. I was more interested in the current indie launch scene: what people are choosing right now, at the point they first put something in public.<p>A few implementation details: it runs on .NET, uses Playwright for rendered pages, and has a first-party fingerprint catalogue rather than one copied from Wappalyzer/etc. robots.txt is honoured, and the bot identifies itself.<p>Frustratingly, I am still waiting for verified bot status from Cloudflare and currently that knocks out about 10% of all sites.<p>There is also a private readiness check: paste a URL, get the same style of report, fix things, and recrawl. No account or email needed.<p>I'd be interested in feedback on the usefulness of this, the methodology, and any obvious false positives.<p>Jonathan.
Show HN: Script to bulk delete Claude chats from the web UI
I haven't found a way to delete all chats in bulk like you can on Chatgpt. With Claude, you have to scroll to the bottom, select everything, and delete. The problem is, if you have a lot of chats, it becomes impossible. I created this script. It does it alone. I hope it helps someone.<p>(conversations disappear from the UI slowly, over several minutes, and remember to keep the tab open until the console shows "Finished", refreshing away from the page can stop the deletion process.)
Show HN: Putt.day a daily mini golf game
Show HN: Atlasphere – Live Infrastructure Diagrams
Hi HN. My name is Andrey. On a regular business day, I'm a software engineer working at AWS. Outside of work hours, I spend time on my hobby - writing code.<p>I was once building a pet project that allowed customers to spin up fully synchronized blockchain nodes within just a few minutes. The backend was split into a control plane and a data plane, each with its own AWS account. Later I added two more AWS accounts. One for shared RPC nodes. One for the Analytics Service.<p>Since I love to visualize things, I used drawio to visualize the architecture.<p>With time, I noticed a pattern. I'd write some code, add a few lambda functions, update my drawio diagram, write more code, introduce a few more resources, test things, see that everything works fine and go to sleep with a smile on my face. Next week I'd check my diagram, and shockingly, it's missing some of the resources! This kept happening for a few more weeks until I decided to fully abandon the project until my infrastructure diagrams could stay in sync with my cloud account.<p>That's how Atlasphere.io was born. I've been working on it for the past 6 months and I think the product is ready for some feedback :)<p>A few notes:<p>- Atlasphere uses a ReadOnly IAM role to scan your AWS account (my account reaches your account through a trust relationship).<p>- The number of services is currently limited (WIP)<p>- It's a macOS app<p>- It's NOT an Electron app, i use Rust + Webview<p>What am I looking for? All I really need is for someone to try the app and tell me what they like about it and what they absolutely hate about it, haha!<p>The website is <a href="https://atlasphere.io/" rel="nofollow">https://atlasphere.io/</a>
Show HN: Boo – Screen-style terminal multiplexer built on libghostty
Show HN: Boo – Screen-style terminal multiplexer built on libghostty
Show HN: Claw Patrol, a security firewall for agents
At Deno we've been using OpenClaw and other agents increasingly for addressing production problems in Deno Deploy - when a PagerDuty alert fires, the agent starts researching the cause and making fixes.<p>In order to do this, the agent needs access to real production systems - postgres, kubernetes, gcp, clickhouse, github, etc. But this is dangerous to say the least - we want destructive actions to be reviewed by other LLMs, approved by humans, and logged appropriately.<p>Claw Patrol terminates TCP connections over WireGuard or Tailscale, then parses application protocols (eg http, postgres, ssh) to apply rules that allow you to deny/allow requests.<p>There are a few projects that sit as a proxy in front of agents to do secret injection or apply various guardrails, but none met our needs (LLM gateways, MCP proxies, sandboxes), particularly the need to handle low-level protocols, or handle complex real world situations like tunneling postgres through k8s.<p>Written in Go, configured in HCL, MIT licensed. Happy to answer any questions.<p><a href="https://clawpatrol.dev/" rel="nofollow">https://clawpatrol.dev/</a>
Show HN: Claw Patrol, a security firewall for agents
At Deno we've been using OpenClaw and other agents increasingly for addressing production problems in Deno Deploy - when a PagerDuty alert fires, the agent starts researching the cause and making fixes.<p>In order to do this, the agent needs access to real production systems - postgres, kubernetes, gcp, clickhouse, github, etc. But this is dangerous to say the least - we want destructive actions to be reviewed by other LLMs, approved by humans, and logged appropriately.<p>Claw Patrol terminates TCP connections over WireGuard or Tailscale, then parses application protocols (eg http, postgres, ssh) to apply rules that allow you to deny/allow requests.<p>There are a few projects that sit as a proxy in front of agents to do secret injection or apply various guardrails, but none met our needs (LLM gateways, MCP proxies, sandboxes), particularly the need to handle low-level protocols, or handle complex real world situations like tunneling postgres through k8s.<p>Written in Go, configured in HCL, MIT licensed. Happy to answer any questions.<p><a href="https://clawpatrol.dev/" rel="nofollow">https://clawpatrol.dev/</a>
Show HN: FablePool – pool money behind a prompt, and Fable builds it in public
Show HN: FablePool – pool money behind a prompt, and Fable builds it in public
Show HN: Homebrew 6.0.0
Today, I’m proud to announce Homebrew 6.0.0. The most significant changes since 5.1.0 are a new tap trust security mechanism, the new faster, smaller, default internal Homebrew JSON API, sandboxing on Linux, better defaults informed by our user survey, many brew bundle improvements, improved performance and initial support for macOS 27 (Golden Gate).<p>Happy to discuss any questions here!
Show HN: Homebrew 6.0.0
Today, I’m proud to announce Homebrew 6.0.0. The most significant changes since 5.1.0 are a new tap trust security mechanism, the new faster, smaller, default internal Homebrew JSON API, sandboxing on Linux, better defaults informed by our user survey, many brew bundle improvements, improved performance and initial support for macOS 27 (Golden Gate).<p>Happy to discuss any questions here!
Show HN: Resonate – Low-latency, high-resolution spectral analysis
Last April I shared about my Resonate project here (<a href="https://news.ycombinator.com/item?id=43694157">https://news.ycombinator.com/item?id=43694157</a>)<p>A lot has happened since: the work I presented in much more detail at last June's International Computer Music Conference (ICMC) got best paper award. I also gave a talk at the Audio Developer Conference in Bristol last November, the video is on YouTube).<p>This year's work, which I recently presented at this year's ICMC, starts with known techniques from the phase vocoder literature to build self-tuning filter banks that extract very efficiently the frequency components that are actually present in the input signal. Overview on the project website, more details in the papers, including applications to super-resolution spectrograms and re-synthesis experiments.<p>As many people have pointed out, none of the techniques I have used are new (some of them even have different names across different fields), but I haven't seen them applied together in this way, and to me the results are incredibly satisfying and sometimes look magical. See for example this demo: <a href="https://youtu.be/LasdoIJJkw8" rel="nofollow">https://youtu.be/LasdoIJJkw8</a><p>Of course the best way to experience in person is through the free demo app: <a href="https://alexandrefrancois.org/Oscillators" rel="nofollow">https://alexandrefrancois.org/Oscillators</a><p>Looking forward to feedback from the community!
Show HN: macOS menu bar gauges for your Claude Code quota
Show HN: macOS menu bar gauges for your Claude Code quota
Show HN: HelixDB – A graph database built on object storage
Hey HN, it’s been just over a year since we launched HelixDB (<a href="https://news.ycombinator.com/item?id=43975423">https://news.ycombinator.com/item?id=43975423</a>), a project a friend and I started in college. It’s an OLTP graph database built on object-storage, with native vector search and full-text search (FTS).<p>Why graph, vector and FTS? Graph databases provide a natural cognitive model for data, vectors allow for a semantic understanding of the entities and relationships in the graph, and FTS provides more specific filtering. Many AI-driven applications attempt to combine all of these functionalities by stitching together multiple disconnected systems, but even then there’s no native way to perform joins or queries that span all systems. You still need to handle this logic at the application level.<p>Helix started as a graph DB, but we moved to a hybrid graph/vector approach after attempting to build an AI memory system, which led us down the GraphRAG and HybridRAG rabbit hole, where we would need separate graph and vector databases.<p>We knew scalability would be a challenge at each stage of our product's development, however our initial focus this past year was to prove out the product through local deployments and was only meant to be run on a single node. Scaling graph DBs remained a difficult and expensive problem we’d have to solve later.
Some common ways other graph DBs solve scaling is by duplicating entire datasets across distributed machines (extremely expensive per node), or by sharding the data.<p>Sharding databases is effective and affordable, however, graph data doesn’t have explicit partitions like relational databases do. For example, sharding a relational DB involves splitting up tables. When it comes to graph DBs, the edges can span across any of the partitions, and hopping across multiple machines when traversing nodes is ineffective and computationally expensive.<p>Replicating graph DBs for high availability and better throughput drastically increases the operational cost of the db and still has a limit of how big you can vertically scale. The workload that we’re used for requires storing a huge amount of data for agents, where only a subset of that data is ever needed at any one time. So rather than having the whole thing in memory, we can store it all in object-storage and get the bits we need when they’re needed.<p>Agents benefit from better context, which is achieved from more and better data (more relationships etc). By using S3 as the persistence/data layer there is <i>no limit</i> to how big the graph can be or how many relationships you can have, and we can scale to serve throughput and requests by horizontally spinning up nodes and caching relevant subsets of the graph on each node. This way, you get extremely low latency for “hot” data and a p99 of ~100ms for writes and ~50ms for reads from cold storage (S3). Plus you get the benefit of dirt cheap storage.<p>Workloads that HelixDB is currently supporting:
- Huge amounts of data (TBs) from which the agents need to search and traverse over
- Offering affordable graph storage for companies where cost of graph data is a bottleneck
- Consolidating multiple databases, enabling AI agents to have autonomy over companies, helping them become more autonomous.
- AI memory
- Company brains<p>We’re currently working on our own generalised AI memory layer which will use HelixDB under the hood and be completely open-source. Also, we’re finishing up on pre-filtering for vector search which will allow you to pre-filter based on relationships in the graph, metadata, and sub-graphs. And lastly, GA cloud will be available in the coming weeks.<p>If you want to run Helix locally (either on-disk or in-memory), you can find more info on our github (<a href="https://github.com/HelixDB/helix-db" rel="nofollow">https://github.com/HelixDB/helix-db</a>) or via our docs (<a href="https://docs.helix-db.com/database/local-development">https://docs.helix-db.com/database/local-development</a>). If you’re interested in getting started with our distributed cloud, please email us founders@helix-db.com.<p>Many thanks! Comments and feedback welcome!
Show HN: HelixDB – A graph database built on object storage
Hey HN, it’s been just over a year since we launched HelixDB (<a href="https://news.ycombinator.com/item?id=43975423">https://news.ycombinator.com/item?id=43975423</a>), a project a friend and I started in college. It’s an OLTP graph database built on object-storage, with native vector search and full-text search (FTS).<p>Why graph, vector and FTS? Graph databases provide a natural cognitive model for data, vectors allow for a semantic understanding of the entities and relationships in the graph, and FTS provides more specific filtering. Many AI-driven applications attempt to combine all of these functionalities by stitching together multiple disconnected systems, but even then there’s no native way to perform joins or queries that span all systems. You still need to handle this logic at the application level.<p>Helix started as a graph DB, but we moved to a hybrid graph/vector approach after attempting to build an AI memory system, which led us down the GraphRAG and HybridRAG rabbit hole, where we would need separate graph and vector databases.<p>We knew scalability would be a challenge at each stage of our product's development, however our initial focus this past year was to prove out the product through local deployments and was only meant to be run on a single node. Scaling graph DBs remained a difficult and expensive problem we’d have to solve later.
Some common ways other graph DBs solve scaling is by duplicating entire datasets across distributed machines (extremely expensive per node), or by sharding the data.<p>Sharding databases is effective and affordable, however, graph data doesn’t have explicit partitions like relational databases do. For example, sharding a relational DB involves splitting up tables. When it comes to graph DBs, the edges can span across any of the partitions, and hopping across multiple machines when traversing nodes is ineffective and computationally expensive.<p>Replicating graph DBs for high availability and better throughput drastically increases the operational cost of the db and still has a limit of how big you can vertically scale. The workload that we’re used for requires storing a huge amount of data for agents, where only a subset of that data is ever needed at any one time. So rather than having the whole thing in memory, we can store it all in object-storage and get the bits we need when they’re needed.<p>Agents benefit from better context, which is achieved from more and better data (more relationships etc). By using S3 as the persistence/data layer there is <i>no limit</i> to how big the graph can be or how many relationships you can have, and we can scale to serve throughput and requests by horizontally spinning up nodes and caching relevant subsets of the graph on each node. This way, you get extremely low latency for “hot” data and a p99 of ~100ms for writes and ~50ms for reads from cold storage (S3). Plus you get the benefit of dirt cheap storage.<p>Workloads that HelixDB is currently supporting:
- Huge amounts of data (TBs) from which the agents need to search and traverse over
- Offering affordable graph storage for companies where cost of graph data is a bottleneck
- Consolidating multiple databases, enabling AI agents to have autonomy over companies, helping them become more autonomous.
- AI memory
- Company brains<p>We’re currently working on our own generalised AI memory layer which will use HelixDB under the hood and be completely open-source. Also, we’re finishing up on pre-filtering for vector search which will allow you to pre-filter based on relationships in the graph, metadata, and sub-graphs. And lastly, GA cloud will be available in the coming weeks.<p>If you want to run Helix locally (either on-disk or in-memory), you can find more info on our github (<a href="https://github.com/HelixDB/helix-db" rel="nofollow">https://github.com/HelixDB/helix-db</a>) or via our docs (<a href="https://docs.helix-db.com/database/local-development">https://docs.helix-db.com/database/local-development</a>). If you’re interested in getting started with our distributed cloud, please email us founders@helix-db.com.<p>Many thanks! Comments and feedback welcome!
Show HN: HelixDB – A graph database built on object storage
Hey HN, it’s been just over a year since we launched HelixDB (<a href="https://news.ycombinator.com/item?id=43975423">https://news.ycombinator.com/item?id=43975423</a>), a project a friend and I started in college. It’s an OLTP graph database built on object-storage, with native vector search and full-text search (FTS).<p>Why graph, vector and FTS? Graph databases provide a natural cognitive model for data, vectors allow for a semantic understanding of the entities and relationships in the graph, and FTS provides more specific filtering. Many AI-driven applications attempt to combine all of these functionalities by stitching together multiple disconnected systems, but even then there’s no native way to perform joins or queries that span all systems. You still need to handle this logic at the application level.<p>Helix started as a graph DB, but we moved to a hybrid graph/vector approach after attempting to build an AI memory system, which led us down the GraphRAG and HybridRAG rabbit hole, where we would need separate graph and vector databases.<p>We knew scalability would be a challenge at each stage of our product's development, however our initial focus this past year was to prove out the product through local deployments and was only meant to be run on a single node. Scaling graph DBs remained a difficult and expensive problem we’d have to solve later.
Some common ways other graph DBs solve scaling is by duplicating entire datasets across distributed machines (extremely expensive per node), or by sharding the data.<p>Sharding databases is effective and affordable, however, graph data doesn’t have explicit partitions like relational databases do. For example, sharding a relational DB involves splitting up tables. When it comes to graph DBs, the edges can span across any of the partitions, and hopping across multiple machines when traversing nodes is ineffective and computationally expensive.<p>Replicating graph DBs for high availability and better throughput drastically increases the operational cost of the db and still has a limit of how big you can vertically scale. The workload that we’re used for requires storing a huge amount of data for agents, where only a subset of that data is ever needed at any one time. So rather than having the whole thing in memory, we can store it all in object-storage and get the bits we need when they’re needed.<p>Agents benefit from better context, which is achieved from more and better data (more relationships etc). By using S3 as the persistence/data layer there is <i>no limit</i> to how big the graph can be or how many relationships you can have, and we can scale to serve throughput and requests by horizontally spinning up nodes and caching relevant subsets of the graph on each node. This way, you get extremely low latency for “hot” data and a p99 of ~100ms for writes and ~50ms for reads from cold storage (S3). Plus you get the benefit of dirt cheap storage.<p>Workloads that HelixDB is currently supporting:
- Huge amounts of data (TBs) from which the agents need to search and traverse over
- Offering affordable graph storage for companies where cost of graph data is a bottleneck
- Consolidating multiple databases, enabling AI agents to have autonomy over companies, helping them become more autonomous.
- AI memory
- Company brains<p>We’re currently working on our own generalised AI memory layer which will use HelixDB under the hood and be completely open-source. Also, we’re finishing up on pre-filtering for vector search which will allow you to pre-filter based on relationships in the graph, metadata, and sub-graphs. And lastly, GA cloud will be available in the coming weeks.<p>If you want to run Helix locally (either on-disk or in-memory), you can find more info on our github (<a href="https://github.com/HelixDB/helix-db" rel="nofollow">https://github.com/HelixDB/helix-db</a>) or via our docs (<a href="https://docs.helix-db.com/database/local-development">https://docs.helix-db.com/database/local-development</a>). If you’re interested in getting started with our distributed cloud, please email us founders@helix-db.com.<p>Many thanks! Comments and feedback welcome!
Show HN: Extend UI – open-source UI kit for modern document apps
We're open-sourcing 14 components & examples today for PDF, DOCX, and XLSX viewers, plus bounding box citations, file upload, e-signature, and more. It's MIT licensed and fully customizable.<p>Demo video here: <a href="https://share.extend.ai/kRmSGKRF">https://share.extend.ai/kRmSGKRF</a><p>When we started, we tried every file viewer and document component library we could find. Unfortunately, none of them had all the functionality (and polish) that we wanted, so we ended up building our own for <a href="https://extend.ai/">https://extend.ai/</a>. It was only ever meant to be internal, but enough customers kept asking for it that we decided to open source it.<p>It's useful for building document processing agents, real-time user facing document intake flows, or all kinds of internal tooling.<p>We naively thought this would be a solved problem. Turns out, making PDF/XLSX/DOCX viewers that work at scale is not trivial...we use and maintain it for Extend ourselves, so we've fixed a lot of edge cases that came up while running millions of pages / day through our own system. Our hope is that with our resources + community support, it'll keep getting better over time.
Show HN: Extend UI – open-source UI kit for modern document apps
We're open-sourcing 14 components & examples today for PDF, DOCX, and XLSX viewers, plus bounding box citations, file upload, e-signature, and more. It's MIT licensed and fully customizable.<p>Demo video here: <a href="https://share.extend.ai/kRmSGKRF">https://share.extend.ai/kRmSGKRF</a><p>When we started, we tried every file viewer and document component library we could find. Unfortunately, none of them had all the functionality (and polish) that we wanted, so we ended up building our own for <a href="https://extend.ai/">https://extend.ai/</a>. It was only ever meant to be internal, but enough customers kept asking for it that we decided to open source it.<p>It's useful for building document processing agents, real-time user facing document intake flows, or all kinds of internal tooling.<p>We naively thought this would be a solved problem. Turns out, making PDF/XLSX/DOCX viewers that work at scale is not trivial...we use and maintain it for Extend ourselves, so we've fixed a lot of edge cases that came up while running millions of pages / day through our own system. Our hope is that with our resources + community support, it'll keep getting better over time.