Open xdamman opened 1 week ago
To make it even more generic (and allow anyone to offer a QR code that links to the webpage of their choice, while at the same time being readable by the QR code scanner of the Citizen Wallet), what about adding the ability to parse any URL that would specify a citizen wallet community and address?
https://example.com/path?cwcommunity=wallet.pay.brussels&cwrecipient=[username|address]&cwamount=:amount&cwdescription=:description
Using the cw prefix to avoid collision, but not sure it's really required.
(only cwcommunity
and cwrecipient
would be required)
This way, I could create a QR code to link to the menu of my restaurant. When I open it with my camera, I go to the menu. But when I open it with the QR scanner of the Citizen Wallet, it automatically switch to the right community and prefills the recipient.
@kevtechi wdyt?
For a standard format for reading amounts, we already support this: https://eips.ethereum.org/EIPS/eip-681
So, might as well stick with standards. You can generate this from within another app like Metamask.
The only thing that you should also add is ?alias=wallet.pay.brussels
Not sure we are talking about the same thing here. This is not about EIP-681. This is about enabling anyone to create a QR code that opens a webpage by default but that can be understood by the scanner of the Citizen Wallet.
So we need to add parameters that won't conflict with any website and that are also quite self explanatory. ?alias=wallet.pay.brussels
is confusing (and might collide).
Hence the proposal above:
https://example.com/path?cwcommunity=wallet.pay.brussels&cwrecipient=[username|address]&cwamount=:amount&cwdescription=:description
Some examples:
The fridge at the Commons Hub: https://live.citizenwallet.xyz/wallet.pay.brussels/fridge/pay?cwcommunity=wallet.pay.brussels&cwrecipient=fridge
Alternatively, we could use the mailto: format:
e.g. for Brussels Pay https://pay.brussels/xavier/6/sandwich?sendto=xavier@wallet.pay.brussels?amount=6&description=sandwich
Open to other ideas (just please give examples of how it would look like for the end users and developers)
Maybe what I was saying is not clear, but there's already a format that is currently in use by every wallet out there for parsing a recipient + amount + token.
So, we might as well use that one since citizen wallet already understands it.
I haven't checked but there might already be npm packages that can construct it for you.
https://example.com/?<standard-eip-681-params>
More a suggestion for your use-case now rather than saying we shouldn't implement our own format.
What about we support both:
https://example.com/?eip681=<standard-eip-681-params>
(note the param name, to make sure it doesn't conflict with other possible params in the URL)
and
https://example.com/?sendto=:address(0x or username)@:communitySlug?amount=10.50&description=:customDescription
A simple change that will go a long way:
Can you add support for this URL scheme when scanning QR codes?
https://live.citizenwallet.xyz/:communitySlug/:username/[donate|pay] https://live.citizenwallet.xyz/:communitySlug/:address/[donate|pay]
E.g.: https://live.citizenwallet.xyz/wallet.pay.brussels/fridge/pay
Use case: We have this poster on the fridge of the Commons Hub with a QR code that anyone should be able to scan. That's why it cannot go directly to the Citizen Wallet (people have the option to donate via Stripe as well).
But what ends up happening, is that people download the Citizen Wallet, then use the scanner and try to scan the QR code again. But of course it doesn't work.
So adding support for those URLs would fix it and greatly improve the UX.