Perhaps we can add a filter command to the NIP-46 RPC to fetch a bunch of messages and get them decrypted, so instead of the client fetching the encrypted DMs, sending them to the nsecBunker for decryption, and then back, the client sends the filter it wants and the nsecBunker replies with the messages directly.

Or Perhaps we could have another approach where the nsecBunker is a relay, authorized clients AUTH themselves, publish to that relay and the nsecBunker/relay signs and publishes the event itself to the specified relays (added like a tag or something).

And for decryption the client just gets the messages decrypted straight in the AUTHed wire. 

 Sure, or just change it from decrypt to getSharedSecret. That should already be enough to solve everything without having to turn the nSecbunker into a relay.  

 I’m struggling to see what would be the benefit of using an nsecBunker at all if the client is going to end up with the secret though, the only reason I would see is to share the nsec with a new client by leveraging this new auth_url response, but don’t know if such a niche user flow warrants this.

Makes sense? 

 You are not sharing the nsec. You will be sharing just the sum (nsec+npub) of each conversation. In NIP-44 its impossible to calculate the original nsec just with the conversation key. 

Clients can then encrypt and decrypt messages but they can never sign for them. That's the role of the bunker.  

 Oh! I thought you were saying to just share the nsec that was in the bunker! I didn't get this was solely within the context of NIP-44! 

 Yep, all encryptions will be NIP-44 in the future. It could affect everything :)