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.
It’s a great honor to be able to talk with Andris. A few months ago I learned that the author of EmailEngine not only created EmailEngine, but is also behind many foundational Node.js email libraries that are widely used. My own projects, RustMailer and Bichon, are built on the shoulders of many great Rust email libraries. EmailEngine is undoubtedly a success, and Andris has spent years quietly and diligently contributing to these core libraries. I have deep respect for you.
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?
Even team members visiting from Canada were told very explicitly to not say they're coming to the US to "work" but rather for a business trip. But practically of course everyone do some amount of actual work. From checking their email / slack to doing some white boarding designs etc. If those aren't even allowed, then I don't see how any in person team meetings can be conducted.
Right but the purpose of the trip was to attend the business meeting and the person on the trip was also conducting their regular duties as a developer as well.
Attending meetings and conferences are rarely the main duties of an employee but they are the main purpose of trips.
Similarly to how, if you go to Mexico on a Tourist Visa but answer a critical work phone call you would not be breaching the terms of your visa as the purpose of your trip is still vacation. However if you rent a house for 5 months and spend most of that time doing developer work, I think that the authorities there might be a little upset.
From what I've read it's still an ESTA violation. When I went to the CES a few years ago my goal was clearly work, not vacation, and I did work from my hotel. I should have been arrested and put in chains, then publicly shamed for that I guess, even though my employer asked me to.
Was only planning a single family trip in the US in the next few years anyway, and Trump nicely gave me an argument to visit the Carribbean instead (because yes, I intend to work a few days from my vacation,I have to when I take more than a month off).
Is it "work" if it's done on behalf of the foreign company? It doesn't interact with anything in the US; people or taxes, so it has no impact on the US labor market or taxes.
Not that I agree but Governments take a very nuanced view on what they consider impact. Remember, growing your own corn for feed outside of the government quota was considered as having an impact on "Interstate Commerce".
In a hypothetical; If you were employed by an Canadian company, doing internal tech support and then you then move to Belize because you hate the cold. No interaction with anything in Belize.
The Belize government might say, "Not so, you moved here and are taking advantage of our infrastructure, societal governance, etc. but are not helping pay for it." Furthermore, natives of Belize may be upset that because you have a higher income than the native population you are affecting the cost of goods(not one person individually but if 1000 people with high income show up and are all looking to rent houses, the rental rates would rise both due to demand and the ability to pay.)
If we think about things especially from the second point of view, it would be very bad for a country to allow unlimited rich foreigners to come into their country and live there; Even if they are contributing by purchasing local goods and services, they are in competition with local workers as well; They might even stunt the economy if it becomes reliant on them and then they all move out suddenly; and the foreigners would also start shaping the culture of the country as well, which could be neocolonialism depending on your view of things.
EDIT to add: I like the idea of being able to live wherever I want to but it is also important to consider the views of those who are in those countries as well. I think that some(most?) people from Europe and North America don't have a strong national identity and don't see any value in such things. But there are people in other countries that do take a lot of pride in where they are from and how long their family has lived there. Some of this pride is what builds the culture and the local charm that those without enjoy but it becomes a sort of "We are destroying the thing we love by trying to experience it" situation.
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 don't think I was specific enough on what kind of structured data. The idea is that it extracts information from the text/HTML content of emails (e.g. a flight itinerary from an airline booking email or an ingredient list from a recipe) using AI.
Since you already have a method for reaching into folks Microsoft 365 inboxes and such, you could probably train an LLM to extract arbitrary data based on a user's prompt quite quickly though.
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.
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.
This is a really interesting approach, I hadn't thought of this!
Just out of curiosity, do you think the separate documentation page has better conversion than if you were to, say, include the ad directly into the readme inside the repo?
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.
Thanks for sharing. It's an interesting idea, to try to trampoline it into another related commercial project. I just checked my RTD analytics, I get around 1k pageviews to `/` per month. Unfortunately I don't have a related commercial product either.
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.
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.
Very interesting! I wonder if, sadly, the rise of AI-assisted coding will chip away also at this potential revenue stream? As developers simply ask a local or cloud LLM how to use a piece a software instead of reading the documentation.
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.
> This gives the opportunity to use such a library without issues, and the end user never knows about these tools anyway.
Why not something like MPLv2 then? It does give the opportunity to use the library without issues, the only constraint (compared to e.g. MIT) being that changes to the library needs to be distributed. If you don't change it, then it's pretty much like MIT.
To me, MPLv2 is superior to MIT in the sense that it gives developers leverage against their management. If I tell my manager "I fixed a bug in this MIT library, can I contribute it upstream?", the answer is often "let's discuss that later" or "hmm we'll have to see with legal" or "are you sure that it is not a competitive advantage for us?". In my experience, managers never see value in contributing anything back.
Now if the library is MPLv2, I can use it just like MIT, but if I fix a bug I can tell my manager: "it is MPLv2, which means that I must distribute my changes. Are you fine with me contributing them upstream?". Again in my experience, the manager will just say "if you have to, then do it". Even though (AFAIU) MPLv2 does not enforce contributing upstream: you just have to distribute the changes with the software (to your customers). But managers generally don't know anything about licenses, so "contributing upstream" is a good-enough approximation.
TL;DR: with MPLv2, the developer has leverage to bring their changes upstream. With MIT, the manager can happily keep the changes proprietary. I am a developer, I want to open source my code. Therefore I want copyleft.
You are right: MPLv2 does not enforce contributing upstream. So you turn your manager into a fool (just a little bit).
The MPL is probably one of the best F/OSS licenses: clear, concise, well written...
But this is - hopefully - true for the EUPL as well.
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.