📅 Original date posted:2014-07-01
📝 Original message:Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd
advocate for a simple array parameter name, like rs= ("plural" of r).
Length really does matter for QR codes.
I'm fine with either multiple r= params or exactly one r= plus zero to
many r[]= params. Although I think it is a violation of the (current)
spec to choke on more than one r= parameters, I admit that bitcoinj is
currently implemented that way. (We could however fix this in a
maintenance release.)
However, r= should also allow all other protocols, exactly like any of
the r[]= params. I don't think we should do a distinction here. Also
because of backwards compatibility to the status quo.
On 07/01/2014 03:03 PM, Alex Kotenko wrote:
> In my mind it's not like the client's phone is going all directions at
> the same time. There should be a priority method and fallback method(s).
> And I see p2p radio as priority, and web as fallback, and BIP21 in the
> end as always-working-default.
>
> So I'm keeping support for it all while want to be able to provide best
> user experience.
> Mike, a while ago in this thread you've described contactless cards
> user experience. I'm also using contactless cards often, and what I'm
> aiming at is creating same level of user experience for Bitcoin users.
>
> Encryption over bluetooth is a matter to worry about, and we will
> introduce that, but we need to sort out more low level problems first
> before coming into that stage.
>
>
> So, the backwards compatibility is a good issue Michael pointed out.
> While processing of multiple "r" parameters is indeed uncertain (since
> there is no RFC for that various implementations may behave
> differently), the array solution is somewhat better. The array parameter
> name is "r%5B1%5D=", i.e. it's not "r=", and we can add plain "r="
> alongside. And if particular implementation understands the array
> construct - it will use it, otherwise it will ignore the "r%5B1%5D=" and
> use only usual "r=".
>
> This doens't work though for cases where particular implementation
> understands array construct but doesn't work well with repeating
> parameters, since it will see two repeating "r" - an array and a string.
> I don't have a solution for that atm.
>
>
> If add completely new parameter to solve this we will need to make it an
> array straight away to address upcoming issues with accommodating other
> protocols.
> And then I would also modify existing BIP72 to strictly define "r=" as
> "http(s)" only parameter, while all other protocols (bluetooth, WiFi
> Direct, ultrasound, chirp etc) should go to the new array parameter.
>
>
>
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
Andreas Schildbach [ARCHIVE] /
npub1xg…adsv7
2023-06-07 15:23:24
in reply to nevent1q…pelk
Author Public Key
npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7Published at
2023-06-07 15:23:24Event JSON
{
"id": "5b7830c3de3d756212c0d302a7b89ce48d93c1f061daba407d2cf919585feba1",
"pubkey": "3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc",
"created_at": 1686151404,
"kind": 1,
"tags": [
[
"e",
"ee6bc64c1976b2dbf1e8fad28498a66081191f29656dae347bd7d9144f6faaad",
"",
"root"
],
[
"e",
"0094455cc26b84431362858adb84bb58be452749935b716a1931b3c34a6cd656",
"",
"reply"
],
[
"p",
"ac99e5ca3122fca258fbfcb6cb62d10d4dba423b3243251cbc0c4e0042656dec"
]
],
"content": "📅 Original date posted:2014-07-01\n📝 Original message:Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd\nadvocate for a simple array parameter name, like rs= (\"plural\" of r).\nLength really does matter for QR codes.\n\nI'm fine with either multiple r= params or exactly one r= plus zero to\nmany r[]= params. Although I think it is a violation of the (current)\nspec to choke on more than one r= parameters, I admit that bitcoinj is\ncurrently implemented that way. (We could however fix this in a\nmaintenance release.)\n\nHowever, r= should also allow all other protocols, exactly like any of\nthe r[]= params. I don't think we should do a distinction here. Also\nbecause of backwards compatibility to the status quo.\n\n\nOn 07/01/2014 03:03 PM, Alex Kotenko wrote:\n\u003e In my mind it's not like the client's phone is going all directions at\n\u003e the same time. There should be a priority method and fallback method(s).\n\u003e And I see p2p radio as priority, and web as fallback, and BIP21 in the\n\u003e end as always-working-default.\n\u003e \n\u003e So I'm keeping support for it all while want to be able to provide best\n\u003e user experience. \n\u003e Mike, a while ago in this thread you've described contactless cards\n\u003e user experience. I'm also using contactless cards often, and what I'm\n\u003e aiming at is creating same level of user experience for Bitcoin users. \n\u003e \n\u003e Encryption over bluetooth is a matter to worry about, and we will\n\u003e introduce that, but we need to sort out more low level problems first\n\u003e before coming into that stage. \n\u003e \n\u003e \n\u003e So, the backwards compatibility is a good issue Michael pointed out. \n\u003e While processing of multiple \"r\" parameters is indeed uncertain (since\n\u003e there is no RFC for that various implementations may behave\n\u003e differently), the array solution is somewhat better. The array parameter\n\u003e name is \"r%5B1%5D=\", i.e. it's not \"r=\", and we can add plain \"r=\"\n\u003e alongside. And if particular implementation understands the array\n\u003e construct - it will use it, otherwise it will ignore the \"r%5B1%5D=\" and\n\u003e use only usual \"r=\". \n\u003e \n\u003e This doens't work though for cases where particular implementation\n\u003e understands array construct but doesn't work well with repeating\n\u003e parameters, since it will see two repeating \"r\" - an array and a string.\n\u003e I don't have a solution for that atm. \n\u003e \n\u003e \n\u003e If add completely new parameter to solve this we will need to make it an\n\u003e array straight away to address upcoming issues with accommodating other\n\u003e protocols. \n\u003e And then I would also modify existing BIP72 to strictly define \"r=\" as\n\u003e \"http(s)\" only parameter, while all other protocols (bluetooth, WiFi\n\u003e Direct, ultrasound, chirp etc) should go to the new array parameter.\n\u003e \n\u003e \n\u003e \n\u003e \n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e Open source business process management suite built on Java and Eclipse\n\u003e Turn processes into business applications with Bonita BPM Community Edition\n\u003e Quickly connect people, data, and systems into organized workflows\n\u003e Winner of BOSSIE, CODIE, OW2 and Gartner awards\n\u003e http://p.sf.net/sfu/Bonitasoft\n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e",
"sig": "763eac6148da285f7ba3964177b76ca559809c280cd4eda110d9dc36006f64c0455d3c6f858f5b4847e8f1054d918626ff7f18cf17aa220387888acd4e7b0840"
}