Andy Parkins [ARCHIVE] on Nostr: 📅 Original date posted:2011-12-13 🗒️ Summary of this message: Amir Taaki ...
📅 Original date posted:2011-12-13
🗒️ Summary of this message: Amir Taaki proposes a HTTPS service for Bitcoin aliases, but Dr. Andy Parkins suggests using URLs instead of hard-coded mappings.
📝 Original message: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 at 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 at 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 at 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 at 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 at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111213/bac47699/attachment.sig>;
🗒️ Summary of this message: Amir Taaki proposes a HTTPS service for Bitcoin aliases, but Dr. Andy Parkins suggests using URLs instead of hard-coded mappings.
📝 Original message: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 at 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 at 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 at 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 at 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 at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111213/bac47699/attachment.sig>;