Show stories

Over the past year I’ve been building a set of operational panels for Django:

- Redis inspection - cache visibility - Celery task introspection - URL discovery and testing

All of these tools have been built inside the Django admin.

Instead of jumping between tools like Flower, redis-cli, Swagger, or external services, I wanted something that sits where I’m already working.

I’ve grouped these under a single umbrella: Django Control Room.

The idea is pretty simple: the Django admin already gives you authentication, permissions, and a familiar interface. It can also act as an operational layer for your app.

Each panel is just a small Django app with a simple interface, so it’s easy to build your own and plug it in.

I’m working on more panels (signals, errors, etc.) and also thinking about how far this pattern can go.

Curious how others think about this. Does it make sense to consolidate this kind of tooling inside the admin, or do you prefer keeping it separate?

I've liked all the projects that put LLMs into game environments. It's been a weird juxtaposition, though: frontier LLMs can one-shot full coding projects, and those same models struggle to get out of Pokémon Red's Mt. Moon.

Because of this, I wanted to create a game environment that put this generation of frontier LLMs' top skill, coding, on full display.

Ten years ago, a team released a game called Screeps. It was described as an "MMO RTS sandbox for programmers." The Screeps paradigm of writing code and having it executed in a real-time game environment is well suited to LLMs. Drawing on a version of the Screeps open source API, LLM Skirmish pits LLMs head-to-head in a series of 1v1 real-time strategy games.

In my testing I found that Claude Opus 4.5 was the most dominant model, but it showed weakness in round 1 as it was overly focused on its in-game economy. Meanwhile, I probably spent a third of all code on sandbox hardening because GPT 5.2 kept trying to cheat by pre-reading its opponent's strategies.

If there's interest, I'm planning on doing a round of testing with the latest generation of LLMs (Claude 4.6 Opus, GPT 5.3 Codex, etc.).

You can run local matches via CLI. I'm running a hosted match runner with Google Cloud Run that uses isolated-vm. The match playback visualizer is statically served from Cloudflare.

I've created a community ladder that you can submit strategies to via CLI, no auth required. I've found that the CLI plus the skill.md that's available has been enough for AI agents to immediately get started.

Website: https://llmskirmish.com

API docs: https://llmskirmish.com/docs

GitHub: https://github.com/llmskirmish/skirmish

A video of a match: https://www.youtube.com/watch?v=lnBPaZ1qamM

Hey HN,

We built Sgai to experiment with a different model of AI-assisted development.

Instead of prompting step-by-step, you define an outcome in GOAL.md (what should be built, not how), and Sgai runs a coordinated set of AI agents to execute it.

- It decomposes the goal into a DAG of roles (developer → reviewer → safety analyst, etc.) - It asks clarifying questions when needed - It writes code, runs tests, and iterates - Completion gates (e.g. make test) determine when it's actually done

Everything runs locally in your repo. There’s a web dashboard showing real-time execution of the agent graph. Nothing auto-pushes to GitHub.

We’ve used it internally for prototyping small apps and internal tooling. It’s still early and rough in places, but functional enough to share.

Demo (4 min): https://youtu.be/NYmjhwLUg8Q GitHub: https://github.com/sandgardenhq/sgai

Open source (Go). Works with Anthropic, OpenAI, or local models via opencode.

Curious what people think about DAG-based multi-agent workflows for coding. Has anyone here experimented with similar approaches?

I wanted to share our new speech to text model, and the library to use them effectively. We're a small startup (six people, sub-$100k monthly GPU budget) so I'm proud of the work the team has done to create streaming STT models with lower word-error rates than OpenAI's largest Whisper model. Admittedly Large v3 is a couple of years old, but we're near the top the HF OpenASR leaderboard, even up against Nvidia's Parakeet family. Anyway, I'd love to get feedback on the models and software, and hear about what people might build with it.

