But not for ProtonCalendar, and definitely not on Android.
Proton doesn't interact at all with the rest of the ecosystem. I'm not a Proton customer myself, I just hear it from our many customers that are frustrated by their closeness.
@tasn
From 10/4/2014, 10:13:26 AM till now, @tasn has achieved 694 Karma Points with the contribution count of 281.
Recent @tasn Activity
Yeah, but it's the case with all of them. ProtonMail, Tutanota, etc, all of them are walled gardens that try to shove you into their proprietary lands.
I created EteSync[1] a contacts, calendars and tasks sync solution that's e2ee and privacy respecting but people kept on asking us to integrate with one of the above email solutions. Though they are all closed and don't interoperate. :(
Running an email service is just damn hard and it's hard to get people to pay for it. Even if you have the privacy angle.
There's just so much abuse going on, and when you are privacy first you limit your ability to fight abuse which makes things much worse. :(
Congrats on the launch! This is something we plan on adding to the Svix webhooks service[1], and we'll definitely take a look at cloudflare when doing it.
We created Svix Play that gives the Stripe CLI experience to everyone for free: https://www.svix.com/play/
I really dislike Auth0, and so happy to see new entrants in the space. Best of luck, and congrats on the launch!
Get them to start using svix.com :P
Seriously though, that's why we built it, so this all too common issue, won't be a thing for companies.
Just making it clear for others as I had to double check.
The one you're replying to isn't op and is just taking a jab at enterprise pricing.
You'd be surprised (I was), but high memory usage is also a power drain.
> As the popular saying goes, there are only two hard problems in computer science: caching, off-by-one errors, and getting a Rust job that isn't cryptocurrency-related.
For whatever it's worth, we are hiring for a non cryptocurrency Rust job, haha.
Oh, I remember your Show HN. Congrats on the launch!
There are a lot of cool YC open source companies!
PostHog, Supabase, Wasmer, Mattermost, Chatwoot and of course Svix, just to name a few!
Sure, but then you'd want to hide it behind an `--i-really-know-what-im-doing` flag to prevent people from shooting themselves in the foot.
Also, even if the persistence is elsewhere in the stack, it's not obvious to me how disaster recovery will actually work. Same with accounting (e.g. marking a message as sent). I'm not saying it's not possible, it's just not immediately obvious to me how you can make that both simple and robust.
Founder of Svix here.
It's a great question, and there's no one definitive answer. Some context: I've been an open source developer for all my life, my previous business was also open source, and I spoke with a lot of people over the last year about the right license for us.
The main choices are: copyleft like AGPL (you want AGPL, not GPL for server applications), permissive like MIT (which we chose[0]), or so called "fair-code" which are the not-quite-open-source variants like the SSPL.
While AGPL and SSPL are "better for business", MIT is more aligned with our mission, and is better for fostering a community. You can read more about the thinking on our Show HN[1].
Either way though, all of what the stricter licenses do is make it harder for competitors to use your code in their own service. Which is important, but not the end of the world as competitors can always just copy your API, landing page, and everything else.
Founder of Svix here.
I don't know if I'd call us SaaS first, though we definitely spend a lot of time, money and attention making sure our SaaS offering is as reliable as it gets if that's what you mean.
FWIW, I've been an OSS developer and maintainer for all my life (my previous business was also open source), and open sourcing Svix was always the plan. It was literally one of the first tickets I opened for the team, and our first public commit was in Feb 2021.
We've indeed recently announced the open sourcing of our webhooks dispatcher[0]. It's written in Rust, so also a single binary with no third party dependencies. We do NOT however offer in memory storage. This is on purpose, as persistence is a requirement for robustness.
Exactly what the sibling comment said, you can do it in many languages. Also, the comment I replied to suggested just that ("cast to any"), which is the context. :)
This is something I thought about a lot before switching to Rust at Svix[0]. What I came to realize though, that there are no "casts to any and move on", but rather there are silencing real bugs and praying you won't hit them.
Almost every time I've ever tried to silence the type checker (in any other language) it resulted in a bug.
Does it make you slower? Definitely at times, but it's mostly OK, and the code is pretty damn clean. You can check out our repo to see how it looks[1].
Edit: we don't use Actix, we use Axum, but the same holds for Actix too.
I couldn't agree more. Every now and then I let gmail auto complete for me, but it feels like my writing is just becoming generic.
Ping me at tom @ our domain (or see my profile), or come to our slack: https://www.svix.com/slack/
We would be happy to help you set it up!
One day I'll write a blog post about why we went with Rust rather than Go, but I'll resist the urge to hijack this thread for a Go rant. :P
site design / logo © 2022 Box Piper