https://github.com/nostr-protocol/nips/blob/master/57.md

So, most of the NIPs are optional. Technically this is a specification for an optional part of the protocol. Because of the network architecture, basically all NIPs are implemented in clients. So in a sense the person who told you that is right.

But that’s a double edged sword; because most of them are implemented in clients, building a client with different functionality means creating a different network of users. If you’re using a client without zaps and someone sends you a zap you will never know, if you send someone Monero on this client and they’re not using the same client they’ll never know. https://github.com/jesterui/jesterui is an example of a client for playing chess over Nostr, as an example. The people using this client are not the same people talking to each other using Flamingo, and the two groups of people cannot interact without using a different client. This is just a fact of life when you have an application agnostic network. To create a monero focused client is to create a separate Monero focused network. May as well try to make a better protocol specification.

Sending Monero via Nostr (or something like it) wouldn’t necessarily deanonymize transactions, if the protocol for sending them was designed properly. You can’t do things like derive addresses from npubs or the nostr private key, or publish transaction key images. A client could have Monero integrated and have a watch only function that notified the recipient, but nobody else could see it. This way of doing it would not give it the hype that zaps have gotten, because zaps are public, but it would work.

To see just how convoluted the protocol is check this out https://github.com/nostr-protocol/nips/blob/master/README.md

If you decide on the new spec route, I don’t mind helping with the spec, I already have done some rough work on the idea and have a bit of an idea what a good spec would look like.