jzelinskie

I wish the references to Spanner included exactly what aspects; as it's presented here is very hand-wavy. Assuming he means syncing physical clocks with uncertainty windows, those windows have tolerances acceptable for batching together transactions, but probably not every casual dependency within any program. If he means waiting out _logical_ clocks' uncertainty window, isn't that serializing everything?

I'm definitely going to read more about this work to learn more!

If you are seriously considering SpiceDB and our approach to telemetry bothers you, please do us a favor and open a GitHub issue (or find an existing one if someone beats you to it) and include your perspective. We want to be respectful while also maintaining a feedback loop to be able to improve what people use. We do a lot more than I've seen others do to communicate when/when/how/why we collect and how to re-configure (off or collect it yourself) so those who wish to opt-out can immediately. If this is not the right balance or our solution is just entirely wrong, it's important for us to understand why and improve rather than alienating folks.

I love reading posts like this because it shows that authorization isn't as niche as it once was. I also empathize with avoiding dependencies when you ship enterprise software for running on-prem; we abused Postgres a lot while serving enterprise customers for Quay before we founded AuthZed/SpiceDB. As an engineer it's your job to decide when is the right time to use a dedicated system or continue to invest in your own.

I can't help but see the similarities in their design to concepts from Zanzibar/SpiceDB, and that's great! It also means if they ever do encounter a situation where the existing system is no longer viable (engineers leave or a new design constraint requires rethinking), they _can_ migrate to a dedicated solution easily.

One trade-off I didn't see acknowledged in this post is the sacrifice in terms of tooling. Dedicated solutions have toolchains for debugging and proving correctness that you can integrate into CI/CD and homegrown solutions can't typically spare the time to also build themselves a nice toolchain.

This is interesting, but I think most enterprise AI buyers probably aren't looking to buy from the current batch; they're just too volatile at that stage. This does seem like an opportunity for cross-pollination where early start-ups get to test their product signals and enterprises get to see what's on the cutting edge.

This seems more beneficial to the founders because the the enterprises could instead just choose to do some research on the start-ups. It's not like the start-ups are keeping their knowledge quiet because for them to survive they need to convince everybody what their doing is meaningful.

Has anyone on HN gotten the horseshoe crab pin and can share the story?

Love this museum! It's child and adult friendly. They also have the best souvenir: a collab with a local brewery for wild ales (sour beer)!

Lots of very bad uses for JWTs for service-to-service communication, too. There are often way more standard/foolproof alternatives than how lots of people use JWTs on the backend.

I feel like discussions like these usually will surface PASETO/Macaroons/Thin Mints as the fix without acknowledging that the complexity of distributed token passing with arbitrary attenuation isn't a fit for most use cases.

That all being said, sometimes JWT is the right solution for the job! It's the core skill of software engineering to be able to take in all the arguments and tradeoffs and make the right choice for your scenario.

Full disclaimer: Take what I say with a grain of salt because I build a project (SpiceDB) that advocates for a more centralized approach for one of the backend JWT use cases: fine-grained authorization.

Sorry for the "asking for more"-style comment, but it would be amazing if this came in epub and not just PDF.

"Understanding _using_ singleflight in Go" would be a better title. This generated article doesn't give the reader a real understanding of the implementation and its various tradeoffs that you might care about depending on your workload (e.g. should the first execution to reach a key spawn a goroutine or is that allocation too much)

That being said, singleflight is a fantastic library and pattern that helps so much with p95 latency. It's a little noisy code-wise, but if you use it in the right places the gains are huge.

Also, totally agree with the below comment that recommends janos/singleflight -- start there, but most of the critical projects at my company, AuthZed, have reimplementations with tailored semantics.

I think I need a deeper-dive into the "diagonal scaling" presented. From my understanding, this is actually no different from "industry decoupling" he disparages earlier in the presentation. There are even off-the-shelf libraries for LSMs backed by object storage like SlateDB.