Show HN: Nullroom.io – Experimental, stateless P2P messaging and file sharing https://ift.tt/tH7nRhU

Show HN: Nullroom.io – Experimental, stateless P2P messaging and file sharing Hi HN, I’ve been experimenting with WebRTC and Rails 8 to see if it's possible to build a messaging utility that is truly "stateless". I wanted to create something for those moments when you need to move a snippet of text or a file between devices without leaving a trace on a server, a database, or a third-party cloud. The AI Collaboration: I also want to mention that this project has been a deep dive into collaborating with AI. I used AI to brainstorm the "Zero-Trace" architecture, help me harden the infrastructure after a security audit. How it works: Zero-Trace Architecture: No accounts, no cookies (beyond basic security), and absolutely no server-side logging. Client-Side Encryption: Encryption keys stay in the URL fragment (#). Since fragments are never sent to the server, the signaling layer is cryptographically blind to your data. P2P Signaling: We use ActionCable for the initial handshake. Once the WebRTC DataChannel is established, the conversation and file transfers happen directly between browsers. Zero Third-Party Dependencies: No external fonts, scripts, or trackers. Everything is served from the origin to prevent IP leakage to third-party providers. The Beta Experiment: I'm currently testing the stability of the P2P signaling. I’ve enabled file transfers (up to 24MB) for everyone during this phase. I’m curious to see how the connection logic handles different network environments. The Tech Stack: Framework: Rails 8 Deployment: Kamal 2 on a single VPS I’d love to get your thoughts on the UX and any edge cases you find with the WebRTC handshake! https://ift.tt/Hlba0v9 February 26, 2026 at 02:58AM

Show HN: PullMaster – Recommends code reviewers from your repo history https://ift.tt/N8iK1RG

Show HN: PullMaster – Recommends code reviewers from your repo history I've been a developer for 20+ years and reviewer selection has been a recurring problem at every company I've worked at. Either you're a CODEOWNER getting spammed on every PR, or you're in Slack trying to find someone who actually knows the code you changed. CODEOWNERS is too coarse — it maps paths to people, but doesn't account for who's available, who reviewed this author before, or who actually touched these files recently. I built PullMaster to fix this. It's a GitHub App that analyzes your repo's actual history and recommends the best reviewer for each PR. It adapts to the risk level of each change, so critical PRs surface experienced reviewers while routine ones get distributed across the team. Install the GitHub App and comment `@pullmaster-ai suggest` on a PR to get a recommendation with an explanation, or `@pullmaster-ai assign` to also request the review automatically. No configuration needed — it learns from your repo as soon as it's installed. It's free. I'd use it at my day job but being in a heavily regulated industry without SOC 2 makes that a non-starter, so I'm looking for early users and feedback. Happy to answer questions about how it works. https://ift.tt/8aqIfSY February 25, 2026 at 10:46PM

Show HN: A Visual Editor for Karabiner https://ift.tt/42I7tnG

Show HN: A Visual Editor for Karabiner https://ift.tt/dtzFbRG February 25, 2026 at 12:39AM

Show HN: StreamHouse – S3-native Kafka alternative written in Rust https://ift.tt/pdKcIo1

Show HN: StreamHouse – S3-native Kafka alternative written in Rust 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://ift.tt/3duhx4S Happy to answer questions about the architecture, tradeoffs, or what I learned building this. https://ift.tt/3duhx4S February 24, 2026 at 11:50PM

Show HN: Falcon – Chat-first communities built on Bluesky AT Protocol https://ift.tt/anhN0EC

Show HN: Falcon – Chat-first communities built on Bluesky AT Protocol I’m building a chat-first community app that uses Bluesky’s AT Protocol for identity. Current architecture: - Electron client - Spring Boot backend (monolith) - REST for servers/channels - Planning WebSocket-based messaging As a solo builder, I’m trying to balance simplicity with future scalability. At what point would you introduce: - a separate WebSocket gateway - pub/sub (Redis, etc.) - or keep everything in one Spring app until it breaks? Curious how others approached real-time chat systems early on. Project for context: https://ift.tt/nPj1HMe February 24, 2026 at 12:02AM

Show HN: Enseal – Stop pasting secrets into Slack .env sharing from the terminal https://ift.tt/qYr7MQl

Show HN: Enseal – Stop pasting secrets into Slack .env sharing from the terminal We've all done it — "hey can you DM me the staging .env?" Secrets end up in Slack history, email threads, shared notes — all searchable, all persistent. The secure path (1Password, GPG, etc.) always had more friction than the insecure one, so people took the shortcut. enseal makes the secure path faster than the insecure one: # sender $ enseal share .env Share code: 7-guitarist-revenge Expires: 5 minutes or first receive # recipient $ enseal receive 7-guitarist-revenge ok: 14 secrets written to .env Zero setup, no accounts, no keys needed for basic use. Channels are single-use and time-limited. The relay never sees plaintext (age encryption + SPAKE2 key exchange). For teams that want more: identity mode with public key encryption, process injection (secrets never touch disk), schema validation, at-rest encryption for git, and a self-hostable relay. Written in Rust. MIT licensed. Available via cargo install, prebuilt binaries, or Docker. Looking for feedback on the UX and security model especially. What would make you actually reach for this instead of the Slack DM? Detailed documentation here: https://ift.tt/197lQxE https://ift.tt/jX8GbD6 February 23, 2026 at 11:15PM

Show HN: Gridl – A daily block puzzle game https://ift.tt/BDi2aVK

Show HN: Gridl – A daily block puzzle game https://gridlgame.com February 23, 2026 at 12:28AM