The idea is indeed to disallow re-sharing. 

Picture a company relay. All the information should be strictly contained into that main relay. 

However, for Nostr clients to work, they need to verify events by themselves. Which means they receive a full copy of the event and can re-broadcast that copy to another relay very easily.

That creates a problem.

We could just delete the signature field and ask Nostr clients to not verify and "trust" that the company or its relay is not modifying the message from its original author. But relying on trust defeats the purpose of using Nostr in the first place.

Since the company relay authenticates who is connecting to them, it could easily modify the event to make sure only that user can verify it. 

My initial solution was simply to encrypt the signature field to the pubkey of the connecting user. Then the client would have to decrypt it before verifying. The issue is that once the user has decrypted, the user has access to the full signature in plain text and can add it back in the event and re-share it with another relay. 

Which is not really a solution to the problem.

This led me to the question in this post. How do we make a modified event signature that only one user can verify. It could be still possible to allow other people to verify the new event, but that implies having to make the user's main private key public and hopefully there is enough sensitive information in that private key to serve as a deterrant from users doing so.  

 Right, thanks, that helps quite a lot. I do get where you're coming from with the "leak private key" concept, that's of course intrinsic/fundamental to Schnorr sigs so it makes sense to at least think about it as a deterrent.

It's pretty whacky, but this combination gives you something like what you want: imagine 2 of 2 musig between user A and relay R. A gives R an adaptor on its partial sig sigma_A' where the adaptor secret is its own private key. Then R gives sigma_R and A can *internally* verify the full signature on the musig aggregated key against the message. If it broadcasts that full signature, it leaks its private key. 

 Interesting... I need to do some testing, but maybe this is the beginning of a modified Nostr protocol for enterprises and trully private groups.

I do think there is a lot of need and money waiting for solutions in that realm.  

 Interesting it is :) But practical? I guess maybe not? We need a version of these ideas that doesn't involve non-trivial interaction between the client and the server (relay), right? I'm finding myself drawn back to "HMAC"; because that was always the traditional solution to this problem, i.e. only the two parties involved in the conversation can verify. There are so called "algebraic HMACs" that can use EC arithmetic instead of hashes. I'll take another look at that.