For your use case you need ephemeral pubkeys sending encrypted messages.

The design of nostr builds its censorship resistance on the fact that events are not bound to any one relay. They can be re-submitted to different relays. But relays have to filter spam, which is hard with ephemeral keys sending encrypted messages.

This dilemma already led to paid relays that only let paying pubkeys store events there or to throttling and time-constraints, making it hard to re-submit all my events to another relay.

I think, we need relays that charge sats first thing when opening the websocket and then credit that balance with what gets requested and sent. Then, relays could charge for example x3 for encrypted events and x2 for ephemeral authors, all without the need for long-lived pubkey-relay relationships. With these things in place, GiftWraps are ok. Without DM and GiftWraps, maybe we don't need these things. (I think we should have these things regardless.) 

 I agree with most of this. But I don't think GiftWraps make spam filtering impossible. It's just a different way to do it. Because the event is private, the relay must rely on Reports (or Deletion events) from the author of the p-Tag that the GiftWrap is sent to. Clients can help relays filter these events out when they are in-fact spam. 

I think people are waaay to stuck on the current way of filtering spam. Also, I expect to see relay operators that will only deal with GiftWraps. And I would go further to say that they will become the most used relays because most of the information traveling through Nostr will be private in the future. 

To me, P2P is now a must. If we truly care about decentralization, P2P should be an option in the toolkit. Relays will always be there as a fallback, but they don't need to be the only game in town.  

 > Because the event is private, the relay must rely on Reports (or Deletion events) from the author of the p-Tag that the GiftWrap is sent to.

Wait ... so these events are sent to identified pubkeys? What if the recipient's client can't decrypt the event ... cause it's just garbage? Who's going to report this spam? 

 > these events are sent to identified pubkeys?

On the most basic version, yes. Clients can use aliases as well if they want additional privacy. And those aliases can also be independently registered with relays or simply used to write Spam reports or deletion events. 

> What if the recipient's client can't decrypt the event

It doesn't matter if they can or cannot decrypt. If they are listed as a pTag, they are the only interested party in the event. If they are reporting spam, it is spam and can be deleted.  

 But what is the incentive for them to mark it as spam? What is the incentive to not flood the system with events that then clients have to mark as spam, without even knowing where they came from?

I feel like such a scheme would urgently require the sender to pay the relay to store-and-forward and pay the recipient to bother decrypting it. Else, spam will just remain undetectable and a burden for all. 

 If people are sending me DMs I don't like, I am marking as spam. It's as important as it gets. Otherwise that message will be polluting my inbox forever.  

 On primal, if I don't follow them, their DMs are on a separate tab which I would not check all the time. That's also how the big social media platforms do it. I found a guy's bag and tried to contact him on Facebook and Instagram. He hasn't seen my DM for weeks now as these DM's don't get shoved in his face as they shouldn't.

On nostr we could bribe the recipient into reading our messages but otherwise, unsolicited messages - from ephemeral accounts even - should never cause some inbox notification. 

 There is a big difference between new requests and spam. New requests are fine. People are never going to report them. But everytime I see an impersonator DMing me, for instance, I report right away. Because otherwise I might fall for the impersonators trap in the future when I am not paying attention.