Needed this. Thanks.

Your welcome.

Let's see what the common denominator has to say about this!

I really think this gets at the heart of the distinction between language as it pertains to how we connect with others and language that records our observations of the world and its history.

I think the ideal mode for engaging with LLMs should be as interactive encyclopedias. They are excellent at rewarding curiosity when someone passionate about learning sits in the driver seat of this kind of tool. There is something to be said about the benefits of _active_ learning over _passive_ instruction.

Nonetheless, it's impossible to consistently discern fact from fiction when in the form of narrative. As such hallucinations are the key counterexample for why we can't have a world where LLMs can be effective instructors. Because it's one thing to be exposed to the structure of a narrative, and to read it as grammar, but you don't ever know how to _feel_ about these structures until you become tuned to another human being.

Women don't get anxious about social status? TIL

Perfectly safe. I would argue that it is the safest of the three, the least invasive both in terms of its design and in terms of privacy.

The open source model of development has encouraged the correct incentives for people to become active in identifying and fixing possible exploits in a global, communal effort.

Every server on the cloud has (by a large margin) chosen Linux as the OS to trust specifically for this reason.

for most people linux is the least secure. linux assumes the user knows what they are doing, whereas windows and mac os assume the user needs protection.

I would not go as far to say that they exist in a bubble. I quit my job as an engineer because this exact sentiment from my boss was ruining my life.

I'll take three hours instead and hop on a train to get brunch.

I agree that it is relative, but disagree with your conclusion. I think the relativity you have in mind is what we normally think of as a setting.

I've been iterating on sodium bindings in Lean4 for about four months, and now that I've gotten to Ristretto255 I can see why the author is excited about its potential. Ristretto is a tightly designed API that allows me to build arbitrary polynomials on Curve25519 and I've been having a blast tinkering and experimenting with it! If the author by chance reads this, just want to say thank you for your work!

You have a public repo of this?

Yes: https://github.com/rj-calvin/sodium

The bindings are set and have a monadic interface, but there's some abstractions that still need refining/iterating: mostly I want to be able to formalize keyboard input and eventually build a tactic framework for zero-knowledge proofs.

I've been writing [libsodium](https://doc.libsodium.org/) bindings in Lean4 and have ended up using `native_decide` quite liberally, mostly as a convenience. Can any Lean devs provide a more thorough interrogation of this? Should I go back and try to scrub its usage out of my library? Logically it seems consistent with what I'm trying to do with Lean4's FFI (i.e. you really do need to explicitly trust the Lean kernel since I'm adding nontrivial computation using a foreign cryptography library) but I'm curious if this isn't necessary and whether Lean devs would push back on its use.