For persistent, high-throughput traffic, Muti Metroo maintains long-lived connections and multiplexes multiple logical streams over a single peer link, each with independent flow control. This works well for token streaming, where low latency matters more than raw bandwidth. In residential networks, QUIC is usually the best choice, with HTTP/2 and WebSocket also available.
Service discovery is handled via the port-forwarding model. A node can advertise a named endpoint (e.g. an Ollama instance), and another node can bind a local listener to that key. The mesh routes traffic end-to-end encrypted, so from the client’s perspective it behaves like a local port even though the service is remote.
For distributed inference, the main constraints are latency and hop count - extra hops add delay, which is fine for background work but relevant for interactive use. Everything runs in userspace, and outbound connections plus QUIC make it usable behind typical residential NATs.
At this point, almost all new EmailEngine customers are AI startups. These are teams that know how to use LLMs well, which makes it interesting that they still opt for EmailEngine despite the extremely expensive $83/month price tag.
EmailEngine author here. The commenter tried the EmailEngine trial back in 2024 and appears to have had a negative experience. Since then, he’s repeatedly criticized EmailEngine and related components like the ImapFlow IMAP library, often while promoting his own product.
I maintain the Nodemailer library. Several years ago I used my personal email in a few usage examples. Developers still copy that old snippet, add their SMTP credentials and send test emails - which land in my inbox.
I once flew to the US for a week on ESTA to attend a few meetings (pre-COVID), but I mostly just did my regular developer work in the US office. By today’s standards, would I have been shackled for that?
You can also get structured data out of mailboxes with my project EmailEngine. You can use an API request to fetch message contents, or you can configure EmailEngine to send a webhook for every new email in a structured JSON, for example, like this: https://emailengine.app/webhooks#messageNew
I renew my essential domain names in 10‑year increments. As long as I control the domain, I can spin up new mail hosting if any provider boots me. I’d lose the old messages stored on their servers, but the address itself keeps working.
For example, I once switched the license of Nodemailer from MIT to EUPL, with the option of still getting a MIT version if you paid for it. I had some paying customers, but it turned out they were all spammers using stolen credit cards (I guess they misunderstood what the paid offering was). So, when the chargebacks came in, my account actually went into the negative.
When I started with Nodemailer, my goal was to build a cool product—not to become an unpaid helpdesk employee for life. But here we are. So, I’ve been trying to monetize the project in various ways for the past ten years. I’ve tried everything (license restrictions, freelancing and consulting, paid extensions, etc.), and each approach failed for different reasons. The only strategy that actually took off was using Nodemailer’s documentation page as a referral source for another relevant paid project.
You have less control over formatting and ad placement in the README file, as rendered markdown offers only limited options. With a dedicated documentation website, it’s much easier.
It’s also a question of sovereignty. If your documentation is in the README, then GitHub owns the audience. If they, for some reason, close your project, you’re finished. With your own documentation page, the risk is much lower.
I had the exact same experience with Nodemailer, a popular open-source project I started 14 years ago. My solution was to empty the README file and set up a dedicated documentation website. Since the project is popular, the documentation website receives around 70,000 visits per month. I initially tried paid ads, but they only netted about $200 per month—not great. So, I started a commercial project somewhat related to Nodemailer and added ads for my new project on Nodemailer’s documentation page. This brings in around 3,000 visits per month to my paid project through the ads on the documentation page. Even if the conversion rate is low, it’s essentially free traffic for my paid project, which is now approaching $10,000 MRR. Without the free visitor flow from my OSS project’s documentation page, I definitely wouldn’t have made it this far.
Multiple enterprise customers use my software (https://emailengine.app) because it can proxy OAuth2-enabled IMAP/SMTP connections as regular password-based sessions. Turns out there are a lot of legacy, like all kinds of cron scripts, that want to connect to some IMAP account to check and do something. It all breaks down once the organisation enforces OAuth for their email. So, personally, I don't like it at all, but as a software developer, I'm really happy about it. Helps with my sales effort :P
Service discovery is handled via the port-forwarding model. A node can advertise a named endpoint (e.g. an Ollama instance), and another node can bind a local listener to that key. The mesh routes traffic end-to-end encrypted, so from the client’s perspective it behaves like a local port even though the service is remote.
For distributed inference, the main constraints are latency and hop count - extra hops add delay, which is fine for background work but relevant for interactive use. Everything runs in userspace, and outbound connections plus QUIC make it usable behind typical residential NATs.