Motivation. By building out P2P encrypted communication between the sender and the receiver of a payment without changing the existing base layer user workflow, the learning curve of Lightning Network, PayJoin, merge avoidance and some other schemes would be radically reduced, because the user experience would be unified, the robots would handle the heavy lifting.
Background A taproot script exposes the public key, which is essential for this scheme.
Expected Existing Workflow. Receiver gives Sender a taproot Bitcoin address, which has a corresponding public key. Sender sends bitcoins to the address.
Problem. How can we build up P2P encrypted communication between receiver and sender without disrupting the existing workflow?
Solution.
The receiver starts listening to messages on the Bitcoin P2P network.
Sender instead of creating a transaction, creates an encrypted message to Receiver's public key and broadcasts it to the Bitcoin P2P network.
The message contains an endpoint, which can be can be anything that both the S and the R are compatible with, IP address, onion address, domain, etc...
If the receiver isn't compatible with L1/2 or isn't online when the message was broadcasted to him, after some reasonable timeout the sender falls back to normal send.
If a P2P connection is established, the parties can negotiate the transaction.
Issues.
This system does not deal with spam.
The SNICKER proposal has the same kind of spam issue and suggested 4 possible solutions for it.
P2P network is not necessary, but it is desirable to avoid a central point of failure.
Usage of Bitcoin URLs and QR codes are well adopted, but building on those user workflows only covers a subset of Bitcoin users.
You may notice that this argument applies to adoption of scripts those expose public keys, but with Taproot coming along it is not inconceivable that such scripts will replace other scripts eventually.