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.
Nodemailer author here. I now publish all my libraries/tools (like Nodemailer) under some permissive license (MIT, MIT-0, ISC). This gives the opportunity to use such a library without issues, and the end user never knows about these tools anyway. For example if I build a OSS software and commercial software that both use such library, then it is easier to manage it under permissive license - I don't want copyleft licenses turning up in my commercial software even if I'm the owner.
For OSS applications, I use EUPL (eg. https://wildduck.email/) or AGPL copyleft licenses. The license does not stop anyone using it as an application, but at the same time people are not free to copy, rename and sell it either.
I did not plan to make the project paid at first, I would have prefered the OS / Open Core model, but it did not work out. So what I meant about the feedback was that the feedback for a free product might not help much for a paid product and vice versa. Different target groups, different priorities. On the other hand, more users, no matter if free or paid, help to detect edge case bugs better as there is a higher chance of someone stumbling on it and reporting it. In this case the first larger wave of free users did help me, yes.
TBH, I get way better feedback from paying users than previously from free users. Free users like to tinker and think in terms of "what if," so they bring up all kinds of features the software should also have because it can or it would be cool. The paying users only need actual features that help their business case, and they do not care at all about these "what if" features.
You can't take the entire software commercial, as everything previously released under the open-source license will stay under that license. In the case of EmailEngine, all versions ever released under the AGPL license are still in Github; you can fork and use these freely. It is only the path forward that gets closed when going commercial - users can start paying, can stay indefinitely on the already released free versions, or can take the initiative and fork the project.
I locked prices for existing customers. So someone who signed up 2 years ago is still paying 250€ per year, while customers signing up today will pay 895€ per year.
Well, I guess you're right in a way. While there are no meaningful outside commits in EmailEngine, there are _some_ commits, even if these have minimal impact, by people who do not get paid for it, while I do.
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.