[1]: https://pnpm.io/settings#minimumreleaseageexclude

My understanding is that the switch statement was for npc character conversation text. That seems pretty reasonable, even in enterprise SaaS for something like translations. It might not be as easy to maintain in other circumstances.

[1] https://zed.dev/

I find mongo alright at producing a short-lived prototype of an application (e.g. school assignments), but the risk of it shipping to production for a long period is too risky for the “benefit”.

Some aspects that I feel aren't talked about as much are things like:

- How to store records of personal auth tokens (like GitHub personal tokens)

Using JWTs for these kinds of tokens is widely deemed a bad idea because it's not revokable (without changing the JWT key and essentially revoking all tokens signed with the same key). What I hear is that just generating a token with cryptographically random bytes is good enough for most applications, but does one just store those bytes raw in the database? Or is a hash stored? Or does the database record have an id and hash (similar to a username/password) and the token given to the user is an encoded string that contains the id and raw token? Most things I find when I search "How to store record of token in database" are questions about how to store an auth token given from an OAuth2 handshake or how to store a GitHub token securely. Nothing about how the identity service itself stores a token.

- How to store (or not store) records of one-time auth tokens like email auth/verification tokens

Similar to the above token question, though the threat model seems a little different because they're not long-lived tokens.

- Best practice for uphashing password hashes

I've played around with this idea of needing to rehash password hashes. For example, say you have password hashes a bcrypt hashes with 10 rounds. Then it's decided that bcrypt with that many rounds isn't great anymore with today's hardware and you should bump it up to 14 hashes, or switch to a different algorithm. Next time people login, you could use the old algorithm to validate then hash the password while you have it in plaintext, but what about the users who don't sign in? Couldn't you instead store the layers of hash rules (like the algorithm, salt, number of rounds without the hash) and the last "layer" be a hash with the latest algorithm? I vaguely remember someone suggesting that somewhere here, but when I tried to implement it, there wasn't really a standard format for storing those hashing rules beyond the PHC format that argon2 uses.

The goal of learning these sorts of things is not to go off and write my own auth service. At this point, I feel like rolling your own auth is treated a lot like rolling your own crypto: Leave it to the experts. But without expert writings, how are we to learn and maintain existing systems? Or attempt to improve them? Perhaps I'm just impatient and haven't spent the requisite time searching, but I'm hoping to get some ideas from this community.

Comments URL: https://news.ycombinator.com/item?id=35215500

Points: 2

# Comments: 4

You can use `tsc` to export the types defined in jsdoc and other projects that import your module will get all the intellisense and type checking as if it had been written in TypeScript.

    computation() |> then(&Map.put(my_map, key, &1))

Not saying it’s the best reason, but a reason nonetheless.

They made this change with a 6-month trial period where we would determine if we would keep it at a later time based on some sort of productivity measurements. Everyone, including the CEO, seemed to agree that trying to measure productivity would yield few meaningful metrics. The consensus at the end was that productivity was either the same or a little less, but we ended up keeping it anyway.