-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding NDEF capability #239
Conversation
Amazing! Love it. I saw the demo in Berlin. |
Were you there? I haven't seen you around! Wish I met you! |
Might it be worth considering adding an option which writes URL This would be perfect onboarding experience, because this works even if a user has no idea what a cashu token is and how to redeem it. |
@prusnak |
src/components/SendTokenDialog.vue
Outdated
this.scanningCard = false; | ||
try { | ||
const tokenURL = | ||
window.location.toString() + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder whether we should use this or just hardcode wallet.cashu.me here
Both approaches have their advantages and disadvantages. What do you think @callebtc?
Since this got raised on Telegram. Maybe we can use this PR to also fix diff --git a/src-pwa/manifest.json b/src-pwa/manifest.json
index 7bca548..c5e6761 100644
--- a/src-pwa/manifest.json
+++ b/src-pwa/manifest.json
@@ -9,11 +9,11 @@
"protocol_handlers": [
{
"protocol": "web+cashu",
- "url": "/?token=%s"
+ "url": "/#token=%s"
},
{
"protocol": "web+lightning",
- "url": "/?lightning=%s"
+ "url": "/#lightning=%s"
}
],
"icons": [
diff --git a/src/components/SendTokenDialog.vue b/src/components/SendTokenDialog.vue
index 1983838..c3f375c 100644
--- a/src/components/SendTokenDialog.vue
+++ b/src/components/SendTokenDialog.vue
@@ -280,7 +280,7 @@
size="md"
icon="link"
flat
- @click="copyText(baseURL + '?token=' + sendData.tokensBase64)"
+ @click="copyText(baseURL + '#token=' + sendData.tokensBase64)"
><q-tooltip>Copy link</q-tooltip></q-btn
>
<q-btn
@@ -676,7 +676,7 @@ export default defineComponent({
try {
const tokenURL =
window.location.toString() +
- "?token=" +
+ "#token=" +
this.sendData.tokensBase64;
this.ndef
.write(
diff --git a/src/pages/WalletPage.vue b/src/pages/WalletPage.vue
index ea3eb8f..d57a0a0 100644
--- a/src/pages/WalletPage.vue
+++ b/src/pages/WalletPage.vue
@@ -410,7 +410,7 @@ export default {
const decodedTokenLink = new TextDecoder().decode(
message.records[0].data
);
- const cashuIndex = decodedTokenLink.indexOf("?token=cashu");
+ const cashuIndex = decodedTokenLink.indexOf("#token=cashu");
if (cashuIndex === -1) {
throw new Error("not a cashu token");
}
diff --git a/src/stores/wallet.ts b/src/stores/wallet.ts
index 2afd88a..dfca241 100644
--- a/src/stores/wallet.ts
+++ b/src/stores/wallet.ts
@@ -1104,7 +1104,7 @@ export const useWalletStore = defineStore("wallet", {
this.payInvoiceData.input.request = req
await this.lnurlPayFirst(this.payInvoiceData.input.request);
} else if (req.indexOf("cashuA") !== -1) {
- // very dirty way of parsing cashu tokens from either a pasted token or a URL like https://host.com?token=eyJwcm
+ // very dirty way of parsing cashu tokens from either a pasted token or a URL like https://host.com#token=eyJwcm
receiveStore.receiveData.tokensBase64 = req.slice(req.indexOf("cashuA"));
this.handleCashuToken()
} else if (req.indexOf("cashuB") !== -1) { |
Unfortunately doesn't seem to be enough. Tested it right now and when opening the link Chrome inserts a "/" between the "#" and the token.
|
It seems this is some Vue magic. Not Chrome specific. |
This could bring extra limitations on the UX. AFAIK URLs have max ~2000 chars, so a token has to fit in that. A V4 token can be, depending on the proofs (inputs) :
Maybe this can be validated in the "write NFC" phase? |
Not really. Since only Chrome on Android can read NFC via WebNFC and this browser supports 2MB payload in GET, I don't see how an UX can be limited when compared to the original proposal. |
Do we want to merge this? |
I am in favor, but cannot do that :) |
The functionality is very cool, I would love to merge it but the UI needs work. |
Do you have anything particular in mind? |
@lollerfirst I think we should add a switch which allows you to choose between the text/URL/binary representation of the token. It does not have to be a part of this PR, but we should think about the ideal UX for this option chooser. Options:
|
This can be part of some "NFC settings" in the settings I suppose. |
Also @prusnak don't know if it interests you but lately I've been focusing on cashu-kvac (the Signal anonymous credentials scheme, but for cashu) which would give the option for making tokens of constant size (~100-200 bytes) |
Co-authored-by: Pavol Rusnak <[email protected]>
Finally managed to fix the "toggle" behaviour for the scanner. |
I will be using the encoding choice in the scanner once cashu-ts supports binary tokens |
better UI for NFC errors
everything is also prepared for reading/writing binary tokens and we will enable the functionality once it arrives to cashu-ts
nfc: implement reading/writing of text/weburl tokens
This works really nice. Although when receiving with NFC it automatically redeems, whereas the other methods only fill the Should we conform to that? @prusnak |
Yeah, maybe we should not automatically redeem and just prefill the receive form like other methods do. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tested ACK
I think we should merge this one now @callebtc
We will follow up with another PR which adds binary encoding of tokens once the encoding/decoding is supported in cashu-ts
the When NFC is enabled and Payment Requests are disabled:
When NFC is disabled or Payment Requests are enabled, everything is shown like it should. |
Read and write cashu tokens to a NFC card through WebNFC amazing NDEFReader.
Lmk if you want to move the relevant code to a store to make it a bit tidier.