From: slush <slush@centrum•cz>
To: Andy Parkins <andyparkins@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Date: Fri, 16 Dec 2011 01:07:58 +0100 [thread overview]
Message-ID: <CAJna-HiR0qrOp2sG0hb=5bJ2H60y7QwC8BiHDVR9=kiV20W0vA@mail.gmail.com> (raw)
In-Reply-To: <201112131622.08158.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4219 bytes --]
I really like this proposal with standard URLs. All other proposals like
DNS mapping or email aliases converted to URLs with some weird logic looks
strange to me.
Plain URLs (returning address in response body, redirecting to URI
"bitcoin:<address>" or anything else) are very clear solution, easy to
implement in clients and very easy to understand by people. It's also
extremely flexible - almost everybody can somewhere setup static file
containing his "personal" addresses or it's very easy to integrate such
solution with eshops (providing custom address for given order) etc. I'm
definitely for this solution.
Best,
slush
On Tue, Dec 13, 2011 at 5:22 PM, Andy Parkins <andyparkins@gmail•com> wrote:
> On 2011 December 13 Tuesday, Amir Taaki wrote:
>
> > Maybe I wasn't clear enough in the document, but this is the intent with
> > the HTTPS proposal.
>
> I don't like the idea of a hard-coded mapping at all. We shouldn't be
> making
> choices on behalf of server operators. It's up to them how they arrange
> their
> domain names and paths.
>
> I also agree that DNS is not the technology to use. DNS is a nightmare.
>
> > genjix@foo•org
> >
> > Contacts https://foo.org/bitcoin-alias/?handle=genjix and the system
> > responds with a bitcoin address. Whether the system gives you a new
> > address from a pool of addresses, or contacts the merchant behind the
> > scenes is implementation defined.
> >
> > I'll clarify it later. This is the relevant line:
> >
> > string strRequestUrl = strDomain + "/bitcoin-alias/?handle=" +
> > pszEncodedNick;
> >
> > Between HTTPS service and server service, I lean slightly towards HTTPS
> > (automatic encrypted connection, CAs + all benefits of DNS). But still
> > interested in arguments in favour of a server service (daemon answering
> > queries).
>
> Why bother with an encoding scheme at all? If the address
>
> genjix@foo•org
>
> always maps to
>
> https://foo.org/bitcoin-alias/?handle=genjix
>
> Then forget the hardcoding of "https" the hardcoding of "bitcoin-alias" and
> "?handle=" and the original email-looking "genjix@foo•org". Just use the
> URL.
> Then the author of the service can use whatever they want.
>
> "Can I pay you 10 BTC?"
> "Sure, send it to 'https://bitcoinalias.foo.org/genjix/'"
>
> While I might implement my alias server like this:
>
> "Sure, send it to 'https://google.com/bitcoin/?andyparkins'"
> "Sure, send it to 'https://parkins.co.uk/"
>
> ... or any other URL they want -- any of which suit might suit me and my
> webserver better than whatever mapping would otherwise be hard-coded. The
> world is already very familiar with URLs so this is no more scary than the
> email address. What's more, the email address form looks _too much_ like
> an
> email address, and will only lead to confusion ... "send it to
> genjix@foo•org"
> "so I use outlook express for that, right?" "erm, no, you put it in your
> bitcoin client".
>
> The URL form could easily be made to detect a browser connecting rather
> than a
> bitcoin client (and this is an area that would benefit from a standards
> document -- define the headers and user agent triggers that an alias server
> expects) and give them better instructions.
>
> https can be specified as the default, so "https://" can be optional when
> they're typing. If, in the future, bitcoin gets a distributed peer-to-peer
> alias system, then a new URL type can be added easily
> "bcalias://andyparkins"
> might automatically find my node in the network and query it for an address
> (or whatever).
>
> All of the above is exactly why OpenID chose to use URLs for ID.
>
>
>
> Andy
>
> --
> Dr Andy Parkins
> andyparkins@gmail•com
>
>
> ------------------------------------------------------------------------------
> Systems Optimization Self Assessment
> Improve efficiency and utilization of IT resources. Drive out cost and
> improve service delivery. Take 5 minutes to use this Systems Optimization
> Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 5930 bytes --]
next prev parent reply other threads:[~2011-12-16 0:31 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-12 23:16 [Bitcoin-development] " Zell Faze
2011-12-12 23:37 ` Jorge Timón
2011-12-12 23:41 ` Luke-Jr
[not found] ` <CAGQP0AGBKKEqhaJZj-Rw400AjrVHE9_EMve=RWdqoaOaDsTgtw@mail.gmail.com>
2011-12-13 0:00 ` [Bitcoin-development] Fwd: " Jorge Timón
2011-12-13 0:42 ` Amir Taaki
2011-12-13 2:32 ` Daniel F
2011-12-13 2:37 ` Amir Taaki
2011-12-13 2:43 ` Luke-Jr
2011-12-13 2:52 ` Daniel F
2011-12-13 10:55 ` Mike Hearn
2011-12-13 11:42 ` Christian Decker
2011-12-13 12:32 ` Jorge Timón
2011-12-13 13:06 ` Gavin Andresen
2011-12-13 15:46 ` Amir Taaki
2011-12-13 16:22 ` Andy Parkins
2011-12-14 19:22 ` D.H.
2011-12-14 20:07 ` Luke-Jr
2011-12-14 20:17 ` D.H.
2011-12-14 20:21 ` Joel Joonatan Kaartinen
2011-12-14 22:51 ` Jorge Timón
2011-12-14 23:02 ` Rick Wesson
2011-12-14 23:27 ` Luke-Jr
2011-12-15 1:22 ` Rick Wesson
2011-12-15 3:57 ` Zell Faze
2011-12-15 4:56 ` Kyle Henderson
2011-12-15 6:04 ` Zell Faze
2011-12-15 6:41 ` Walter Stanish
2011-12-15 7:45 ` Jordan Mack
2011-12-15 7:52 ` Jorge Timón
2011-12-15 7:48 ` Jorge Timón
2011-12-15 8:26 ` Walter Stanish
2011-12-15 10:01 ` Andy Parkins
2011-12-15 11:08 ` Jorge Timón
2011-12-15 11:22 ` Christian Decker
2011-12-16 5:42 ` Walter Stanish
2011-12-16 8:46 ` Pieter Wuille
2011-12-15 15:44 ` Rick Wesson
2011-12-15 15:42 ` Rick Wesson
2011-12-16 0:07 ` slush [this message]
2011-12-16 15:52 ` Rick Wesson
2011-12-16 16:36 ` slush
2011-12-16 17:10 ` Andy Parkins
2011-12-16 17:41 ` Rick Wesson
2011-12-16 18:29 ` Amir Taaki
2011-12-16 19:06 ` Gavin Andresen
2011-12-16 19:22 ` Rick Wesson
2011-12-16 20:58 ` Andy Parkins
2011-12-16 20:54 ` Andy Parkins
2011-12-16 21:50 ` Rick Wesson
2011-12-13 15:47 ` Luke-Jr
2011-12-16 17:36 ` Khalahan
2011-12-16 17:48 ` Gregory Maxwell
2011-12-13 15:55 ` Walter Stanish
2011-12-13 16:15 ` Jorge Timón
2011-12-13 16:48 ` Gavin Andresen
2011-12-14 2:30 ` Walter Stanish
2011-12-13 2:39 ` [Bitcoin-development] " Stefan Thomas
2011-12-12 23:52 ` Matt Corallo
2011-12-12 23:37 ` Will
[not found] <9109000381434268897@unknownmsgid>
2011-12-13 8:55 ` [Bitcoin-development] Fwd: " Cameron Garnham
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='CAJna-HiR0qrOp2sG0hb=5bJ2H60y7QwC8BiHDVR9=kiV20W0vA@mail.gmail.com' \
--to=slush@centrum$(echo .)cz \
--cc=andyparkins@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