+1  ^{(populism != sanity)}

The bitcoin: URL scheme makes sense by analogy to mailto: but

• It leaves the transaction info visible.  Without a standard way to transport and encrypt it (re-invent https?!), you encourage data leaks which are likely to link people to transactions.
• Is >35 chr long.  bitcoin: (8 chr) + address (27 in base64, 35 in the standard form?) + amount etc.
• Compare something like ht tps://txn.bt/b64id which is 20 chr, of which some cavalier folk will omit 8.  Without a checksum, it's good for 1E9 transactions.
  "txn.bt has not been registered yet and so available. This domain could be purchased but with no guarantee. Availability of domain name doesn't necessarily mean this can be purchased." -- http://www.nic.bt/twhois/whoiss.php
  If it's available, that's a nice landgarb for some enterprising person to make another centralised service. 
• So you need a transport for the text containing/of the URL.  I think in HTML-over-HTTPS is intended, and could work fine.  Otherwise, you could offer a shortcut (.lnk) file for download but a) they are platform-dependent b) cautious people don't trust them c) do shortcut files have a mimetype? 

Quote

Cool!

I have cooked up an email version,

• One encrypted email from Bob to Alice requesting payment and attaching your file.
• Another mail containing a copy of Alice's GPG keys so you can read the first mail.
• Currently for the benefit of those happy to download and open an mbox file.
• I suggest moving your ~/.gnupg/ out of the way while trying it, to avoid accumulating the cruft key.

Also may I suggest from my armchair,

• The message file looks quite minimal.  Can you put up a bells'n'whistles example with more fields, such as
  
  • Suggested txn fee.  If it took the form of a range it would allow newbie customers to exercise discretion with an "express payment .. cheapskate" slider bar...  but still be only a request or recommendation.
  • a nonce or id, to be recorded in the wallet.  This allows prompting "You paid this request on yyyy-mm-dd and it was confirmed an hour later.  Do you want to pay it again?"
  • a suggested txn message (how big are these? just an id?)
  • a symmetric key (reuse the nonce? take 20 bits as the nonce and bin the rest after a week?) to encrypt the txn message, because it is public
  • state how many confirmation blocks the merchant will wait for.
  • Some X-Foo: headers to show extensions.  X-Face: raises the issue of phishing...
  • dates...  bill issue (now) date, due date, request expiry date?  But I guess we don't want to re-invent the B2B monstrosity.
• It might be good to include some characteristic magic string, so file(1) can guess the mimetype.  I don't know a good way to do this.
• How would the merchant sign the payment request in a way that makes it clear what is being bought? Should the request contain mime attachments or be included in a multipart/mixed ?
• How does the txn message make it irrevocably clear that the payment is in answer to this request?  Suppose it ends up in court after wrong goods are delivered - customer has the offer to treat in the form of (( self-contained inventory HTML+images of shopping cart contents; request for payment; merchant signature )) and there is a public payment in the blockchain with a message identifying that request.
• Can the request delivery to existing browsers be improved with mime Accepts headers?  (I haven't dabbled with this aspect of the HTTP spec.)  Is it good for browsers to advertise acceptance of the payment-request type?

HTH,