rich1.0npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7https://nostr.ae/npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7njumphttps://nostr.ae📅 Original date posted:2015-02-22 📝 Original message:On 02/22/2015 11:37 PM, Andy Schroder wrote: > Andreas and I had a number of private discussions regarding the > payment_url parameter. I had suggested a "additional_payment_urls" > repeated parameter, but he didn't seem to like that idea and I > personally am indifferent, so that is why we decided to just change > payment_url to a repeated field. The spec is simpler without the > "additional_payment_urls", but the wallets have to be a little bit > smarter finding the right url they want to use in the list. It's maybe > not a bad idea for the wallet to try all payment_url mechanisms in > parallel. Should we add this as a recommendation to wallets in TBIP75? I think it will cause too much chaos. My recommendation for the payment_url field is prefer the same mechanism that was used for fetching the payment request. Only if the recommendation fails use the alternatives in order (or in reverse order, I'm not sure at the moment). > Regarding the NFC data formats. I would like to clarify that the wallets > are having those events dispatched by the android OS. The "URI" and > "mime type" events are sent to the application in the same way as from > other sources such as a web browser, e-mail, stand alone QR code scanner > app, etc.. So, I don't think the wallet actually knows it is receiving > the event from NFC. I think it can know. The method for catching these intents is very similar and you can reuse almost all code, but in fact you need to add an additional line to your AndroidManifest.xml. > That is one reason why so many existing wallets > happen to support BIP21 payment request via NFC. Many? Bitcoin Wallet and its forks were the only ones for about a year. Only recently Mycelium caught up and the others still do not care I guess. > I'm a little weary sending the "mime > type" based format over NFC because of backwards compatibility and > because of the long certificate chain that needs to be transferred. You > want that tap to be as robust and fast as possible. A bluetooth > connection can have a retry without any user interaction. I agree whatever we do must be robust. However I see no reason why NFC can't be robust, see my previous post. > I don't really like the Airbitz proposal. Figuring out if your selecting > is the right one is a real nuisance. The idea is neat in a few > applications, but I just don't think it is going to work for people as > the most efficient and trouble free option day to day. I realize they > are probably doing it to work with Apple's limited functionality phones > (and BLE is a new buzz word). However, I don't think we should base > bitcoin around what Apple wants us to do. They've already had their war > on bitcoin. They are going to do whatever they can to protect their NFC > based payment system. We need to make their platform the the less > desirable one if they are going to play the game that way. If that means > an Airbitz like proposal is implemented as a fallback, maybe that is > fine and POS systems need to support both, but I just don't think we > should limit what we can do because of Apple's products capabilities. Ack on Airbitz, and ack on our relationship to Apple (-: > There is also the "ack" memo that I mentioned in reference [2]. I think > we can improve upon this really. Can we make a new status field or > different bluetooth message header? I know Andreas didn't want to change > it because that is how his app already works, but I don't think the way > it is is ideal. I'm not against improving this point, but I felt the BT enhancements and the r,r1,r2 proposals are already getting complex enough. I would like to simplify the proposal by moving unrelated things to somewhere else.