aeonik

If only social media platform let individuals sort messages by time, and filter messages based on their friend groups, and weren't forced to view feeds controlled by algorithms they have no control or insight over.

I agree with everything you state about squeezing data out of sensors.

But, I also run into a LOT of cases where I need better sensors too. I just don't see them as mutually exclusive.

I did stick my comment into an LLM, annoying, I hand wrote the entire comment, and had it fact check my statements. Here is my original unmodified comment:

    Eh, there's too much here for me to give a proper reply.

    I agree with a lot of what you said, and I'm on team sensor, but I've been studying how the eye works and processes info.

    A *system* of many sensors can cover larger ground for sure... But I'm very interested in compact systems that can be better than the eye or ear, I know we can do it, I just haven't seen it yet.

     Also, AI and/or filtering can't give you data that wasn't picked up by the sensor in the first place.

     There are limits in the sensor, and there are also limits in getting the data off the sensor. That's true for biology and hardware.

    I'm pretty excited to get my hands of Quantum Dot cameras for example, but even they don't have the same Dynamic Range as the human eye, but could probably beat it with clever systems engineering.

Humans have better dynamic range for hearing and vision compared to any sensor I'm familiar with.

Human vision is also extraordinary sensitive, with some people being able to detect individual photons with their rod cells.

Lemma, Theorem, Proof, Repeat.

Arbitration in CAN is still one of the coolest things I've seen at the hardware layer.

Being able to handle a collision without needing the higher priority message to skip a single beat seemed like magic to me when I first learned about it

This would work, but the first stage hash is effectively the password at this point.

    Client:
        C = SHA256(password)
    
    Server:
        V = Argon2id(C, server_salt)
    
    Database:
        stores V and server_salt

It depends on the bacteria living in your mouth.

Some people get lucky, and even with low brushing, won't get cavities.

The point of a hash is that the password is not stored on the machine long term. Thus, if an attacker gains access to the back-end and exports all the hashes, you can't reuse the hashes themselves to login. I.e. you need to do a password-cracking attack, which is infeasible with a password of sufficient length.

I don't care if someone gets my password hash. They aren't going to crack it due to the complexity of it.

Here is my hashed password. Good luck:

    $argon2id$v=19$m=65536,t=3,p=1$YTE4NzBkMDIwMjRhMGY5NzU4OTc2ZWY5YzI0N2RjOTY$GSBlUwWxr4BBs+5o5Ye2NphT9PFeWx4ECG6siED9uVQ

You can't use that to login to my system. You can only use it to validate if I give you my password...

The mechanism proposed by the GP is not competence. It's a well-known vulnerability called "pass the hash".

This is incorrect implementation fyi.

You are supposed to send the password, via TLS so it's not in the clear, to the server to be hashed.

If you hash on the client... then the hash essentially becomes the password, and defeats the purpose of a hash. I could just steal the hash and use it.

The name of this vulnerability is "pass the hash"

The ice9 / grey goo of the biological world.

BOSL2 library combined with LLMs really make me fly with my creations.

But it can't verify that for generally intelligent copies of itself.

There is no way for it to formally verify large multi-agent dynamical systems.

It will still need a set of agreed upon behavioral protocols to keep things stable.

Grey goo or paperclip optimizers are real dangers, but super intelligence necessitates these protocols even more than lesser intelligences due to the high leverage and rapid evolution of the systems.