there is no off-the-shelf way to display historical activity for both senders receivers once a payjoin was initiated, updated, and completed. Basically we want to be able to add "payjoin happened" to a tx history screen (or cli output) in a consistent way. And we want to have documentation and an API around best practices wrt that

any particular protocol offers a number of user-facing APIs that are ~independent from the particular implementation. For Payjoin users, they need some thing that allows them to identify where their money went, and probably the'd expect this thing to be the same independently from which particular wallet they use. Similar probably could be said for some kind of identifier for the flow by which they can easily discern which payment is which if they, e.g., have multiple concurrent payments going on.
We probably can find some good contenders for both of these in the concrete LDK Node implementation, but it feels almost like a layer violation as it's essentially not up to us to make up typical APIs for the payjoin protocol. Hence my view that, as all implementors would have the same issue, it might be good to provide clear guidance in rust-payjoin itself.

@tnull

Fortunately there are multiple implementations (payjoin-cli, nolooking, LDK-Node, Mutiny) to reference and come up with a unified solution:

• payjoin-cli uses the public key of the session for receivers and the pj_url for senders
• nolooking uses the bip21's bitcoin address for receivers and does not persist sender sessions
• LDK-Node tried using the bip21's bitcoin address for sending
• Mutiny used the public key of the session for receivers and the txid of the original PSBT for senders
• BitMask seems to rely wholly on BDK's transaction list to persist this info

This seems more like a wallet issue than a rust-payjoin issue since the historical activity is related to a label of activity.

payjoin-cli details

payjoin-cli stores Sender and Receiver structs serialized as json and identified by Sender::pj_uri() and Receiver::id() respectively I think the first thing to figure out is whether or not this is sufficient. Historical data is maintained by the blockchain at bitcoin core without issue. Does this serialization make sense?