@Infinity x2 tested it and it works with existing relays right now!

Not a bad idea, although I could see nasty bugs happening as a result. Wouldn't fix spam though, would just allow deletion.

Not a spam solution, because spammers will not add the ephemeral key to their spam messages. You will only delete from compliant sender's, which are not the problem.

The only way to prevent spam while staying decentralized is to send an "authors" filter with every query. Any query without an authors filter is susceptible to spam. Therefore we must add an "authors" filter to NIP-17. The best proposal so far is to precompute the nip44 shared secret of everyone you follow and query by those authors. But we will need to extend signers to allow safely signing events with it.

Wrong, the only scalable and decent way to prevent against spam is by picking relays that enforce limits and reading from such relays on a case-by-case basis. If you rely on an "authors" filter and blind relays you're limiting yourself to only ever seeing stuff from people you know and never learning that other people exist in the world -- or every client has to perform complex and costly computations locally that then make that "authors" list so big that relays will rightfully reject it. In other words: enforcing restrictions once per write is much more effective and efficient than trying to enforce them on every read.

> I found a simple solution > Not a spam solution > The only way to prevent spam I personally don't believe spam currently can be solved with some single magic pill; every solution has limitations. If nothing is perfect, something better could emerge out of an intersection of the least damaging things. > because spammers will not add the ephemeral key to their spam messages. You will only delete from compliant sender's If we decide it's a useful and safe feature, we could make it a spec requirement. Not having the key from a non-contact (whoever we never responded to) could be one of the heuristics for spam (supplementable by locally running spam detection models, public trust rank, etc.): these messages could be put into a "potential spam" UI folder.

>If you rely on an "authors" filter and blind relays you're limiting yourself to only ever seeing stuff from people you know and never learning that other people exist in the world That is exactly my take.

You realize your statement contradicts your other position on the Outbox Model? Which is that you should connect to whatever other random relays people tell you to connect to.

The gift wrap spam will not necessarily follow the rules. for e3xample the gift wrap generator I made explicitly creates invalid gift wraps in order to break apps

No, it doesn't. You connect to random relays and fetch only from specific authors from such relays, that's in one scenario. Then there is a different scenario in which you want to open yourself to reading stuff from strangers, in that scenario you choose relays wisely and take what they give you. That's the fundamental duality of Nostr, or something. @Constant has written many notes about it, made videos, even gave a talk about it. He explains it better.

I think it important to point out here that the crucial factor here is scale and efficiency. Grimmoire was/is a client that demonstraded more fancy queries, and you can do all sorts of things that way. But insofar every-day use concerning large sets of people and a lot of events etc etc, the day to day way to do this is to rely on relay-feeds (that may or may not have done all the heavy lifting for you, leveriging those fancy queries themselves). What is boils down to, is that 'location' is still important, but that identity (by extension social graph) and content/data is not strickly bound to a location/server/relay. So whenever for whatever reason, one of these relays you have been leveraging (for what they are good for) starts acting up, you have means/alternatives such that you don't instantly become marginalized down to your own website or some alt-platform neither of which anyone will ever visit ever....you probably won't even have to leave your app to 'reconnect' with someone

I will point out that Alex did state that his remark in the context of it being decentralized. So in that sense he is right. The point is that decentralization and scaling/efficieny don't mix well in this regard, so we can't expect that method to do everything for everyone all the time.