đź“… Original date posted:2014-07-01
đź“ť Original message: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.
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140701/3d587442/attachment.html>;
Alex Kotenko [ARCHIVE] /
npub14j…h00t4
2023-06-07 15:23:24
in reply to nevent1q…mhj5
Author Public Key
npub14jv7tj33yt72yk8mljmvkck3p4xm5s3mxfpj289up38qqsn9dhkqeh00t4Published at
2023-06-07 15:23:24Event JSON
{
"id": "0094455cc26b84431362858adb84bb58be452749935b716a1931b3c34a6cd656",
"pubkey": "ac99e5ca3122fca258fbfcb6cb62d10d4dba423b3243251cbc0c4e0042656dec",
"created_at": 1686151404,
"kind": 1,
"tags": [
[
"e",
"ee6bc64c1976b2dbf1e8fad28498a66081191f29656dae347bd7d9144f6faaad",
"",
"root"
],
[
"e",
"a392f39fff85faa9251bdcd268d62d9b354fcd3a0ae4b147500ff4d7e377e5ea",
"",
"reply"
],
[
"p",
"5dfbe446644f4260520516c70aa838e0d4a0c8577a552092ac76ea0d71e4f5cb"
]
],
"content": "📅 Original date posted:2014-07-01\n📝 Original message:In my mind it's not like the client's phone is going all directions at the\nsame time. There should be a priority method and fallback method(s). ​And I\n​see p2p radio as priority, and web as fallback, and BIP21 in the end as\nalways-working-default.\n\n​So I'm keeping support for it all while want to be able to provide best\nuser experience.\nMike, a while ago in ​this thread you've described contactless cards user\nexperience. I'm also using contactless cards often, and what I'm aiming at\nis creating same level of user experience for Bitcoin users.\n\nEncryption over bluetooth is a matter to worry about, and we will introduce\nthat, but we need to sort out more low level problems first before coming\ninto that stage.\n\n\nSo, the backwards compatibility is a good issue Michael pointed out.\nWhile processing of multiple \"r\" parameters is indeed uncertain (since\nthere is no RFC for that various implementations may behave differently),\nthe array solution is somewhat better. The array parameter name is \"\nr%5B1%5D=\", i.e. it's not \"r=\", and we can add plain \"r=\" alongside. And if\nparticular implementation understands the array construct - it will use it,\notherwise it will ignore the \"r%5B1%5D=\" and use only usual \"r=\".\n\nThis doens't work though for cases where particular implementation\nunderstands array construct but doesn't work well with repeating\nparameters, since it will see two repeating \"r\" - an array and a string. I\ndon't have a solution for that atm.\n\n\nIf add completely new parameter to solve this we will need to make it an\narray straight away to address upcoming issues with accommodating other\nprotocols.\nAnd then I would also modify existing BIP72 to strictly define \"r=\" as\n\"http(s)\" ​only ​parameter, while all other protocols (bluetooth, WiFi\nDirect, ultrasound, chirp etc) should go to the new array parameter.\n\n\n​\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140701/3d587442/attachment.html\u003e",
"sig": "de20289d9e8e7a51c0ffe4a9f4748d076ff2b1c2d15c2e5cfff4dbb0d57ba10f44ededcb095b441fe07b810c2a0a91f3fe03edd2bb176193667ea1f8ec1a4669"
}