I very much suspect that this depends on how you use it. You can use it to dig yourself a hole as much as building a ladder to get out. To me it always comes down to whether you focus on cultivating internal impulses that are helpful vs unhelpful to you. LLM can probably help you cultivate most aspects of yourself that you want to focus on.
"The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." - George Bernard Shaw
I think that not doing partial-identity checks invite bot noise into conversations. We could have id checks that only check exactly what needs to be checked. Are you human? Are you an adult? And then nothing else is known.
Identity checks do not prevent bot noise. They just increase the difficulty for bot operators a bit (steal / buy identities or verified accounts). Added bonus for them: Their bot comments now appear more authentic.
There are better and there are really really bad ways to do ID checks. In a world that is increasingly overwhelmed by bots I don't see how we can avoid proof-of-humanity and proof-of-adulthood checks in a lot of contexts.
So we should probably get ahead of this debate and push for good ways to do part-of-identity-checks. Because I don't see any good way to avoid them.
We could potentially do ID checks that only show exactly what the receiver needs to know and nothing else.
> We could potentially do ID checks that only show exactly what the receiver needs to know and nothing else.
A stronger statement: we know how to build zero-knowledge proofs over government-issued identification, cf. https://zkpassport.id/
The services that use these proofs then need to implement that only one device can be logged in with a given identity at a time, plus some basic rate limiting on logins, and the problem is solved.
Thank you - this gets way too few attention especially among tech folks. People act like uploading your government ID to random online services was the only solution to this problem, which is really just a red herring.
The challenge here though is to prove to the user, especially without forcing the user to go into technical details, that it is indeed private and isn't giving away details.
The user needs to be able to sandbox an app like that and have full control of its communications.
BankID is very convenient but the lock in is ridiculous. Owned by a private company and pretty much every service that you use depends on it. You're forced to own a new Google-approved Android or iPhone to use it and to function in society.
We definitely need a vendor independent ID system.
My only objection here is that technology wont save us unless we also have a voice in how it is used. I don't think personal adaptation is enough for that. We need to adapt our ways to engage with power.
I think I see your point. I've had it in the back of my head too.
Guess it's like the separation between backend and front-end. When the logic is neatly wrapped in a nice API you can potentially get a lot of reusability from that since the API can be integrated into other things with other use cases.
But a TUI probably doesn't naturally come with a separate backend. However, if a cli is built in a non TUI way it is about as flexible as a backend. Output can be streamed into pipes etc.
I can't stream k9s output into a pipe or variable but I can with kubectl.
Would be nice if we could have the cake and eat it here. Can TUI frameworks encourage having it both ways?
reply