You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The BIP21 req- parameter prefix was rarely (if ever?) even implemented by wallets. I left it in the 0.1.0 draft because I'm not certain if I've thought through the issue enough, but I don't have a vision of any likely future uses for it. Most new use cases are going to either:
Want backwards compatibility, e.g. a p parameter than initiates a P2P connection of some sort, but the URI still has an r for older clients to fall back to, or
Be a completely new concept or protocol, where either a new protocol scheme (e.g. lightning:) or new CashAddress version(s) (e.g. CashTokens) are likely to be allocated.
In either case, prefixing a new parameter with req- will be seen as a waste – you either want a short/one-character parameter name, or you want to avoid a new parameter entirely (the address itself embeds the new information).
I'll probably send a PR to drop the idea completely unless someone can offer reasoning to keep it.
The text was updated successfully, but these errors were encountered:
The whole premise of the req- prefix was that every wallet implements it such that one can reliably use it and know that transactions do what you need them to do. I have high doubts it will be implemented with the release of this CHIP when it gained close to zero traction with BIP-21.
Thanks for the comment @jonas-lundqvist. I still haven't come up with a viable use case, and I think our reasoning against including it is quite solid. Dropped in cd4b6fb. 👍
The BIP21
req-
parameter prefix was rarely (if ever?) even implemented by wallets. I left it in the0.1.0
draft because I'm not certain if I've thought through the issue enough, but I don't have a vision of any likely future uses for it. Most new use cases are going to either:p
parameter than initiates a P2P connection of some sort, but the URI still has anr
for older clients to fall back to, orlightning:
) or new CashAddress version(s) (e.g. CashTokens) are likely to be allocated.In either case, prefixing a new parameter with
req-
will be seen as a waste – you either want a short/one-character parameter name, or you want to avoid a new parameter entirely (the address itself embeds the new information).I'll probably send a PR to drop the idea completely unless someone can offer reasoning to keep it.
The text was updated successfully, but these errors were encountered: