vinney...axkl -- 198d i do want it to have technical bearing, but not beyond what the protocol currently supports. and this is already much more than in view: https://straycat.brainstorm.social/about-trusted-assertions.html we're basically there. replyi do want it to have technical bearing, but not beyond what the protocol currently supports. and this is already much more than in view: https://straycat.brainstorm.social/about-trusted-assertions.html we're basically there.
thread · root 8769fdef…159d · depth 18 · · selected 7174467b…ec8b
thread
root 8769fdef…159d · depth 18 · · selected 7174467b…ec8b
*sigh* I was careless with my security and someone got ahold of the nsec private key for this account. Pleaseunfollow and ignore and don't respond to DMs. I'll make a new one with video proof of identity tomorrow. -AdamSoltys
happened to me too. I still use the garbage nsec cause it's a hassle to start over on nostr.big problem with nostr IMO, but cannot be fixed without a protocol fork.
Disagree. WoT fixes this
How? It's not like Farcaster where you can have your trusted people sign off on a new main key. For nostr therecan only ever be one main key per human. Best you can do is keep it very secure (not easy) and rely on bunkers,signers, etc. we all know the drill .
you precisely can have your most trusted people attest to your new key. exactly what you said.
right but nostr, unlike Farcaster, cannot swallow that. Farcaster your FID belongs to the chain and your mainkey is control over it, so such a thing can work. Nostr the buck stops at your main key, which means you'd beasking clients to do something that clients cannot physically do in terms of stitching old you and new youtogether.
You're right that the tactics are quite different between the two systems, but you're wrong that the generalsolution "impossible" on nostr. It just employs different tactics than Farcaster.Feel free to prefer the blockchain solution if you like.I prefer the tradeoffs on the WoT side.
I mean it's close enough to impossible to do that you'll give up trying. Think through what clients would haveto *actually do* in the case of someone having their nsec taken by an attacker and creating a new one thatfriends validate. It's like subkeys and Vitor's response here, sounds great in theory but when you think throughwhat clients would have to *actually do* to reconcile the subkeys you realise it's a non starter. There's adifferent such list for this main key respawn scenario, but it's equally off-putting.https://image.nostr.build/b4c3a4342cc3433866c83717fd0023bfa4d8896805d74abe3cb0071db68f615b.png
Do you think building and properly decentralizing a blockchain for this purpose is more feasible? Be moreexplicit about what you're proposing as an alternative, if you are doing so.
I'm not proposing anything for nostr. The only thing for nostr is a fork.In the Farcaster case, the core identity (the FID) doesn't change. If you lose the highest thing you canpossibly lose (your main key, as it were) and then your trusted friends vouch for a new main key, once done thattakes control of your FID (as per the smart contract) and you're back on the SAME identity. So you have anold-to-new bridge in the form of the blockchain. nostr has no such bridge, and can never have one.You don't need a chain, but you do need some help from somewhere and that help does not and cannot exist innostr unless you fork it.
You've identified my complaint: the smart contract at the root of the protocol. I should say off the bat, too,that I developed software for Farcaster a couple years ago. I'm not a stranger to it. Let the fact that I movedfrom it to nostr speak for itself.Different sets ofnpubs should be able to decide to adhere to different concepts of trust without the protocolgiving a shit what they do.If _my_ trust network wants "npub's mom + wife have the say over npub's new nsec", then the way _we_ use theprotocol should allow for that. If another group of people want to use another system, they should go ahead andI wish them luck. I'd prefer an open protocol that doesn't enforce opinions about which trust systems areprescribed.If I understand you correctly, you're implicitly saying "the smart contract is the ultimate source of truth" andI'm simply not a fan of that idea. I prefer blockchains be used for timestamping/double-spend and not as the"global state", because I don't believe "global state" is a coherent concept (and I think it's a road to hell,honestly).
There's always an ultimate source. In nostr the nsec is the ultimate source of identity. The nsec is a smartcontract too, just a very tiny one.Point being, WoT will not do anything to help people bridge a lost or stolen nsec to a new nsec in a nostrcontext.And if you don't like blockchains you can achieve this without a blockchian (instead various forms of oldfashioned key pair voodoo) but, again, breaking changes to nostr and a hard fork.
> If _my_ trust network wants "npub's mom + wife have the say over npub's new nsec", then the way _we_ use theprotocol should allow for that.You haven't responded to the meat of this part, but I think it's because I didn't explain it enough:I think you're incorrect that the nsec is the ultimate source of identity. *I* am the ultimate source ofidentity, and the nsec is a layer I use to connect with other people. the same ultimate source of identity canuse a subsequent nsec. operating at the nsec-layer then sure, nostr doesn't have an easy solution - but I'moperating a layer deeper, at the same layer as the ultimate human source of identity. That's why I'm saying Iprefer "trust-maxxing".Bob is a human and Alice is a human. They like communicating digitally. They both agree that Bob's human familyand Alice's human family are great sources to rely on - in human land - for information about each other.Bob loses his nsec. Bummer. But it's just a tool - Bob and Alice and their families still exist the same, humanway. So Alice points some of her digital tools and particular parts of Bob's family's digital tools and shefinds out about Bob's new nsec.The problem has been solved at the deeper, human layer. Our tools are just along for the ride; and they answerto us, not the other way around.I don't need a blockchain telling me what's true, and I don't want a protocol interrupting the way us humansprefer to interact.
None of this changes the fact that what you are suggesting requires a hard fork. It can be done in a"nostr-like" way, but it requires a hard fork.
You leave me with no choice but to assume that you can't read or are unwilling to let what I'm saying into yourhead.
Show me where the fork is buried in what I'm saying.
"you precisely can have your most trusted people attest to your new key"that's what you said, and that's exactly where the fork is buried.Assuming of course that you want this attestation to have some technical bearing. If just for warmth and funsiesthen no fork is needed.
i do want it to have technical bearing, but not beyond what the protocol currently supports. and this is alreadymuch more than in view:https://straycat.brainstorm.social/about-trusted-assertions.htmlwe're basically there.
happened to me too. I still use the garbage nsec cause it's a hassle to start over on nostr.
big problem with nostr IMO, but cannot be fixed without a protocol fork.
vinney...axkl -- 200d [parent] | reply [1 reply]Disagree. WoT fixes this
b90c3cb7…7823 -- 199d [parent] | reply [1 reply]How? It's not like Farcaster where you can have your trusted people sign off on a new main key. For nostr there can only ever be one main key per human. Best you can do is keep it very secure (not easy) and rely on bunkers, signers, etc. we all know the drill .
vinney...axkl -- 199d [parent] | reply [1 reply]you precisely can have your most trusted people attest to your new key. exactly what you said.
b90c3cb7…7823 -- 199d [parent] | reply [1 reply]right but nostr, unlike Farcaster, cannot swallow that. Farcaster your FID belongs to the chain and your main key is control over it, so such a thing can work. Nostr the buck stops at your main key, which means you'd be asking clients to do something that clients cannot physically do in terms of stitching old you and new you together.
vinney...axkl -- 199d [parent] | reply [1 reply]You're right that the tactics are quite different between the two systems, but you're wrong that the general solution "impossible" on nostr. It just employs different tactics than Farcaster. Feel free to prefer the blockchain solution if you like. I prefer the tradeoffs on the WoT side.
b90c3cb7…7823 -- 199d [parent] | reply [1 reply]I mean it's close enough to impossible to do that you'll give up trying. Think through what clients would have to *actually do* in the case of someone having their nsec taken by an attacker and creating a new one that friends validate. It's like subkeys and Vitor's response here, sounds great in theory but when you think through what clients would have to *actually do* to reconcile the subkeys you realise it's a non starter. There's a different such list for this main key respawn scenario, but it's equally off-putting. https://image.nostr.build/b4c3a4342cc3433866c83717fd0023bfa4d8896805d74abe3cb0071db68f615b.png
vinney...axkl -- 199d [parent] | reply [1 reply]Do you think building and properly decentralizing a blockchain for this purpose is more feasible? Be more explicit about what you're proposing as an alternative, if you are doing so.
b90c3cb7…7823 -- 199d [parent] | reply [1 reply]I'm not proposing anything for nostr. The only thing for nostr is a fork. In the Farcaster case, the core identity (the FID) doesn't change. If you lose the highest thing you can possibly lose (your main key, as it were) and then your trusted friends vouch for a new main key, once done that takes control of your FID (as per the smart contract) and you're back on the SAME identity. So you have an old-to-new bridge in the form of the blockchain. nostr has no such bridge, and can never have one. You don't need a chain, but you do need some help from somewhere and that help does not and cannot exist in nostr unless you fork it.
vinney...axkl -- 199d [parent] | reply [1 reply]You've identified my complaint: the smart contract at the root of the protocol. I should say off the bat, too, that I developed software for Farcaster a couple years ago. I'm not a stranger to it. Let the fact that I moved from it to nostr speak for itself. Different sets ofnpubs should be able to decide to adhere to different concepts of trust without the protocol giving a shit what they do. If _my_ trust network wants "npub's mom + wife have the say over npub's new nsec", then the way _we_ use the protocol should allow for that. If another group of people want to use another system, they should go ahead and I wish them luck. I'd prefer an open protocol that doesn't enforce opinions about which trust systems are prescribed. If I understand you correctly, you're implicitly saying "the smart contract is the ultimate source of truth" and I'm simply not a fan of that idea. I prefer blockchains be used for timestamping/double-spend and not as the "global state", because I don't believe "global state" is a coherent concept (and I think it's a road to hell, honestly).
b90c3cb7…7823 -- 199d [parent] | reply [1 reply]There's always an ultimate source. In nostr the nsec is the ultimate source of identity. The nsec is a smart contract too, just a very tiny one. Point being, WoT will not do anything to help people bridge a lost or stolen nsec to a new nsec in a nostr context. And if you don't like blockchains you can achieve this without a blockchian (instead various forms of old fashioned key pair voodoo) but, again, breaking changes to nostr and a hard fork.
vinney...axkl -- 199d [parent] | reply [1 reply]> If _my_ trust network wants "npub's mom + wife have the say over npub's new nsec", then the way _we_ use the protocol should allow for that. You haven't responded to the meat of this part, but I think it's because I didn't explain it enough: I think you're incorrect that the nsec is the ultimate source of identity. *I* am the ultimate source of identity, and the nsec is a layer I use to connect with other people. the same ultimate source of identity can use a subsequent nsec. operating at the nsec-layer then sure, nostr doesn't have an easy solution - but I'm operating a layer deeper, at the same layer as the ultimate human source of identity. That's why I'm saying I prefer "trust-maxxing". Bob is a human and Alice is a human. They like communicating digitally. They both agree that Bob's human family and Alice's human family are great sources to rely on - in human land - for information about each other. Bob loses his nsec. Bummer. But it's just a tool - Bob and Alice and their families still exist the same, human way. So Alice points some of her digital tools and particular parts of Bob's family's digital tools and she finds out about Bob's new nsec. The problem has been solved at the deeper, human layer. Our tools are just along for the ride; and they answer to us, not the other way around. I don't need a blockchain telling me what's true, and I don't want a protocol interrupting the way us humans prefer to interact.
b90c3cb7…7823 -- 199d [parent] | reply [1 reply]None of this changes the fact that what you are suggesting requires a hard fork. It can be done in a "nostr-like" way, but it requires a hard fork.
vinney...axkl -- 199d [parent] | reply [1 reply]You leave me with no choice but to assume that you can't read or are unwilling to let what I'm saying into your head.
vinney...axkl -- 199d [parent] | reply [1 reply]Show me where the fork is buried in what I'm saying.
b90c3cb7…7823 -- 198d [parent] | reply [1 reply]"you precisely can have your most trusted people attest to your new key" that's what you said, and that's exactly where the fork is buried. Assuming of course that you want this attestation to have some technical bearing. If just for warmth and funsies then no fork is needed.