<div dir="ltr"><div class="gmail_default" style="font-family:'courier new',monospace;color:rgb(0,51,0)">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.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:'courier new',monospace;color:rgb(0,51,0)">So I'm keeping support for it all while want to be able to provide best user experience. </div>
<div class="gmail_default" style="font-family:'courier new',monospace;color:rgb(0,51,0)">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. </div>
<div class="gmail_default" style="font-family:'courier new',monospace;color:rgb(0,51,0)"><br></div><div class="gmail_default" style="font-family:'courier new',monospace;color:rgb(0,51,0)">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. </div>
<div class="gmail_default" style="font-family:'courier new',monospace;color:rgb(0,51,0)"><br></div><div class="gmail_default" style="font-family:'courier new',monospace;color:rgb(0,51,0)"><br></div><div class="gmail_default" style="font-family:'courier new',monospace;color:rgb(0,51,0)">
So, the backwards compatibility is a good issue Michael pointed out. <br></div><div class="gmail_default" style="font-family:'courier new',monospace;color:rgb(0,51,0)">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 "<span style="font-size:13px">r%5B1%5D=</span>", 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 "<span style="font-size:13px">r%5B1%5D=</span>" and use only usual "r=". </div>
<br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:'courier new',monospace;color:rgb(0,51,0)">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. </div>
<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:'courier new',monospace;color:rgb(0,51,0)">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. </div>
<div class="gmail_default" style="font-family:'courier new',monospace;color:rgb(0,51,0)">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.</div>
<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><span style="color:rgb(0,51,0);font-family:'courier new',monospace"></span><br></div></div>