-
Notifications
You must be signed in to change notification settings - Fork 2
PoP URI
In order to make PoP work smoothly, we need some way of transferring the PoP request to the client. This can be accomplished in a number of ways. Here I will list some options.
Like BIP72, we could extend BIP21 to support PoP requests. For example:
bitcoin:?p=https%3A%2F%2Fmerchant.com%2Fpop.php&nonce=972632163068&label=service1
The p parameter is the PoP destination, the nonce is, you guessed it, the nonce. The other parameters of BIP21 are also accepted are amount, label and message.
The problem with this is that this is not a payment and therefore we might confuse users and wallet developers. When implementing my proof of concept wallet, a fork of Mycelium, I created a mess trying to shoehorn PoP into the bitcoin: scheme.
We could make a BIP similar to BIP21 that introduces a new scheme, for
example btcpop:. That could look something like this:
btcpop:?p=https%3A%2F%2Fmerchant.com%2Fpop.php&nonce=972632163068&label=service1
This scheme should take all the standard parameters that the BIP21 accepts, i.e. amount, label and message. The p and nonce paramemters are mandatory and the rest are optional.
It is more clear to a user what is going on when this scheme is uses for PoP. Also wallets can easily have different handlers for different schemes. In android, it would be a PoPActivity for btcpop: and SendPaymentActivity for bitcoin:. It's harder to make that distinction if everything is encoded under the same scheme.
TBD