bear330
Show HN: I rebuilt Google Map's Pac-Man for my 5-year-old son
Show HN: I want to use Apache Tika from Python, but I don't want to install Java
I’m using my company’s long‑term org chart and culture to shape the Grokbot team, and building mcp (like MIS/mail/kanban/ERP) for them, so that AI employees can work fully autonomously and operate independently. I really enjoy this process and this team—it’s exactly what I’ve always envisioned. Once things run smoothly, I’d like to open source them.
Right now, ffl serves as the data plane, while https://www.mailtrigger.net/doc/ works as the control plane, and the system is running very well. I hope my company can successfully transform.
Show HN: FFL - A portable CLI (via APE) to send files to browser via WebRTC
Includes 158 files: 116 PDFs, 28 MP4s, 14 images, plus source URLs, SHA-256 checksums, and a start-here guide.
This is not an analysis of the contents; it is just a convenience archive.
I understand that some kind people here may have already packaged similar resources, but I’m simply offering another channel in the hope that it can be helpful to everyone. :)
Show HN: A browser-friendly mirror of the war.gov UFO/UAP Release 01 files
Server Migration Without Extra Disk Space: Streaming Borg Backups with Ffl
It's Android App don't need LAN to share: https://play.google.com/store/apps/details?id=com.fastfileli...
AI Fatigue: Why the "Test Only, Zero Code Review" Methodology Is Flawed
I've been using Claude Code (CLI) heavily, but I hit a major friction point: When Claude generates artifacts locally (like a specific SQLite dump, build logs, or a patch), it has no easy way to "hand" them to a coworker.
I didn't want to upload sensitive local files to a third-party cloud (S3/Drive) just to send a temporary file to a teammate sitting virtually next to me.
So, I built an MCP server (ffl-mcp) that gives Claude the capability to share files directly via P2P.
The Workflow:
1. I ask Claude: "Zip the logs and send them to Bob."
2. Claude uses the tool to generate a one-time P2P link.
3. My coworker clicks the link to download immediately (streaming transfer, E2EE).
Under the hood:
It wraps ffl [0], a CLI tool I built for NAT traversal (WebRTC, relay if failed). (I packaged the core tool as an "Actually Portable Executable" so it runs as a single binary across platforms without Python environment headaches).
It's open source and you can try it with uvx: https://github.com/nuwainfo/ffl-mcp
[0] The core ffl tool: https://github.com/nuwainfo/ffl
Show HN: Giving Claude Code "hands" to deliver local files (P2P, No Cloud)
Like llamafile, it's built on Cosmopolitan Libc. Getting the full Python stack + WebRTC to run as a single APE binary was incredibly tricky to pull off, but the result is super convenient. I mainly built it to solve the pain of moving large files (logs, DB dumps) in and out of containers—now it's just one command.
The repo has a demo showing a round-trip transfer between Windows (x64) and Android (arm64) using the same binary. I hope you give it a try!
Since llamafiles can be quite large (multi-GB), I built ffl to help 'ship' these single-file binaries easily across different OSs using WebRTC. It feels natural to pair an APE transfer tool with APE AI models.
It's ~90% production-ready. We use it internally to move files between containers and hosts (especially when volumes aren't mounted), and for WFH employees to exchange large files without a relay server. For huge files, there's resumable upload to our infra-backed server — fast global downloads included.
The CLI will also support receiving files via WebRTC, but that feature hasn't been released yet. It is open source (https://github.com/nuwainfo/ffl), but the README hasn't been updated yet and the code is not synced with the latest version (working on these).
Another production-used tool I'm working on is MailTrigger (https://www.mailtrigger.net/) — a programmable SMTP server that turns any email into a message on LINE, Slack, Teams, Telegram, SMS, or basically anything. If your app can send email, it can trigger multi-channel notifications with zero extra code.
Think of it as “SMTP to Anything,” or an email-native IFTTT/Zapier.
It supports JS and WASM for preprocessing, routing, and automation — you can write custom logic, auto-reply with LLM-generated messages, or forward alerts intelligently. We use it for price drop alerts, server health monitoring, and integrations with Jenkins/Sentry to push incidents to our DevOps Telegram channel.
Also experimenting with LLM-assisted rule creation: you can define notification logic in natural language instead of writing code — for example, auto-reply with an LLM-generated joke or handle customer support queries dynamically.
Docs are more complete than the website (which is still evolving), and the pricing page is currently a placeholder. Already running in production for us and a few early adopters.
One thing to note: while the website mainly talks about multi-channel notifications, MailTrigger is actually more like IFTTT or Zapier, but specialized for email — when a message arrives, it can trigger smart, programmable actions. You can turn your existing email system into an IFTTT-style automation engine. It supports JS and WASM for preprocessing and routing, so you could, for example, auto-reply with an LLM-generated joke or handle customer support queries dynamically. The website might not fully reflect this yet, but the docs are more complete and show what’s possible.
Right now, each MailTrigger mailbox requires SMTP authentication (username/password), so unless someone has the correct credentials, they can’t inject messages. That gives us a basic layer of protection against spoofing from the SMTP side.
For forwarded emails (e.g. from Gmail), we do validate SPF, DKIM, and DMARC on inbound messages. Each mailbox acts as a gated endpoint — only verified senders are allowed to trigger actions.
As for pricing — you nailed it, we’re still working that out. We have a few rough ideas, but I’d genuinely love to hear what kind of pricing model would feel fair or sustainable to you.
Would you lean towards usage-based (like number of messages/month), flat monthly per mailbox, or something else entirely? Have you seen pricing models you liked (or didn’t) in similar tools like Zapier or SendGrid?
Your feedback’s incredibly helpful at this stage — really appreciate it!
I’m sorry the loading took so long. I’m not entirely sure if the issue was with the main site or the Join Waiting List process. We’ll definitely investigate and get it fixed as soon as possible.
If it turns out that the waiting list form was the problem and you'd still like to join, feel free to shoot me an email at [email protected] — I'd be happy to add you directly!
Thanks again for flagging this. Your feedback means a lot and will help us improve!
The idea is simple: if your app can send an email, it can trigger notifications across multiple channels with no extra coding. Think of it as "SMTP Server to Anything."
One of the cool parts is MailTrigger supports WebAssembly (WASM), so you can customize your own notification logic and automate workflows. I’ve used it for tasks like monitoring internal systems, forwarding alerts to different chat platforms, and even adding basic decision-making logic before sending notifications. It’s been a huge time saver.
I’ve also experimented with using LLMs to assist in rule creation — you can configure notification rules using natural language instead of writing manual code. It’s like giving your infrastructure a smarter way to handle incidents.
At my company, I’m using MailTrigger for real-time price drop alerts and server health monitoring, along with integrations like Jenkins and Sentry to forward alerts to our DevOps Telegram channel.
It’s still super early, and things like the docs, pricing, and overall user experience are definitely a work in progress. But I’m iterating quickly and would love to hear feedback from this community!
Check it out here: https://mailtrigger.app/
Curious to hear your thoughts!