keychat on Nostr: Since we are considering using NIP-17, we delved deeper into it. So, let's revisit ...
Since we are considering using NIP-17, we delved deeper into it. So, let's revisit your question, "What do you think of NIP-17?"
NIP17 defines a message structure as kind1059(kind13(kind14)). We are puzzled as to why it is necessary to apply NIP44 encryption twice.
Kind13 (seal) is responsible for digitally signing and encrypting the message. Since kind1059 has already encrypted the message, there is no need for kind13 to encrypt it again. Therefore, the only role left for kind13 is digital signing. We wonder why the digital signature cannot be directly incorporated into kind14. A digitally signed kind14 would effectively be equivalent to kind1. Hence, we believe that kind1059(kind1) would be a simpler implementation.
Moreover, changing the timestamp of kind1059 messages to a random time from the past two days could lead to relays repeatedly pushing notes to clients, potentially burdening both clients and relays. We are uncertain if this tradeoff is justified.
https://github.com/nostr-protocol/nips/blob/master/17.md
NIP17 defines a message structure as kind1059(kind13(kind14)). We are puzzled as to why it is necessary to apply NIP44 encryption twice.
Kind13 (seal) is responsible for digitally signing and encrypting the message. Since kind1059 has already encrypted the message, there is no need for kind13 to encrypt it again. Therefore, the only role left for kind13 is digital signing. We wonder why the digital signature cannot be directly incorporated into kind14. A digitally signed kind14 would effectively be equivalent to kind1. Hence, we believe that kind1059(kind1) would be a simpler implementation.
Moreover, changing the timestamp of kind1059 messages to a random time from the past two days could lead to relays repeatedly pushing notes to clients, potentially burdening both clients and relays. We are uncertain if this tradeoff is justified.
https://github.com/nostr-protocol/nips/blob/master/17.md