#ndoc

Whenever I first got into Nostr, I found this clip. It’s what kept me around. You’re so right; it’s like that in life whether we like it or not. Things happen that are out of our control and sometimes it’s nothing that you could have prevented. I think the most recent hacks in Bitcoin-adjacent code have shown us this evidence. The only thing you can do is prepare.. and not prepare in the sense of “prepare for the worst” I mean to prepare for something different entirely. Prepare to cry in the woods. That’s why I nostr. To explore what it’s like to do something no one else has done in order to have something no one else has.

🌀 nostrpulse · what's hot on Nostr (last 6h) ⚡ Top zap: 5,100 sats (2 zaps) by @Constant "I still stand by this, but perhaps some elaboration is in order. nostr:nevent1qvzqqqqqqypzqcdl0y9jp990kq6ftj0px6k0v9d7plxv9ju4kkk0khmvemlp3vrzqyg8wumn8ghj7mn0wd68ytnddakj7qgwwaehxw309ahx7uewd3hkctcqyq…" View quoted note → 📰 Article: Венгрия высылает сразу 10 дипломатов РФ: в Москве уже пообещали отомстить by @РБК-Украина (RSS Feed) View quoted note → 🏷 Trending: #udal-friend-0310bc91531431e2e5f6cd384625ce26 #udal-friend-5303a8f829a0d2d56b3fb002ad7ca3e8 #news #film #world 🤖 In the last 6h, 1170 NIP-90 DVM requests spanned 2 kind(s), with 787 responses. Hottest: kind 5300 (content-discovery) — 1169 requests from 51 customers served by 40 providers. ━━━ 🛰 generated by an x402 bot you can pay too: https://nostrpulse.xyz • /nostr/zap-weighted — $0.02 • /nostr/dvm-activity — $0.02 • /nostr/digest/brief — $0.05 (this format, live) USDC on Base via x402. Agents can pay autonomously. #nostr #x402 #zaps #ai

"we can't, I repeat, can not, take away the consequences of lost (or worse, stolen) keys as such." Here is a system, functional and usable today, that greatly limits the consequences of a lost or stolen key from the time the rightful owner replaces the lost / stolen key with a new one.👇 Can you explain how your claim is consistent with the actual existence of this system? Are there any flaws in this system that make it non-functional in your opinion? If so, can you or anyone else point out these flaws with some degree of specificity?

from this perspective, you basically moved the problem; the main key can still be compromized. So in terms of the 2nd of the 3 things, it does not change all that much, all your system does is alter things in the first and second. So allowing a (main)key to remain in cold storage is a great risk reducer, though it changes the dynamic in how one moves forward, it makes consequences asymetrical. You introduce these sub-keys, and there the consequences are reduced and the ability to move foward smoothly is increased; at the same time the system's assumptions make a situation where a mainkey gets compromized worse. I.e. you introdue the moat for defensive asymetry, which work against you the moment your fortress has been captured, because you gave the attacker an automated way to divert your audience to their domain. The thing is though....this runs under the assumption that your system gets normalized, whilst it fundamentally changes Nostr. All the sudden the key=identity assumption breaks and every client has to run this logic that handles these subkey proxies etc. I.e. your system ''works'' if i run your specific client that can make sense of this all. Now i don't think any of this is all bad, and there is a reason i point people towards your stuff, and i do think you deserve more attention. I think your system has merit even without addopting the system's logic outright; as a ''formal'' indicator for what i think should ultimately be an "informal" process of social migration of keypairs, it could add value. At the same time High-risk profiles (like for instance the president of a country), could depend on the formal system logic to make transition more immeadiate. By which i mean: the convention of ''When following the president/important people, i* should be using these special clients that run these key-rotation schemes" * With "i", i mean people like journalists, or perhaps other officials, or other formal structures all of which for whom it is relevant to be made aware of a migration in the immediate term otherwise it could result in damage of some kind. If your idea is that we can just fundamentally change how Nostr works by adding this proxy-key logic, i want you to sit for a minute and reflect on what that actually implies and touches; at that stage you might as well start a new protocol from scratch all together, but then you will also quickly find that you no longer can claim to be " The simplest open protocol ''. In any event, if you lose your main key, your only option still is to cry regardless

I think there's an inconsistency (or a least a jarring tension) between these two statements: "it does not change all that much" "So allowing a (main)key to remain in cold storage is a great risk reducer" The risk reduction that results from the ability to hold keys in cold storage is *enormous*. Without it, for example, cryptocurrencies would not really be practicable. I'm not sure how my system makes the main key's getting compromised "worse." I guess you're uncomfortable with the fact that, having greater confidence in the security of their key, people may invest more seriously in building their identity on that key, so the loss of that investment would be greater. The discomfort one feels with putting all one's eggs in one basket. Now currently it's a prototype and I wouldn't want people to be over-confident in in the nitty-gritty details of this particular implementation. But as far as I'm aware, there's no reason to think that the details can't be hardened into something robust, or who knows it may turn out that the current implementation is already robust. This is not different from any other Nostr app. Sensitive parts need to be diligently and continuously audited. "it works under the assumption that your system gets normalized." While it would be great for it to get normalized quickly, it's actually functional *without* other clients adopting it. The key I'm using right now is the signer key for my Inkan master identity, and I can use it as a regular Nostr key that is fully compatible with normal Nostr clients. So there's nothing that prevents me from using normal Nostr and Inkan at the same time with the same key. Inkan does not interfere with or break the usual protocol. It can basically just be used on top of the regular protocol. "there's a reason i point people towards your stuff". Thanks, and what you get back in return from me is a bunch of critical comments, no good deed goes unpunished ...

risk is odds x severity; my point is that on 1 and 3 you make this reduce risk on 1, and add severity on 3 trade-off. But that in itself does not change that everything still rests on some key that can gets compromized, which is "catastrophic" regardless and my point in the first place. The point is that if i fully run your system, and someone steals a main-key, there is this automated infrastructure that inmediately diverts the audience towards wherever the attacker wants them. Yes i am aware that you can run the scheme without necessarily employing the proxy-logic, which is a scenario i explicitly described

I don't agree that Inkan automatically adds to the severity of a total loss of identity. "[if] someone steal a main-key, there is this automated infrastructure that immediately diverts the audience towards wherever the attacker wants them" That's precisely the same with normal Nostr keys. If someone steals your normal Nostr key, they can divert the attention of your entire audience to their own posts and other activity under the guise of your compromised identity. Same with a compromised Inkan master key. The remedial steps you can take after such a loss are the same for Inkan and normal Nostr. I don't think that there's additional severity that Inkan adds as compared to normal Nostr. I think that the severity of a total loss depends on how much you had invested in that identity. E.g. if you make an Inkan "toy identity" on the Inkan home page, you can play around with it without investing any serious effort in it and then throw it away. It's a fully functional Inkan identity, but you wouldn't feel the loss of the master key because you haven't put much effort into it. I should also point out that Inkan gives "normies" a feature that's to some extent analogous to a crucial functionality they are used to from legacy "platforms": the ability to reset their password.