hodlbod

You're being too prescriptive. If it helps though, I could put the following in the NIP: "clients that implement this NIP SHOULD NOT screw it up."

> we will have a security nightmare to deal with Do you have a particular scenario in mind?

> We should get a real audit at some point. That would be helpful, but you're talking about implementation bugs, which would require an audit of _all_ implementations in a...

Yeah, I agree with @vitorpamplona, NIP 32 specifies that labels applied to non-1985 are self-labels, not labels of the target. This was probably overly-prescriptive, so it might make sense to...

I'm still a chicken, but now I'm building something that returns conversation keys to the client (because you can't do encryption with frost), so consider my objections invalidated now.

Just include multiple `k` tags. They're for indexing, not for describing the tag values which should be unambiguous based on prefix.

This has been tackled a few times: https://github.com/nostr-protocol/nips/pulls?q=is%3Apr+is%3Aopen+kanban+ I'm not sure how active any of these proposals are, but that would be a good place to start. Based on your...

I think this is fine, although somewhat at odds with the idea that keys are a user's root identity (which is philosophically debatable). Distinct from but complementary to #2137. It...

@fiatjaf's suggestion pushes this back towards #2137, with the addition of kind 1111 comments (which can be done anyway they're just not in the proposal).

It seems like the benefit of interoperability is significant, so I would lean toward using PGP keys. We could do something similar to marmot's key package by allowing users to...