Michael Dilger

The problem of exporting a private key can be solved if people were interested in doing so. Gossip has exported private keys in a password-encrypted form since day 1, but...

@alexgleason custom format. https://github.com/nostr-protocol/nips/pull/133 scrypt key derivation, XChaCha20-Poly1305 encryption, associated data to remember if the private key was ever known to be handled insecurely (exported in cleartext, or imported from...

The inbox model has different characteristics from the outbox model. Neither replaces the other and both can co-exist. ... but the outbox model is superior of course. I'm not sure...

There is no way to query for "all kind 1's of author P, plus any deletion events of kind 1's by author P". Unless deletion events always had a 'k'...

I like to think of the ContactList sync problem fundamentally being that you create an event that doesn't account for past events you didn't know about. This can be solved...

Having thought a bit more on this, I'm not sure about my idea. It could be better or worse and I can't decide. You would have to keep old ContactLists...

While there are these other reasons to not have monolithic full contact list events (and those battles need to continue to be fought), I've never been convinced that the current...

Since this is just for migrations, and not for recovery from a lost key, I think the interpretation of a kind-18 is far too strong: > ... declares the key...

I'm ok with this but as implied by @brugeman, specifying the client key directly leaves an infinite window for a leaked key (via a leaked bunker URL) to be used...

That could work to make them more reliable, but I didn't hear the argument from @semisol as to why they shouldn't persist at all (unless perhaps explicitly marked with expiry)....