📅 Original date posted:2014-03-21
📝 Original message:On 03/20/2014 05:14 PM, Alex Kotenko wrote:
> 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.
> I wonder how complex it would be to implement HTTP-over-Bluetooth. Not
> like I'm willing to do that now, but HTTP is well known and proven to be
> quite good for tasks like this, so in theory it would be handy to have
> such capacities in here.
Thought of that as well. On the other hand, HTTP might be overkill and
we inherit its potential downsides as well.
> Well, do we need to be compatible? If the dev community decides Base43
> PR QR's (or whatever other self-contained format) is the way to go, we
> just implement, roll it out and use it.
>
> My PoS needs to be compatible with BIP21, as when I'm presenting QR code
> or sending NFC message - I have no way to tell what wallet/phone is on
> the accepting side, so I have to be compatible to existing widely
> supported technologies.
Agreed. All I wanted to say support for QR is still small enough that we
might be able to switch to an incompatible standard. If we're determined
that is.
> Well, yes, it would be less efficient than base43. But did you
> calculate how much less? It's a compatible and already widely used way
> and loosing compatibility needs to have serious reasons, so would be
> great to know exact figures here.
Base 64 via binary QR: 64 chars / 256 chars
==> 6 bit / 8 bit = 0.75
Base 43 via alphanum QR: 43 chars / 45 chars
==> 5.43 bit / 5.49 bit = 0.99
That would be efficiency in terms of PR data size vs. amount space used
in a QR code. Of course, the visual QR encoding also plays a role, for
example its size is increased in discrete steps.
Andreas Schildbach [ARCHIVE] /
npub1xg…adsv7
2023-06-07 15:14:27
in reply to nevent1q…udfd
Author Public Key
npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7Seen on
wss://relay.noswhere.comPublished at
2023-06-07 15:14:27Event JSON
{
"id": "1ac800d3aefbc19b81571734dce2079f365a16ef78141b52772664c3cfd420e3",
"pubkey": "3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc",
"created_at": 1686150867,
"kind": 1,
"tags": [
[
"e",
"d70d8d12a406cb1c9a067111bb9c717b35fd85b951e12f89e562fccc2fad4277",
"",
"root"
],
[
"e",
"1d4ba5f42240d41153fdcb1dbf3c2fa9cdb685310ece278d908b65f949a7ffe8",
"",
"reply"
],
[
"p",
"ac99e5ca3122fca258fbfcb6cb62d10d4dba423b3243251cbc0c4e0042656dec"
]
],
"content": "📅 Original date posted:2014-03-21\n📝 Original message:On 03/20/2014 05:14 PM, Alex Kotenko wrote:\n\n\u003e Hmm, if we're inventing an URI for bluetooth, I'd rather follow existing\n\u003e URI's patterns. BT is strictly point-to-point connection, so BT MAC\n\u003e should be considered as server address, and payment request ID can be\n\u003e considered as request path. Probably \"bt:\u003cbt-mac\u003e/\n\u003e \u003crandom_id_of_payment_request\u003e\" would be more usual and easily\n\u003e understandable.\n\nAgreed. I used the dash because I feared a slash would need to be\nescaped if used in an URL parameter.\n\n\u003e I wonder how complex it would be to implement HTTP-over-Bluetooth. Not\n\u003e like I'm willing to do that now, but HTTP is well known and proven to be\n\u003e quite good for tasks like this, so in theory it would be handy to have\n\u003e such capacities in here.\n\nThought of that as well. On the other hand, HTTP might be overkill and\nwe inherit its potential downsides as well.\n\n\u003e Well, do we need to be compatible? If the dev community decides Base43\n\u003e PR QR's (or whatever other self-contained format) is the way to go, we\n\u003e just implement, roll it out and use it.\n\u003e \n\u003e My PoS needs to be compatible with BIP21, as when I'm presenting QR code\n\u003e or sending NFC message - I have no way to tell what wallet/phone is on\n\u003e the accepting side, so I have to be compatible to existing widely\n\u003e supported technologies.\n\nAgreed. All I wanted to say support for QR is still small enough that we\nmight be able to switch to an incompatible standard. If we're determined\nthat is.\n\n\u003e Well, yes, it would be less efficient than base43. But did you\n\u003e calculate how much less? It's a compatible and already widely used way\n\u003e and loosing compatibility needs to have serious reasons, so would be\n\u003e great to know exact figures here.\n\nBase 64 via binary QR: 64 chars / 256 chars\n ==\u003e 6 bit / 8 bit = 0.75\n\nBase 43 via alphanum QR: 43 chars / 45 chars\n ==\u003e 5.43 bit / 5.49 bit = 0.99\n\nThat would be efficiency in terms of PR data size vs. amount space used\nin a QR code. Of course, the visual QR encoding also plays a role, for\nexample its size is increased in discrete steps.",
"sig": "bdd17dc24479c8a1f1d9c5f699604f29124a7bc8b3e544797e2bf1a3019eaf09b7d514395f687580d74395713a468e604212535ad076ee68c8fa1a42dbc2f5e4"
}