The fact that NIP-17 requires you to subscribe to two days worth of events just to get one message is extremely inefficient. Either you need to keep track of all seen events in the last two days, or you generate a new pubkey for every message you want to receive (which you then also have to keep track of in most cases). It basically means you can't offer NIP-17 functionality in a stateless library (something always needs to be kept track of). I won't die on this hill but damn... this was a bad choice.
Here is how to implement it with NDK + nostr-tools https://gist.github.com/callebtc/0ed77c137809c7fc7627fe8fd4e9f163
Blocking time-collision attacks is more important than downloading 2-days worth of events.
i suppose the inefficiency is on purpose; if it's inefficient for you, so it's for people that are trying to keep a tab on other people's private messages to me it seems like a clever but kind of circuitous hack around the more conceptual issue that nostr's architecture might not be the best choice as base layer for a private messaging system