It's very cool! I am planning add Iroh into my daily used https P2P tool (https://github.com/nuwainfo/ffl) which currently using WebRTC. It's very cool to support both protocols, but it seems like Iroh python support is via FFI which can't be used in my APE (Actual Portable Executable) build...thinking...
I mirrored the directly downloadable files from the May 2026 war.gov UFO/UAP Release 01 into a single browser-friendly download pack.
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. :)
I also really like Termux. When I was developing https://github.com/nuwainfo/ffl (a tool similar to croc, but the receiver uses a browser and doesn't need to install anything), it was because I wanted an easy way to get things off my phone. I actually packaged ffl—which is pure Python—into an APE just to make it compatible with Termux. Although many people here use ssh, rsync, or solutions like copyparty, I prefer my own minimalist solution: just one binary to transfer whatever I want. Anyway, Termux is cool.
I actually wrote a section about this here: https://github.com/nuwainfo/ffl?tab=readme-ov-file#porting-t.... In short, I used superconfigure the project’s ported Python APE, rewrote all C extensions into Python APE as built-in extensions, modified libraries like aiortc to use them, and finally resolved several tricky porting issues across platforms. It was a tough process, but I managed to get it working successfully :)
Oh, in this demo the right panel is just simulating the co-worker. In a real case, I would send the link to him via IM (for example, Slack). Since this is only a demo, I’m playing both roles myself. :p
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).
I'm working on ffl (https://github.com/nuwainfo/ffl), an Actually Portable Executable (APE) that turns any file or folder into a secure P2P HTTPS link via WebRTC.
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!
I built a file sharing CLI called ffl which is also an APE built on Cosmopolitan Libc, just like llamafile.
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.
I am working on FastFileLink (https://fastfilelink.com/), yet another file-sharing CLI/app that uses WebRTC for P2P transfer but exposes HTTPS links, making it compatible with browsers and tools like curl/wget.
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.
You might want to check out MailTrigger (https://www.mailtrigger.net/) — it's a programmable SMTP server that can even call an LLM before sending emails, so everything you listed is technically doable: blacklists/whitelists, phishing detection, spam rollups, virus scans, link previews, etc.
It’s not directly related to the MS email stack, but if you're self-hosting and looking for a flexible, programmable layer in front of your mail server, it could be a good fit. It’s still under development (though already running in production for my own company and a few early adopters), and the pricing page is just a placeholder for now. But the docs are public, and I believe it can cover what you're aiming for.
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.