From: Alex Kotenko <alexykot@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Date: Tue, 1 Jul 2014 14:03:52 +0100 [thread overview]
Message-ID: <CALDj+BZ8_YB0DHiaGZPq4MB-dvkRqJhBFazcfnrrPX4EvRxbeQ@mail.gmail.com> (raw)
In-Reply-To: <D4B82FD9-8078-48B2-9F91-8A3AB23AEAA7@osfda.org>
[-- Attachment #1: Type: text/plain, Size: 1890 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 3708 bytes --]
next prev parent reply other threads:[~2014-07-01 13:04 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-27 11:59 Andreas Schildbach
2014-01-27 13:11 ` Mike Hearn
2014-01-27 18:18 ` Andreas Schildbach
2014-01-27 18:34 ` Mike Hearn
2014-01-27 20:53 ` [Bitcoin-development] Experiment with linking payment requests via href Andreas Schildbach
2014-01-27 21:47 ` Mike Hearn
2014-01-27 17:11 ` [Bitcoin-development] Payment Protocol for Face-to-face Payments Jeremy Spilman
2014-01-27 17:39 ` Andreas Schildbach
2014-01-27 18:18 ` Jeremy Spilman
2014-01-27 20:34 ` Roy Badami
2014-01-29 14:57 ` Christophe Biocca
2014-01-30 10:46 ` Andreas Schildbach
2014-01-30 10:50 ` Mike Hearn
2014-02-07 23:15 ` Andreas Schildbach
2014-03-02 9:47 ` Andreas Schildbach
2014-03-02 11:50 ` Mike Hearn
2014-03-20 2:22 ` Alex Kotenko
2014-03-20 3:31 ` Jeff Garzik
2014-03-20 8:09 ` Andreas Schildbach
2014-03-20 10:36 ` Mike Hearn
2014-03-20 12:12 ` Adam Back
2014-03-20 12:20 ` Mike Hearn
2014-03-20 17:31 ` Jeff Garzik
2014-03-20 17:42 ` Alex Kotenko
2014-03-20 18:01 ` Jeff Garzik
2014-03-21 10:28 ` Andreas Schildbach
2014-03-21 13:59 ` Alex Kotenko
2014-03-22 16:35 ` Jeff Garzik
2014-03-22 16:45 ` Mike Hearn
2014-03-22 16:55 ` Mark Friedenbach
2014-03-22 17:24 ` Jeff Garzik
2014-03-22 17:30 ` Mike Hearn
2014-03-23 3:47 ` Alex Kotenko
2014-03-21 10:25 ` Andreas Schildbach
2014-03-21 10:59 ` Adam Back
2014-03-21 11:08 ` Mike Hearn
2014-03-21 11:33 ` Mike Hearn
2014-03-21 12:25 ` Adam Back
2014-03-21 13:07 ` Mike Hearn
2014-03-20 18:20 ` Alex Kotenko
2014-03-20 18:31 ` Mike Hearn
2014-03-20 18:50 ` Alex Kotenko
2014-03-20 21:52 ` Roy Badami
2014-03-20 23:02 ` Mike Hearn
2014-03-26 22:48 ` Roy Badami
2014-03-26 22:56 ` Mike Hearn
2014-03-26 23:20 ` Andreas Schildbach
2014-03-27 10:08 ` Mike Hearn
2014-03-27 13:31 ` vv01f
2014-06-30 19:26 ` Alex Kotenko
2014-07-01 8:18 ` Mike Hearn
2014-07-01 9:48 ` Andreas Schildbach
2014-07-01 10:42 ` Michael Wozniak
2014-07-01 13:03 ` Alex Kotenko [this message]
2014-07-01 14:59 ` Andreas Schildbach
2014-07-01 15:07 ` Michael Wozniak
2014-07-01 15:39 ` Andreas Schildbach
2014-07-01 17:18 ` Alex Kotenko
2014-07-01 17:59 ` Mike Hearn
2014-07-02 8:49 ` Alex Kotenko
2014-03-21 10:43 ` Andreas Schildbach
2014-03-20 8:08 ` Andreas Schildbach
2014-03-20 16:14 ` Alex Kotenko
2014-03-21 9:47 ` Andreas Schildbach
2014-03-21 13:54 ` Alex Kotenko
2014-03-21 14:51 ` Andreas Schildbach
2014-03-21 15:38 ` Alex Kotenko
2014-03-21 15:20 ` Andreas Schildbach
2014-03-21 15:24 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALDj+BZ8_YB0DHiaGZPq4MB-dvkRqJhBFazcfnrrPX4EvRxbeQ@mail.gmail.com \
--to=alexykot@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox