Thread

Happens 🫂

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.

Will do Adam. See you on the new npub. 🤙

You know what they say It’s not a bug it’s a feature

Like losing keys. “It’s not a bug it’s a feature “

Can Brainstorm help this guy today/tomorrow nostr:npub1u5njm6g5h5cpw4wy8xugu62e5s7f6fnysv0sj0z3a8rengt2zqhsxrldq3 ?

Disagree. WoT fixes this

Given Brainstorm as it is currently implemented, if a handful of people use NIP-56 to report this nsec, it will only take a small handful of reports to knock the GrapeRank score down to zero, which will prevent this profile from showing up on profile keyword searches in the future, once we have a few search engines using the GrapeRank metric to filter results. Unfollowing helps too but as a general rule, you’re never going to get enough people to unfollow a compromised nsec. Muting will also reduce the 🍇-Rank score but not as much as reporting. NIP-56 does not specify a reportType for “compromised” — maybe we should update the nip? For now, reportType “other” would work best; or just put “compromised” as the reportType even if it’s nonstandard. https://nostr-nips.com/nip-56

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 .

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 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.

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.

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.

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.

Naive WOT doesn't fix any of this

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.

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).

please qualify what you mean by "naive"

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.

> 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.

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.

If I lose this nsec or it gets compromised I think I'm done here. I may use nostr but the bill cypher nym will be dead, any continued use would be under a different name.

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.

Show me where the fork is buried in what I'm saying.

#nostard thinks he's more than just an nsec

"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.

If you want the attestation to be technically meaningful here are few things that have to happen (and that do happen on Farcaster and elsewhere): Everyone who followed your old key before timestamp x (time of theft) now follows your new key, automatic. DMs sent to your old key can be read using your new key (and no longer read using your old key) Posts from your old key show with your new avatar and handle to anyone browsing. And 50 other things. How are these things to happen Nostr? If what you’re suggesting is just a nostr-native alternative to an adding your NIP05 to your new key then we already know what a non-solution that is. And if you want those things above to happen then you don't need a blockchain per se but you need a hard fork.

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.

oh, that's where our miscommunication is. why did this take so long to get to? i don't require that whole list of stuff. i just want to know with some confidence if someone has a new npub.

Ah okay, fair enough, though I'm not sure that's so much of a value add. The real issue is that normies will never accept a network where if you lose control of your account the best you can do is let everyone know you're starting again completely from scratch at some new account. the expectation that you can somehow sort things out after a hack and not lose all of your history is far too engrained.