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.
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!
Thanks for checking it out and for the feedback — 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!
I'm working on MailTrigger — a customizable SMTP server that turns any email notification into a message on platforms like LINE, Slack, Microsoft Teams, Telegram, SMS, or pretty much anything else.
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!