{"type":"rich","version":"1.0","author_name":"npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrv","author_url":"https://nostr.ae/npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrv","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2011-12-13\n🗒️ 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.\n📝 Original message:On 2011 December 13 Tuesday, Amir Taaki wrote:\n\n\u003e Maybe I wasn't clear enough in the document, but this is the intent with\n\u003e the HTTPS proposal.\n\nI don't like the idea of a hard-coded mapping at all.  We shouldn't be making \nchoices on behalf of server operators.  It's up to them how they arrange their \ndomain names and paths.\n\nI also agree that DNS is not the technology to use.  DNS is a nightmare.\n\n\u003e genjix at foo.org\n\u003e \n\u003e Contacts https://foo.org/bitcoin-alias/?handle=genjix and the system\n\u003e responds with a bitcoin address. Whether the system gives you a new\n\u003e address from a pool of addresses, or contacts the merchant behind the\n\u003e scenes is implementation defined.\n\u003e \n\u003e I'll clarify it later. This is the relevant line:\n\u003e \n\u003e string strRequestUrl = strDomain + \"/bitcoin-alias/?handle=\" +\n\u003e pszEncodedNick;\n\u003e \n\u003e Between HTTPS service and server service, I lean slightly towards HTTPS\n\u003e (automatic encrypted connection, CAs + all benefits of DNS). But still\n\u003e interested in arguments in favour of a server service (daemon answering\n\u003e queries).\n\nWhy bother with an encoding scheme at all?  If the address\n\n  genjix at foo.org\n\nalways maps to\n\n  https://foo.org/bitcoin-alias/?handle=genjix\n\nThen forget the hardcoding of \"https\" the hardcoding of \"bitcoin-alias\" and \n\"?handle=\" and the original email-looking \"genjix at foo.org\".  Just use the URL.  \nThen the author of the service can use whatever they want.\n\n \"Can I pay you 10 BTC?\"\n \"Sure, send it to 'https://bitcoinalias.foo.org/genjix/'\"\n\nWhile I might implement my alias server like this:\n\n \"Sure, send it to 'https://google.com/bitcoin/?andyparkins'\"\n \"Sure, send it to 'https://parkins.co.uk/\"\n\n... or any other URL they want -- any of which suit might suit me and my \nwebserver better than whatever mapping would otherwise be hard-coded.  The \nworld is already very familiar with URLs so this is no more scary than the \nemail address.  What's more, the email address form looks _too much_ like an \nemail address, and will only lead to confusion ... \"send it to genjix at foo.org\"  \n\"so I use outlook express for that, right?\"  \"erm, no, you put it in your \nbitcoin client\".\n\nThe URL form could easily be made to detect a browser connecting rather than a \nbitcoin client (and this is an area that would benefit from a standards \ndocument -- define the headers and user agent triggers that an alias server \nexpects) and give them better instructions.\n\nhttps can be specified as the default, so  \"https://\" can be optional when \nthey're typing.  If, in the future, bitcoin gets a distributed peer-to-peer \nalias system, then a new URL type can be added easily \"bcalias://andyparkins\" \nmight automatically find my node in the network and query it for an address \n(or whatever).\n\nAll of the above is exactly why OpenID chose to use URLs for ID.\n\n\n\nAndy\n\n-- \nDr Andy Parkins\nandyparkins at gmail.com\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 198 bytes\nDesc: This is a digitally signed message part.\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111213/bac47699/attachment.sig\u003e"}