I'm integrating the Yara-x rules engine into my C# hex editor. I'm working to maximize the performance and efficiency of the integration. I'd like to ask your opinion about this. I personally made this decision to expand the functionality of my hex editor by adding Yara-x support. This allows me to search for signatures in binary files in more detail. I think viewing the entire byte grid can help in malware research.

I implemented this using memory mapping files. I also divided the scanning methods into modes: small files are mapped completely, while large files are scanned in 16MB chunks with a small 64KB overlay to prevent a situation where half the signature is in one chunk and half is in another. I also used smarter memory management for performance with large files. Documentation is in the readme. But in short, this is an implementation that doesn't overload the garbage collector in C# and handles unsafe pointers and raw memory addresses. What's important is that I now have protection against bad rules that, for example, search for any byte, overloading the scanner. Such rules won't work, and the scanner will stop scanning so that the scanner doesn't crash with an error.

I can't say right now that this tool could be better than the others, because it's currently in development and I still have room for improvement, but it would be cool to hear people's opinions or accept other people's ideas for improving the tool.

(The native version with Yarax is not yet available in current releases, but the source code is available and you can compile or read it yourself.)

Hi HN,

I built well-net: https://github.com/remoon-net/well

Think tsnet, but without Tailscale or any central server. It’s for secure friend networks — chat, small games, private services.

Existing systems suck in subtle ways: lose your domain → lose your identity and contacts. Delta Chat and Mastodon show the problem. I just want something that works without any central coordination.

Each node gets a stable IPv6 in 2001:00ff::/32 from its MAC using EUI-64. Real MACs → no collisions, no central server needed. NAT is only to avoid overlay address conflicts.

Tech: WireGuard + WebRTC → runs in browsers. Once WebRTC DataChannel works in Service Workers, private services can be accessed directly from the web.

Planned: minimal mail-based chat using Delta Chat with IP-literal addresses like remoon@[2001:ff::1] → DNS-free identity.

Project is experimental.

Would you use this for small friend networks?

Scheme-langserver digest incomplete Scheme code to serve real-world programming requirements, including goto-definition, auto-completion, type inference and such many LSP-defined language feature supports. And this project is based here(https://github.com/ufo5260987423/scheme-langserver).

I built it because I was tired of Scheme/Lisp's raggy development environment, especially of the lack of IDE-like highly customized programing experience. Though DrRacket and many REPL-based counterparts have don't much, following general cases aren't reach same-level as in other modern languages: (let* ([ready-for-reference 1]

         [call-reference (+ ready-for-)]))

If you want some further information, you may refer my github repository in which has a screen-record video showing how you code get help from this project and this project has detailed documentation so don't hesitate and use it.

Here're some other things sharing to Hacker News readers:

1. Why I don't use DrRacket: LSP follows KISS(Keep It Simple, Stupid) principle and I don't want to be involved with font things as I just read in its github issues.

2. What's the newest stage of scheme-langserve: It achieves kind of self-boost, in which stage I can continue develop it with its VScode plugin help. However, I directly used Chez Scheme's tokenizer and this leaded to several un-caught exceptions whom I promise to be fixed in the future, but I'm occupied with developing new feature. If you feel something wrong with scheme-langserver, you may reboot vscode, generally this always work.

3. Technology road map: I'm now developing a new macro expander so that the users can customize LSP behavior by coding their own macro and without altering this project. After this, I have a plan to improve efficiency and fix bugs. 4. Do I need any help: Yes. And I'd like to say, talking about scheme-langserver with me is also a kind of help.

5. Long-term View: I suspect 2 or 3 years later I will lose concentration on this project but according some of my friends, I may integrate this project with other fantastic work.

Scalodb is an open-source distributed database system that focuses on scalability, high availability, and fault tolerance. It provides a key-value store with support for transactions and secondary indexes, making it suitable for a variety of applications.

