Contacts pairing for cover traffic & sender initiated payjoins

[nothingmuch]

As a relatively low complexity feature, Payjoin wallets should be encouraged implement a contacts feature to facilitate e2ee (ideally PQ safe) exchange Payjoin URIs.

Such introductions might take the form of a BIP 321 URI with no address? not sure about this.

A long lived communication channel between two Payjoin wallets is a sequence of mailboxes, where the payjoin session is a special case with just two messages.

Supporting wallets could exchange messages over the payjoin directory (ideally several directories in parallel) in the same format as the sender's message A, i.e. as an HPKE payload with a reply key as the first part of the input. This allows every message to have a reply, for simple turn based messaging protocol. The payload should start with a 0 byte, followed by random padding.

This random cover traffic should be exchanged at random times with any/all contacts, to better hide the traffic of actual payjoin transactions. Senders with can additionally randomly delay broadcast of transactions in order to unlink the real payjoin session from the broadcast of the resulting transaction. This assumes private broadcast as in bitcoin/bitcoin#29415.

By defining other values for the initial 0 byte (e.g. as TLV values), arbitrary payloads can be exchanged.

A first such use would be establishment of additional channels. These channels are reliable only if the directory is honest and does not lose data, additional parallel long lived communication channels on new directories should be negotiated as well. If any message is lost or any party loses their ephemeral keys before getting a reply then the channel will lose liveness permanently.

If #582 happens becomes a thing, reply blocks should be used to avoid the traffic patterns of of polling, improving the quality of the cover traffic. These reply blocks can be indicated in an extension message.

Another message type could allow the sender to initiate payjoins or otherwise send payment intents in a semi standard way. Need to examine this idea in the context of BIP 12 and 353: perhaps being async and web stack friendly makes it complementary for some use cases, and BOLT12 can serve as an introduction channel.

Finally, arbitrary user chat messages could also be supported, but I think this should actually be discouraged because:

1. no metadata privacy
2. rabbit hole of potentially unsafe extensions (formatting, emoji, ...)
3. scamming vector

It's better if users communicate using apps they already trust. In the case of wallets that already have such messaging built in, it seems better to use those channels to initiate sessions and use these payjoin channels mainly for generating cover traffic.