The trick is that in the coinjoin there are input owners who are neither the sender nor receiver of that payment, but these unrelated parties must perform some actions in order for the silent payment protocol to work. (some crypto magic, blind diffie helman or something like that, I forgot the details)
Discussion
Oh ya, I get that. But the goal is to avoid reusing an address that's used in a different tx, on the output side of the coinjoin. If you can guarantee that never happens, even if the recipient of some UTXO's in the coinjoin is distinct from the sender who owns some inputs in the coinjoin (for example I'm making a donation to some org via a coinjoin), without requiring interaction from the recipient, that would be good and worth added complexity to do the silent protocol within the coinjoin.
That's a good point actually.
However the receiver ultimately has to run a custom synchronization to find his coins, so legacy wallets won't work.
Ya this is a significant downside of silent payments. I think the custom sync is worth the downside. Could implement both legacy sync and silent payment sync for users of the feature
Why no lightning address, sir?
Where am I supposed to toss them sats... You can't just rob me of the joy of zapping great content!
I'll get my non custodial LN address set up one of these days
Adding to this: you could flag all "silent" coinjoin txs via an OP RETURN field and implement an RPC that returns those txs for the silent sync. A wallet need only sync new txs since it last loaded. Should keep sync overhead low.