Hey HN! We’re Arne and Raban, the founders of Emdash (https://github.com/generalaction/emdash).

Emdash is an open-source and provider-agnostic desktop app that lets you run multiple coding agents in parallel, each isolated in its own git worktree, either locally or over SSH on a remote machine. We call it an Agentic Development Environment (ADE).

You can see a 1 minute demo here: https://youtu.be/X31nK-zlzKo

We are building Emdash for ourselves. While working on a cap-table management application (think Stripe Atlas + Pulley), we found our development workflow to be messy: lots of terminals, lots of branches, and too much time spent waiting on Codex.

Emdash puts the terminal at the center and makes it easy to run multiple agents at once. Each agent runs as a task in its own git worktree. You can start one or a few agents on the same problem, test, and review.

Emdash works over SSH so you can run agents where your code lives and keep the parallel workflow. You can assign tickets to agents, edit files manually, and review changes.

We also spent time making task startup fast. Each task can be created in a worktree, and creating worktrees on demand was taking 5s+ in some cases. We now keep a small reserve of worktrees in the background and let a new task claim one instantly. That brought task start time down to ~500–1000ms depending on the provider. We also spawn the shell directly and avoid loading the shell environments on startup.

We believe using the providers’ native CLIs is the right approach. It gives you the full capabilities of each agent, always. If a provider starts supporting plan mode, we don't have to add that first.

We support 21 coding agent CLIs today, including Claude Code, Codex, Gemini, Droid, Amp, Codebuff, and more. We auto-detect what you have installed and we’re provider-agnostic by design. If there’s a provider you want that we don’t support yet, we can add it. We believe that in the future, some agents will be better suited for task X and others for task Y. Codex, Claude Code, and Gemini all have fans. We want to be agnostic and enable individuals and teams to freely switch between them.

Beyond orchestration, we try to pull most of the development loop into Emdash. You can review diffs, commit, open PRs, see CI/CD checks, and merge directly from Emdash once checks pass. When starting a task, you can pass issues from Linear, GitHub, and Jira to an agent. We also support convenience variables and lifecycle scripts so it’s easy to allocate ports and test changes.

Emdash is fully open-source and MIT-licensed.

Download for macOS, Linux or Windows (as of yesterday !), or install via Homebrew: brew install --cask emdash.

We’d love your feedback. How does your coding agent development setup look like, especially when working with multiple agents? We would want to learn more about it. Check out our repository here: https://github.com/generalaction/emdash

We’ll be around in the comments — thanks!

I built Match, a pattern matching language designed to replace regex. Instead of cryptic escape sequences, you describe patterns in plain English.

Example — matching an email address:

email: username then "@" then domain

username: one or more of (letter, digit, ".", "_", "-")

domain: one or more of (letter, digit, "-") then "." then between 2 and 6 letters

Key differences from regex:

- Human-readable grammar syntax - Full parse trees with named extractions - No backtracking, no ReDoS by design - Composable grammar modules (use "module" (rule1, rule2)) - Zero dependencies, ~15KB

Available on npm (@hollowsolve/match). Docs, playground, and examples on the site.

GitHub: https://github.com/hollowsolve/Match

Public release of *ZombieHunter*, a forensics tool detecting live exploitation of CVE‑2026‑20700 (dyld memory corruption) in iOS 26.3. Analysis of sysdiagnose archives shows identical exploit shells showing different C2 endpoints:

US Device 1 → 83.116.114.97 (EU/US) US Device 2 → 101.99.111.110 (CN)

The rogue dyld_shared_cache slice triggers overflow via malformed `mappings_count`, executes shellcode (BL #0x15cd), and applies an AMFI bypass (`DYLD_AMFI_FAKE`) enabling unsigned code persistence. Apple PSIRT + CISA were notified; public disclosure follows.

Sample: https://drive.google.com/file/d/1rYNGtKBMb34FQT4zLExI51sdAYR... SHA256 artifact: ac746508938646c0cfae3f1d33f15bae718efbc7f0972426c41555e02e6f9770

Usage: `python3 zombie_auditor.py sysdiagnose_xxx.tar.gz` (Needs capstone)

Reproducible PoC confirms CVE‑2026‑20700 bypass, AMFI neutralization, and live C2 connectivity in production iOS 26.3.

Every MCP tool call dumps raw data into Claude Code's 200K context window. A Playwright snapshot costs 56 KB, 20 GitHub issues cost 59 KB. After 30 minutes, 40% of your context is gone.

I built an MCP server that sits between Claude Code and these outputs. It processes them in sandboxes and only returns summaries. 315 KB becomes 5.4 KB.

It supports 10 language runtimes, SQLite FTS5 with BM25 ranking for search, and batch execution. Session time before slowdown goes from ~30 min to ~3 hours.

MIT licensed, single command install:

/plugin marketplace add mksglu/claude-context-mode

/plugin install context-mode@claude-context-mode

Benchmarks and source: https://github.com/mksglu/claude-context-mode

Would love feedback from anyone hitting context limits in Claude Code.

Enveil is an open-source framework that provides secure, end-to-end encryption for data in use, enabling organizations to perform computations on encrypted data without exposing sensitive information. The project aims to advance privacy-preserving technologies and promote secure data sharing and collaboration.

Hey HN! Lev and Justin here, authors of PgDog (https://pgdog.dev/), a connection pooler, load balancer and database sharder for PostgreSQL. If you build apps with a lot of traffic, you know the first thing to break is the database. We are solving this with a network proxy that works without requiring application code changes or database migrations.

Our post from last year: https://news.ycombinator.com/item?id=44099187

The most important update: we are in production. Sharding is used a lot, with direct-to-shard queries (one shard per query) working pretty much all the time. Cross-shard (or multi-database) queries are still a work in progress, but we are making headway.

Aggregate functions like count(), min(), max(), avg(), stddev() and variance() are working, without refactoring the app. PgDog calculates the aggregate in-transit, while transparently rewriting queries to fetch any missing info. For example, multi-database average calculation requires a total count of rows to calculate the original sum. PgDog will add count() to the query, if it’s not there already, and remove it from the rows sent to the app.

Sorting and grouping works, including DISTINCT, if the columns(s) are referenced in the result. Over 10 data types are supported, like, timestamp(tz), all integers, varchar, etc.

Cross-shard writes, including schema changes (CREATE/DROP/ALTER), are now atomic and synchronized between all shards with two-phase commit. PgDog keeps track of the transaction state internally and will rollback the transaction if the first phase fails. You don’t need to monkeypatch your ORM to use this: PgDog will intercept the COMMIT statement and execute PREPARE TRANSACTION and COMMIT PREPARED instead.

Omnisharded tables, a.k.a replicated or mirrored (identical on all shards), support atomic reads and writes. That’s important because most databases can’t be completely sharded and will have some common data on all databases that has to be kept in-sync.

Multi-tuple inserts, e.g., INSERT INTO table_x VALUES ($1, $2), ($3, $4), are split by our query rewriter and distributed to their respective shards automatically. They are used by ORMs like Prisma, Sequelize, and others, so those now work without code changes too.

Sharding keys can be mutated. PgDog will intercept and rewrite the update statement into 3 queries, SELECT, INSERT, and DELETE, moving the row between shards. If you’re using Citus (for everyone else, Citus is a Postgres extension for sharding databases), this might be worth a look.

If you’re like us and prefer integers to UUIDs for your primary keys, we built a cross-shard unique sequence, directly inside PgDog. It uses the system clock (and a couple other inputs), can be called like a Postgres function, and will automatically inject values into queries, so ORMs like ActiveRecord will continue to work out of the box. It’s monotonically increasing, just like a real Postgres sequence, and can generate up to 4 million numbers per second with a range of 69.73 years, so no need to migrate to UUIDv7 just yet.

    INSERT INTO my_table (id, created_at) VALUES (pgdog.unique_id(), now());

Sharding hardly works without a good load balancer. PgDog can monitor replicas and move write traffic to a promoted primary during a failover. This works with managed Postgres, like RDS (incl. Aurora), Azure Pg, GCP Cloud SQL, etc., because it just polls each instance with “SELECT pg_is_in_recovery()”. Primary election is not supported yet, so if you’re self-hosting with Patroni, you should keep it around for now, but you don’t need to run HAProxy in front of the DBs anymore.

The load balancer is getting pretty smart and can handle edge cases like SELECT FOR UPDATE and CTEs with INSERT/UPDATE statements, but if you still prefer to handle your read/write separation in code, you can do that too with manual routing. This works by giving PgDog a hint at runtime: a connection parameter (-c pgdog.role=primary), SET statement, or a query comment. If you have multiple connection pools in your app, you can replace them with just one connection to PgDog instead. For multi-threaded Python/Ruby/Go apps, this helps by reducing memory usage, I/O and context switching overhead.

Speaking of connection pooling, PgDog can automatically rollback unfinished transactions and drain and re-sync partially sent queries, all in an effort to preserve connections to the database. If you’ve seen Postgres go to 100% CPU because of a connection storm caused by an application crash, this might be for you. Draining connections works by receiving and discarding rows from abandoned queries and sending the Sync message via the Postgres wire protocol, which clears the query context and returns the connection to a normal state.

PgDog is open source and welcomes contributions and feedback in any form. As always, all features are configurable and can be turned off/on, so should you choose to give it a try, you can do so at your own pace. Our docs (https://docs.pgdog.dev) should help too.

Thanks for reading and happy hacking!

Hi HN! I'm Prithvi—my co-founder Frances and I launched Promptless almost a year ago here (https://news.ycombinator.com/item?id=43092522). It's an AI teammate that watches your workflows—code changes, support tickets, Slack threads, etc.—and automatically drafts doc updates when it spots something that should be documented.

Frances and I really appreciated the feedback from our first launch. Today we’re launching Promptless 1.0, which addresses our biggest learnings from the last 12 months.

I also made it way easier to try it out. You can tag @promptless on any open-source Github PR or Issue with a doc update request, and Promptless will create a fork and open a PR for your docs to help. Feel free to use our own docs as a playground: https://github.com/Promptless/docs/issues

Or, you can sign up at https://promptless.ai to get free access for your own docs for the next 30 days. Here's a demo video: https://youtu.be/IWwimHCEY7Y

For me, the coolest part of the last year has been seeing how users got creative with Promptless. One user has Promptless listening in to all their Slack Connect channels, so whenever they answer a customer question, Promptless figures out if their docs should be updated and drafts an update if so. Another user has Promptless processing every customer meeting transcript and updating their internal docs after each meeting: customer dashboards, feature request pages, etc.

Some of the biggest things that are new with version 1.0:

- Automatically updating screenshots: this was by far our most requested feature. The need here was always clear. People would exclude screenshots from docs because they’d get stale quickly, even though they knew screenshots would be helpful to users. A year ago, we just couldn't ship a good enough solution, but given how much LLMs' visual grounding has improved in the last year, now we've got something we're proud of.

- Slop-free writing: The most common critique on early Promptless suggestions was that even though they were accurate, they could sound generic or verbose, or might just reek of AI slop. Promptless 1.0 is 3.5x better at this (measured by voice-alignment compared to what users actually published), through a combination of fine-tuned models, sub-agents, and alignment on user-defined preferences.

- Open-source program: We're especially proud of this—Promptless is now free for CNCF/Linux Foundation projects (reach out if you’re a maintainer!). You can take a look at how Promptless is supporting Vitess (a CNCF-graduated project) with their docs here: https://github.com/vitessio/website/commits

Check it out and let us know if you have any questions, feedback, or criticism!

Although there's plenty of hype going around with agents, what I do think is that we're at the point where we're building the online infrastructure for AI agents, and we don't really know how that looks like yet. So I've built SentientTube (https://sentienttube.com) to explore what it means to allow AI Agents to become content creators.

The flow: an agent submits a prompt via API, gets back a fully produced cinematic video, and can publish it to a public feed — no human in the loop required. I expose a /skill.md endpoint so agents can self-onboard without any UI.

Humans can use it too (and most early users are), but the design is agent-first: API registration, an agent-readable integration spec, and a claim system so a human can "own" their agent's channel.

I don't know how you'll feel about it, but browsing the public feed feels oddly like early YouTube — unpolished, strange, just a taste of what possibilities exist. Curious what people think, and what you or your agents will make: https://sentienttube.com/videos

Free for now, am just testing interest.

Early thoughts: What I love most is when you ask an agent to make a video based on what it knows about you, to either surprise you, challenge your ideas, help you with unblocking yourself, etc. It can be super inspirational if it knows enough about your life and struggles.

I've been begrudgingly working on autorouters for 2 years, looking for new techniques or modern methods that might allow AI to create circuit boards.

One of the biggest problems in my view for training an AI to do autorouting is the traditional grid-based representation of autorouting problems which challenges spatial understanding. But we know that vision models are very good at classifying, so I wondered if we could train a model to output a path as a classification. But then how do you represent the path? This lead me down the track of trying to build an autorouter that represented paths as a bunch of patterns.

More details: https://blog.autorouting.com/p/the-recursive-pattern-pathfin...

It takes an input video and converts it into H.264/Opus RTP streams that you can blast at your video call systems (WebRTC, SFUs, etc.). It also injects network chaos like packet loss, jitter, and bitrate throttling to see how things break

It scales from 1 to n participants, depending on the compute and memory of the host system Best part? It’s packaged with Nix, so it builds the same everywhere (Linux, macOS, ARM, x86). No dependency hell

It supports both UDP (with a relay chain for Kubernetes) and WebRTC (with containerized TURN servers). Chaos spikes can be distributed evenly, randomly, or front/back-loaded for different test scenarios. To change this, just edit the values in a single config file

SnapSift is a mobile app that helps users discover and connect with businesses and brands by allowing them to easily share and discover product recommendations, reviews, and experiences through visual snapshots.

Hello all! Build clean, minimalistic analog clock webpage to Cloudflare Pages.

This is for (maybe): - kids to learn - for second monitor - old tabled on shelf - ..

Themes and screen wake lock buttons with auto-hide. Goal is to keep it as clean as possible.

This possible makes no sense, but for a domain of $10/y this is cheap site for me to keep and see how it lives on.

Sowbot is an open-hardware agricultural robot designed to close the "prototype gap" that kills most agri-robotics startups and research projects — the 18+ months spent on drivers, networking, safety watchdogs, and UI before you can even start on the thing you actually care about.

The hardware is built around a stackable 10×10cm compute module with two ARM Cortex-A55 SBCs — one for ROS 2 navigation/EKF localisation, one dedicated to vision/YOLO inference — connected via a single ethernet cable.

Centimetre-level positioning via dual RTK GNSS, CAN bus for field comms, and real-time motor control via ESP32 running Lizard firmware.

Everything — schematics, PCB layouts, firmware — is under open licences. The software stack runs on RoSys/Field Friend (for teams who want fast iteration) or DevKit ROS (for teams already in the ROS ecosystem). The idea is that a lab in one country can reproduce another lab's experiment by sharing a Docker image.

Current status: the Open Core brain is largely fabricated, the full-size Sowbot body has a detailed BOM but isn't yet assembled, and we have two smaller dev platforms (Mini and Pico) in various stages of testing.

We're a small volunteer team and we're looking for contributors — hardware, ROS, firmware, docs, whatever you can offer.

The best place to start is our Discord: https://discord.gg/SvztEBr4KZ — we have a weekly call if you'd prefer to just show up and chat.

GitHub: https://github.com/Agroecology-Lab/feldfreund_devkit_ros/tre...

Hey all, I built babyshark, a terminal UI for PCAPs aimed at people who find Wireshark powerful but overwhelming.

The goal is “PCAPs for humans”: Overview dashboard answers what’s happening + what to click next

Domains view (hostnames first) → select a domain → jump straight to relevant flows (works even when DNS is encrypted/cached by using observed IPs from flows)

Weird stuff view surfaces common failure/latency signals (retransmits/out-of-order hints, resets, handshake issues, DNS failures when visible)

From there you can drill down: Flows → Packets → Explain (plain-English hints) / follow stream

Commands: Offline: babyshark --pcap capture.pcap

Live (requires tshark): babyshark --list-ifaces then babyshark --live en0

Repo + v0.1.0 release: https://github.com/vignesh07/babyshark

Would love feedback on UX + what “weird detectors” you’d want next.

Interactive timeline of every major Large Language Model. Filterable by open/closed source, searchable, 54 organizations tracked.

This weekend I finally shipped Gryt, a project I’ve been building since 2022 — an open-source, self-hostable Discord-style app focused on reliable voice chat + text.

I’m the creator. I started it after getting fed up with Discord disconnects/paywalls and wanted something self-hosted and auditable.

I started on this in 2022 and had an early proof-of-concept working back then (auth + friends list), but I quickly realized WebRTC voice isn’t something you can duct-tape together. I spent a big chunk of the next couple years learning the stack (ICE/DTLS-SRTP, NAT traversal, SFU design), then came back and built a proper end-to-end architecture and polished it to the point where I felt comfortable releasing it publicly.

Repo: https://github.com/Gryt-chat/gryt Quick start: https://docs.gryt.chat/docs/guide/quick-start Web client: https://app.gryt.chat

Anthropic has released Steerling, an 8-billion parameter language model, aimed at providing a more aligned and truthful AI assistant that can engage in open-ended dialogue and assist with a variety of tasks while adhering to Anthropic's principles of ethical AI development.

Hey HN,

I built StreamHouse, an open-source streaming platform that replaces Kafka's broker-managed storage with direct S3 writes. The goal: same semantics, fraction of the cost.

How it works: Producers batch and compress records, a stateless server manages partition routing and metadata (SQLite for dev, PostgreSQL for prod), and segments land directly in S3. Consumers read from S3 with a local segment cache. No broker disks to manage, no replication factor to tune — S3 gives you 11 nines of durability out of the box.

What's there today: - Producer API with batching, LZ4 compression, and offset tracking (62K records/sec) - Consumer API with consumer groups, auto-commit, and multi-partition fanout (30K+ records/sec) - Kafka-compatible protocol (works with existing Kafka clients) - REST API, gRPC API, CLI, and a web UI - Docker Compose setup for trying it locally in 5 minutes

The cost model is what motivated this. Kafka's storage costs scale with replication factor × retention × volume. With S3 at $0.023/GB/month, storing a TB of events costs ~$23/month instead of hundreds on broker EBS volumes.

Written in Rust, ~50K lines across 15 crates. Apache 2.0 licensed.

GitHub: https://github.com/gbram1/streamhouse

Happy to answer questions about the architecture, tradeoffs, or what I learned building this.

Desktop app for OSINT and darknet investigations. Everything runs locally on your machine, no evidence is sent to the cloud. Built-in Tor browser lets you access .onion sites directly from the workbench without juggling separate tools. An AI copilot can analyze screenshots and web pages as you work. Every piece of evidence gets SHA-256 hashed with a tamper-evident custody chain so your collection holds up. IOC tracking across cases with automatic cross-case correlation to link shared infrastructure between investigations. STIX 2.1 export and MITRE ATT&CK mapping for structured reporting, currently only available on macOS.