Updated Inkan is out, based on Jumble. This is a key rotation system. I think it works, or at least I'm using it. Let me know if you'd like to try it out. #nostrdev

Trying to understand where the zap counts and zap lists in Nostr clients come from. Maybe it works roughly like this. A user associates a lightning address with their pubkey in their profile. Others then send zaps to that lightning address, using an LNURL server and a mechanism by which they specify the intended recipient pubkey (i.e. presumably the pubkey in whose profile the lightning address was found). They can also specify a Nostr event ID alongside their payment, to indicate what event the recipient pubkey is being tipped for. The LNURL server broadcasts 9735 receipts to relays which are signed by the server. These receipts contains among other things the sender pubkey, the recipient pubkey, and any Nostr event ID that was specified by the sender. The LNURL server is trusted to provide correct information. Nostr clients then collect whatever 9735 receipts they can find that refer to a given Nostr event, count up the known zaps, and generate lists of sender pubkeys that are displayed underneath the event. Nostr clients can also count up the total known zaps received by a given pubkey. Other than the signature on a user's profile, there does not seem to be any cryptographic relation between that user's pubkey and the lightning address to which zaps intended for that user are sent, right? I.e. there is no cryptogrphic guarantee that the specified lightning address is correct or current for the profile pubkey. If a user were to change their lightning address in their profile, would clients attribute payments made to both lightning addresses to that user's pubkey and add them up - it seems maybe yes? Also, it seems that NIP-57 allows 9735 receipts to specify a recipient pubkey and a Nostr event even if the recipient pubkey is not the actual signer of the Nostr event. So you could zap pubkeys for Nostr events that are not signed by these pubkeys. That actually seems desirable, but do clients have a protocol for how such zaps are attributed?

What do people use for a web-based Nostr client? Recommendations? #asknostr

I found the "nostr key rotation discussion" - this must be it:

GitHub

Key migration by staab · Pull Request #2137 · nostr-protocol/nips

This NIP was sketched out in a session at nostr.xxx. It's based on @pablof7z's original migration proposal with some elements from #2114. D...

Inkan takes a different approach, but I think it's pretty relevant. It's a prototype showing one way in which key rotation can work in practice. cc: @hodlbod @fiatjaf @Vitor Pamplona @PABLOF7z @Nathan Day View quoted note →

So I’ve been thinking about the question “What if Nostr keys were revocable and replaceable?” The thing I came up with is Inkan. I’ve now set up a lab bench for it at

Inkan

A user-friendly Nostr client for exploring relay feeds

There are a few ways you can poke at it: 1. If you just go to

Inkan

A user-friendly Nostr client for exploring relay feeds

and log in with NIP-07, you’ll get a very plain Nostr client. You should be able to read, post, follow people, etc. For posting you’ll need to add your own relays under Settings > Network, as the Inkan relay isn't wired in at this access level. The client is pretty basic, but if it works for you, feel free to use it. 2. Once you’re logged in, you’ll see an “Inkan Agent” status light in the top right. That’s the thing that drives the identity logic. By default this light will be red: you’re not on the allow-list. The key to understanding Inkan is to watch how the Agent behaves; if you’d like to get access, let me know and I’ll try to cycle people through a small temporary allow-list so the backend doesn’t melt. 3. If, after watching it, you’d like to run an experimental identity of your own, let me know. If there’s enough interest (and capacity), I’ll publish a short “how to”. And if anything doesn’t work — broken site, can’t log in, can’t access the Agent, etc. — please tell me. #nostrdev

At the risk of harping on the same theme: Nostr private keys should really be kept in cold storage.

It seems to me that many people would use nostr differently if they had a higher degree of confidence that their nsec will not at any time be compromised. There is probably disagreement on this point, but it feels like it's probably correct.

Regarding Opentimestamps: NIP-03 says: "The OpenTimestamps proof MUST prove the referenced e event id as its digest." Wouldn't it be preferable if the proof were to have a concatenation of the reference event's event_id and its signature as its digest? Also, I find it useful to tag the reference event's pubkey and signature in the OTS event. #nostrdev