Are you using the simple mechanism that I used with Indra - the messages include a return address, in this case a pubkey to use in a reply? It just seems so obvious to do this, and clients and relays store all the messages, it's really a client side thing to implement.

The state is on the relay this way, no need to complicate the client, it just looks for the events tied to the pubkey, finds messages, decrypts them, finds other keys to use to find DMs, requests them, etc.

I don't see the exact reason for the need of any other complications other than anonymization, which I think is best kept out of the protocol, because anonymous relaying is very easy to abuse (see recent Tor hidden service spam problem).

With a scheme like this, only the relays are privileged to know who is asking for what pubkeys. This is the thing that Tor defends against (or other proxy/VPN). It does not expose chains of messages to casual inspection by querying for DMs for a pubkey.

It would also be quite simple to have relays require auth on the pubkey to fetch DMs, also.

I don't follow your work that closely but I always appreciate it and use your client religiously. Nobody else makes it as well, although there's a few abandoned pieces in the interface you maybe should remove until they get actual use (soviet memes are dead lol). 

 I'm not quite sure what you're describing here, the summary is that I use the inbox model to send shared keys to members. Those invites have relay hints to help them find the group. Everything is wrapped using the nip 59 draft. You can read the spec here: https://github.com/nostr-protocol/nips/pull/875

Thanks for liking coracle! The new release removes several old features which I hope to revisit later. 

 oh, this is not related to DMs and encryption schemes.