Having sent billions of emails between multiple startups:
RE setup and testing: Trust (as is most devops one-time setups). Once the initial email setup is complete, you typically aren’t paying with it much. The black swan outages aren’t really an active concern.
RE PII: email is non-secure and shouldn’t have sensitive data in production either. Also, dev/test shouldn’t have PII in regulated industries as a good hygiene practice (I’ve worked in healthcare, finance, and national security contexts).
Re licensing: I appreciate your openness and clarity on the licensing of the gateway engine as AGPL vs MIT for the rest. There’s a more modern licensing approach with FSL-1.1-MIT. It may be a better fit for customers (ie clear licensing terms when using a paid license and less concerns if the business goes defunct or pivots) and for your business plans.
Thanks, someone who has sent billions of emails is exactly who I need to ask.
Regarding 'set and forget': I agree once infra is stable, it stays. But I see the value when the application layer changes—tweaking templates, switching providers, or DNS updates. Do you still feel mocks are enough there?
Regarding PII: You're 100% right on hygiene. The encryption (ML-KEM-768) is just a 'safety net' for the human errors.
Regarding FSL-1.1-MIT: Very interesting suggestion. I will investigate it.
Honest question: At your scale, is this a niche tool or is 'mock and pray' just the industry standard for a reason? Don’t worry about hurting my feelings, I just need to know if I'm solving a real problem.
For a bit more context, most email infrastructures I’ve worked with are for transactional and marketing DTC and B2B companies. I would read my response in this context.
Re one-time setups and one-time changes: I think this will answer both questions and the implied PMF question as well. For internal FTE staff, this will be handle as a one off exception consistently (it’s really no one’s full-time job or responsibility). You may wish to speak with teams that offer professional services / SaaS including self-hosted where this infrastructure would be helpful. Their jobs are made easier with additional predicable / dependable infrastructure software (ie chat with (a) Twilio’s messaging team which remains the SendGrid acquisition, (b) related Red Hat / IBM) vs more work for an individual who is just doing this one-off. You may wish to consider a revenue share and/or white-labeling as they co-install the infrastructure for your business.
Thanks for that perspective. My goal right now is not money, I just want to build something super helpful. If I can make some cash later, in a way that helps everyone, like with white-label or pro-services, that is great. If not, I am cool with that too.
Building the community is the priority. If I do not solve a real problem for people, then the rest does not matter anyway.
Really appreciate you taking the time to share that 'pro-services' angle. It has given me a lot to think about.
What’s next 5 years look like given that you are very good at building long-term projects that last and evolve through time? And for a very specific example, what’s the plan for incorporating new standards like Agent Skills as they quickly evolve and launch?
short term: yeah, we should totally add agent skills asap! new year's eve goal?
as far as long term plans go, i like the tim o'reilly quote: "create more value than you capture".
with selenium, we created an entire ecosystem of tools, users, companies, and economic activity. (literally billions of usd -- it's a story frequently ignored by the tech press when looking for "open source success stories".) but i hope to do the same with vibium. there will likely be a hosted "vibium.cloud" hosted service. i also hope there will be lots of them. in a similar way, there weren't many "hosted selenium" services when i started sauce labs. now there's a bunch. browserstack, lambdatest, etc.
it was also not really an accident we did that with selenium. there is a lot of behind-the-scenes consensus building that happens to make things like a w3c webdriver standard happen. (funfact: vibium relies on the new! w3c standard "webdriver bidi" protocol heavily inspired by the chrome devtools protocol used by playwright. (tl;dr: it's just json over websockets.)
i'm betting on industry cooperation, standards, and shared prosperity. that's my 5 year plan!
Can you share more about the challenges ran into on the benchmarking? According to the benchmark note, Claude 4.5 Opus and Gemini 3 Pro Preview exhibited elevated rejection and were dropped from TruthfulQA without further discussion. To me this begs the questions, does this indicated that frontier closed SOTA model will likely not allow this approach in the future (ie in the process of screening for potential attack vectors) and/or that this approach will only be limited to a certain LLM architecture? If it’s an architecture limitation, it’s worth discussing chaining for easier policy enforcement.
And if you want to read about open source vs source available, this GitHub with the Red Hat lawyer and co-author of GPLv2 provides a TLDR of the sentiment. The reference from Chad gives a deep dive into the discussion and origin of FSL’s language.
Having done this for Gemini CLI to get it to behave well several months ago to have a non-coding LLM CLI without costs, I can attest that these tips work well across CLIs.
Please do in the repo, and thank you for the wonderful contribution on multiple fronts. This is very well done work and documentation. A few tips to help others discover the value on the Readme: Add the key memory benchmark (currently just above the acknowledgments) to the top of the Readme and link to the rest of the benchmarks on the page that you already have (maybe rename it benchmarks.md in the process): https://github.com/Dancode-188/synckit/blob/main/docs/guides...
That's a great suggestion. The memory benchmark being buried is a fair point. I'll move it up top and create a proper benchmarks.md page. Thanks for the detailed feedback.
I was going to say please use and donate to 'Dollar For' [1] which provides this service, which is likely a better choice for this type of problem than trying DIY.
The business edition of Wispr Flow does this well, and includes sharing among teams so you can make sure that the company wide vocabulary is consistent and well recognized.
+1 from another happy Whispr Flow power user. I tried 4-5 similar apps and even built one with Assembly AI, but Whispr is a significant upgrade above the rest for correctly recognizing my accent and jargon. Having the custom vocabulary helps.
RE setup and testing: Trust (as is most devops one-time setups). Once the initial email setup is complete, you typically aren’t paying with it much. The black swan outages aren’t really an active concern.
RE PII: email is non-secure and shouldn’t have sensitive data in production either. Also, dev/test shouldn’t have PII in regulated industries as a good hygiene practice (I’ve worked in healthcare, finance, and national security contexts).
Re licensing: I appreciate your openness and clarity on the licensing of the gateway engine as AGPL vs MIT for the rest. There’s a more modern licensing approach with FSL-1.1-MIT. It may be a better fit for customers (ie clear licensing terms when using a paid license and less concerns if the business goes defunct or pivots) and for your business plans.
reply