Show HN за 24 февраля 2026 г.

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://github.com/JohannaWeb/ProjectFalcon

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://enseal.docsyard.com/

I got tired of spending hours in PowerPoint and TikZ drawing methodology diagrams for my papers. So I built PaperBanana — you paste your Method section text, and it generates a publication-ready figure in about 2-3 minutes.

How it works under the hood:

1. A Retriever agent searches a curated database of real academic diagrams to find structurally similar references 2. A Planner agent reads your text and generates a detailed visual description (layout, components, connections, groupings) 3. A Stylist agent polishes the visual aesthetics without changing content 4. Then it enters an iterative loop: a Visualizer generates the image, and a Critic evaluates it and suggests revisions — this repeats 1-5 times (you choose)

The key insight is that academic diagrams follow conventions — Transformer architectures, GAN pipelines, RLHF frameworks all have recognizable visual patterns. By retrieving relevant references first, the output is much closer to what you'd actually put in a paper vs. generic AI image generation.

Built with: Next.js + FastAPI + Celery, using Gemini 2.5 Flash for planning/critique and Nanobanana Pro/Seedream for image generation.

Try it here: https://paperbanana.online

Some examples it handles well: Transformer architectures, GAN training pipelines, RLHF frameworks, multi-agent systems, encoder-decoder architectures.

Known limitations: - Works best for CS/AI methodology diagrams — not optimized for biology, chemistry, or general scientific illustration - Text rendering in generated images isn't perfect yet — sometimes labels get slightly garbled - The curated reference database is still small (13 examples), expanding it is ongoing work

Would love feedback from anyone who writes papers regularly. What types of diagrams do you struggle with most?