📅 Original date posted:2014-03-21
📝 Original message:> > Hmm, if we're inventing an URI for bluetooth, I'd rather follow
> existing
> > URI's patterns. BT is strictly point-to-point connection, so BT MAC
> > should be considered as server address, and payment request ID
can be
> > considered as request path. Probably "bt:<bt-mac>/
> > <random_id_of_payment_request>" would be more usual and easily
> > understandable.
>
> Agreed. I used the dash because I feared a slash would need to be
> escaped if used in an URL parameter.
>
> It will need to be escaped, but HTTP URLs used in BIP72 have it
> already, so don't see why we should bother.
Quoting from RFC 3986, Section 3.4. Query: "The characters slash ("/")
and question mark ("?") may represent data within the query component."
> Ok. Btw, I've tested QR possibilities on my PoS screen, in binary mode
> it's limited to about 600 chars, so really I can include only unsigned
> and rather short payment request. Signed requests longer than few
> hundred bytes will not work.
Thanks for testing this. It would be interesting to know what device and
software you used for scanning. But anyway, it falls into the same
ballpark as my tests.
> I probably will skip this anyway and go with bluetooth
> URI scheme we've just agreed + old style payments over p2p network as
> fallback. So no payment requests in QR codes at all from my side.
So BIP72 with a BT URI in the 'r' parameter?
Andreas Schildbach [ARCHIVE] /
npub1xg…adsv7
2023-06-07 17:14:28
in reply to nevent1q…pxmt
Author Public Key
npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7Published at
2023-06-07 17:14:28Event JSON
{
"id": "de49b3c65b19a7c437d1e164273a86749646cd4418824e70eb071247a13817b8",
"pubkey": "3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc",
"created_at": 1686150868,
"kind": 1,
"tags": [
[
"e",
"d70d8d12a406cb1c9a067111bb9c717b35fd85b951e12f89e562fccc2fad4277",
"",
"root"
],
[
"e",
"86690216557b6861c866f0ff17ffdd943b98fd18379f3d75e4dad5547edf3d0d",
"",
"reply"
],
[
"p",
"ac99e5ca3122fca258fbfcb6cb62d10d4dba423b3243251cbc0c4e0042656dec"
]
],
"content": "📅 Original date posted:2014-03-21\n📝 Original message:\u003e \u003e Hmm, if we're inventing an URI for bluetooth, I'd rather follow\n\u003e existing\n\u003e \u003e URI's patterns. BT is strictly point-to-point connection, so BT MAC\n\u003e \u003e should be considered as server address, and payment request ID\ncan be\n\u003e \u003e considered as request path. Probably \"bt:\u003cbt-mac\u003e/\n\u003e \u003e \u003crandom_id_of_payment_request\u003e\" would be more usual and easily\n\u003e \u003e understandable.\n\u003e\n\u003e Agreed. I used the dash because I feared a slash would need to be\n\u003e escaped if used in an URL parameter.\n\u003e\n\u003e It will need to be escaped, but HTTP URLs used in BIP72 have it\n\u003e already, so don't see why we should bother.\n\nQuoting from RFC 3986, Section 3.4. Query: \"The characters slash (\"/\")\nand question mark (\"?\") may represent data within the query component.\"\n\n\u003e Ok. Btw, I've tested QR possibilities on my PoS screen, in binary mode\n\u003e it's limited to about 600 chars, so really I can include only unsigned\n\u003e and rather short payment request. Signed requests longer than few\n\u003e hundred bytes will not work.\n\nThanks for testing this. It would be interesting to know what device and\nsoftware you used for scanning. But anyway, it falls into the same\nballpark as my tests.\n\n\u003e I probably will skip this anyway and go with bluetooth\n\u003e URI scheme we've just agreed + old style payments over p2p network as\n\u003e fallback. So no payment requests in QR codes at all from my side.\n\nSo BIP72 with a BT URI in the 'r' parameter?",
"sig": "ba4dd40748741f91b859fdc3993ceffa40e9ee220acfc7ddb5c0232ff6410863aee360af26482100cb7f66c2c62ad3d216dd5c56d617afbf7d1a5f40a2fef592"
}