mfbx9da4

The assumption that something always has to change is the culture that leads startups to knee jerk their way into miles of red tape and performative bureaucracy

Isn’t it also easier than ever to learn though? The moat that seniors built around their expertise enabled a juicy buffer of mediocre devs paid mediocre rates pushing up the value of mythical 10x engineers.

How can you tell a human actually understands? Prove to me that human thought is not predicting the most probable next token. If it quacks like duck. In psychology research the only way to research if a human is happy is to ask them.

> A shared secret removes the potential for detection from the service while asynchronous key signing does not.

I would approximate that 95% of the time when a webhook sender discusses signatures they are referring to HMAC (symmetric-key signing). There is a clear benefit to asymmetric-key signatures but that's not the focus of this article. It's discussing the industry convention of using symmetric-key signing.

Webhooks basically never implement asymmetric signing. If you survey the industry 99% of the time if it’s signed, it’s hmac.

> Thank you for helping me understand that I had missed context

My pleasure!

> The signing process retains private signing materials under the custody of the sender

In the signing process, with a symmetric key, the signing materials do not remain under the custody of the sender. Both parties need access to the signing key. If the consumer leaks the key they have to notify the sender and vice versa.

Asymmetric signing is used very sparingly in the context of webhooks.

Sorry if I'm misinterpreting your sentence a little too literally here.

> If you move authentication to the web hook implementer you lose control of what authentication mechanisms are in use

I don't understand where you are coming from. The article is comparing shared secret vs signing. In both those auth methods the "control" remains in the same place. The webhook consumer has to do the auth verification. The webhook sender mandates what authentication method is used.

Under none of these scenarios is the webhook consumer providing their own "authentication system".

The API producer will always retain ownership over the authentication mechanism.

The article is comparing the use of a shared secret vs HMAC. For shared secret: Who specifies auth? The webhook producer. Who implements auth? The webhook consumer. For HMAC / signing it's exactly the same parties who do those things.

Discussions about mutual TLS and public keys are out of scope.

I would be curious too. I think it comes down to the benefits are there and they're cheap enough that they may as well recommend a more secure approach.

Hey, author here. Pleasure to work on this article. I'd welcome strong opinions :-)

This is all great except it’s all in memory. To really fail safe you need to account for crashes and therefore need a persistent queue

What if I'm from the UK and I am still wondering what to click?

Unless I'm being really dumb I don't see an image, all I see is this https://pasteboard.co/hxSXWlzyFepX.png

The code walkthrough was excellent and very elegant

Was hoping for more of a high level technical explanation of how it differs from alternatives in the FAQ

Well I've done something now...

Hopefully this feature request is now fulfilled

Ah thanks for letting me know, that's a very old project and I lost access to that domain because I missed the expiration emails.

Unfortunately, I didn’t take that photo

I personally feel that right now my mind is sharp enough to be an engineer but looking at my parents, in 20 years I can't imagine I will be able to operate on the same level ¯\_(ツ)_/¯

I think this is kind of missing the point. The fact that the underlying implementation is not a hand-coded-deterministic one is the interesting thing about this demo. This is clearly going to be useful by making people more efficient and only going to get better with time.

Really cool! Was thinking to build something similar myself as a side project. What is the tech stack? I would be curious to learn more about how it works.

It strikes me that touch typing prose is actually very different to coding due to all the symbols. Also unlike prose, a lot of time is spent editing or refactoring the code. How much would you say your typing competitions actually have an impact on your coding speed?

As an aside I think the non-null assertion operator should be transpiled via Babel from

`userId!`

to

`if (!userId) throw new Error('Non-Null Assertion Failed "userId!"')`

Just use zod?

Cool project!

Example? I don't see the link

I don't think "Offline Is Just Online with Extreme Latency" is a useful concept because it doesn't encapsulate the key difference: pessimistic or optimistic UI.

For example, say you have a form. If you built it thinking online first you'll probably have some pessimistic UI which shows a spinner and waits for the server to respond with ok/error. You can't simply think, okay since we're offline, more latency -> show spinner for longer. You have to re-architect things so that the UI is optimistic, commits to a local database and that local database is synced up to the server when you come online.

In my experience optimistic UI is way more complex to build. Many times the complexity is worth it though.

> We then used ChatGPT to clean up and categorize all 2-thousand and more roles into 9 main categories. Finally we did a quick manual comb-through to correct any discrepancy.

Yet another example of how times are changing!