DIP-4 requires unclear out of band communication

[davidiw]

DIP-4 indicates that the parties explicitly define a to and a from subaddress in the metadata. In order for this to be useful the parties would need to assign pseudonyms internally and exchange those externally. This requires an unmentioned protocol. I would propose that instead the recipient simply indicate unique subaddress for each "from". Using the flows in the doc:

NC => NC
No need

C => NC
Recipient NC would share a distinct subaddress so that it can track the submitter

NC => C
No need

C => C
Recipient VASP would share a distinct subaddress so that it can track the submitter

This information can then be stored easily within a one-time use QR code, bech32 encoded identifier requiring minimal interaction to generate verifiable payment for both payer and payee.

In any case (as proposed in LIP-4 or mentioned here), there is no way to prevent either party from leaky information or ensuring that they choose an identifier dynamically.

[davidiw]

After briefly chatting with @sunmilee , let me rephrase...

I propose we completely eliminate from and to and just use a recipient assigned reference id. The problem with notions of from and to or pseudonymity get us into the murky space of linkability. This entire proposal is supposed to be about tracking unlinkable payments. I think it makes much more sense to suggest that the recipient will always give out distinct Diem payment URLs for each payment and be responsible for tracking them for distinctness and remember who the sender was. The sender, likewise, can at least track those payments that they have been party to.