Different random keys, one for each one.
Add members, you can just add new receivers in the inner message.
Its like an email. You add more receivers, they receive it.
sometimes we have to send automated nip-17 messages, using codes. for example in nostr-tools on npm, we tried a lot but when we try to decode it we get invalid mac for no reasons.
or sometimes a client event amey won't show some of them. i believe this one is because of invalid outbox model usage on some clients.
also, are they energy efficient? when i look at the spec we do a lot of cryptography.
Sry I’m still stuck on the random key. One for each what? One random key for each “dm”? One per group member? Unclear, trying to piece that bit together.
The ones with invalid mac I get are very old. Probably from clients doing tests. But we should keep an eye on it.
Outbox model is irrelevant as NIP-17 has its own relay model. It doesn't use NIP-65 at all.
They are not supposed to be energy efficient. They are supposed to be private at the expense of more energy.
1. so, i think we had some issues with typescript crypto package. we just switched to nip04.
2. yes, i meant the dm preferred relay lists, i can see most clients don't care about it.
3. do we have any energy efficient alternatives?