Yes.  Absolutely.

By the way, to explain a little more about this system:  The Bitcoin AH (Account Hub) + Bitcoin POS (Point of Sale SDK) + The Bitcoin Mobile Apps = the complete system

The primary problem it solves is:   The need for instantaneous transfer

This way, there's no waiting for an hour for a transaction to clear (get verified by 7+ standard bitcoin nodes).  The transaction happens instantly.... so there's no waiting when you buy a large cafe latte...  and there's a line of people waiting behind you.

However, yes, the Mobile App will let you pay anyone who has an account on the Bitcoin Account Hub.  

I'm going to recommend that Andrew also include the capability to pay NON-Bitcoin AH members using the standard Bitcoin network... as long as the user is notified of, and approves of, the necessary delay in the transaction fully clearing.

The "Bitcoin Account Hub" acts very similarly to a MyBitcoin.com-type service.   Both parties must have an active account on a trusted "Bitcoin AH" in order for the transaction to clear instantly.

The main differences are:  

• All of the software is to be completely FOSS (Free Open Source Software)
• Anyone can set up a Bitcoin AH Account Hub (community groups, church groups, university IT labs, Linux user groups, merchants, anyone!)
• Multiple Account Hubs can establish "trust relationships" with each other (this extends the network to all account holders of all trusted networks)
• Transactions always happen instantly - no matter which Bitcoin AH the two parties have accounts on (unless the recipient doesn't have an AH account; in which case the normal Bitcoin network is used)
• The Mobile Apps will have the same abilities to easily make AND RECEIVE transactions, just like the POS system can, and works exactly the same way:  The recipient touches "RECEIVE" button on his phone app, then enters a NAME OF RECIPIENT, and a TEXT DESCRIPTION and an AMOUNT, in either US$ or Euro or Bitcoin, then touches OK.  He sees, "Code 953". The recipient then tells the payer verbally, "The code is 953."  Next, the payer touches "PAY" button on his phone app, then he see, "Enter Code", he enters 9-5-3, then he sees the NAME OF RECIPIENT, the TEXT DESCRIPTION, and the AMOUNT listed in US$ and Euros and BTC equivalents. He touches PAY again to confirm. The payment is instantly acknowledged on both devices.
• The Mobile App might also have extra features, like the ability to Display your Bitcoin Address as a QR Code ~and/or~ Scan someone else's Bitcoin Address as a QR Code (for non-Account Hub transactions; since the recipient's Bitcoin Address is not needed if both parties have an AH account -- the transaction is connected by time + 3-digit-confirmation-code + confirmation screen with transaction details for sender to acknowledge)
• Everything you can do with the Mobile App, can also be done with a web browser via the web interface to the Account Hub

Sound good?   Thoughts?    Ideas?

The more I think about it...

The more I think that we should develop this in three phases:


PHASE ONE

First, the Bitcoin AH which does everything MyBitcoin.com can do and more... but AH-style...  And, all transactions can be completed using any WEB BROWSER via the internet and the AH's Web Interface.

This way, anyone can use Bitcoin AH ~now~ immediately...  via any computer or phone with a web browser...  from ANYWHERE....  GLOBALLY....   (even if there's only one operational AH at the moment).

Also, designed from the ground up to inter-operate with other Bitcoin AH (account hubs) running this identical software, with it's own internal database of "trusted relationships" between other AH's.


PHASE TWO

Second, the Bitcoin Mobile App.....   which does everything the web interface does...  plus a few other additional mobile features, like QR Codes.   

This way, merchants could actually use the Mobile App ~or~ any Web Browser.....   as their POS solution.....   for now.    Instantly.    They could ring up the sale using some unused "Comp Sale" button or code...  which would indicate to their internal accounts that it's a Bitcoin transaction...   and then they'd just ring up the RECEIVE transaction using either:   The Mobil App on a phone, or the AH Web Interface on a computer or a phone.


PHASE THREE

Third, the Bitcoin POS SDK.     

The POS software would also contain built-in calls to API's to automatically upload Bitcoin to MtGox (and/or potentially any other exchange sites), and initiate the sale of those Bitcoins for USD or Euros, and initiate the request for a direct bank deposit of the USD or Euros into the merchant's bank account.

_____

Since merchants could begin transacting business after only Phase One (above) is complete....  That's gotta be first.    Of course, friends could also make instant transactions to each other at this point too.

Phase Two would add lots more convenience....  and mobility.

Phase Three would just be the slick professionalism for merchant processing on a large scale --- the icing on the cake.

Also, I think that it's important that the Payment Process ALWAYS be consistent.... and work the same way.... on all platforms....  for ease of use, and easy consumer adoption....

• Recipient/Merchant touches the RECEIVE button.
• Recipient/Merchant is asked to enter these text fields:  NAME, DESCRIPTION, AMOUNT, USD/EUR/BTC  (if on web or phone, cash register POS-SDK does not enter these automatically).
• Recipient/Merchant's display shows, "Confirm Code 745" (for example).
• Recipient/Merchant verbally tells the Payer/Customer the confirm code.
• Payer/Customer touches PAY button.
• Payer/Customer's display shows, "Enter the Confirm Code".
• Payer/Customer enters 745 (for example).
• Payer/Customer sees the correct information displayed for: NAME, DESCRIPTION, AMOUNT, USD/EUR/BTC and sees, "OK TO PAY"
• Payer/Customer touches "OK TO PAY".
• Both the Recipient/Merchant ~and~ the Payer/Customer see, "Payment Confirmed" on their respective displays.

..... no matter whether either party is using...

• The Web Interface for the AH,
• The Mobile App, or
• The POS SDK integration
• One "Receive" request, and one matching "Payment" request, makes one complete Transaction, once confirmed.  These requests are matched up by the system based on near enough:  CURRENT TIME + CONFIRM CODE + GEOLOCATION

If the CURRENT TIME + CONFIRM CODE agree.....   but the GEOLOCATION is more than 5 miles off, one additional confirmation dialog is displayed for the Payer/Customer.  For example, "You are near Cleveland Ohio USA and you are about to send a payment to Bangkok Thailand. Is this correct?"    The Payer/Customer must touch, "YES" to proceed with making the payment.

Whatta ya think?

Agree?

Maybe you would like to get the Ripple P2P implementation up and running instead of the Account Hub.
http://ripple-project.org/Protocol/Index

If you get it implemented I will send you 10 BTC.
(Will add more as I mine)

EDIT: BTW, feel free to improve the design.

I don't really understand what Ripple is....  but I will pass this suggestion on to Andrew.    Is Ripple something that would be used to replace the AH Protocol?

Now Ripple is a F2F network of IOUs which allows payment between unknow parties if a route can be build of trusted peers between them making payments safe and easy. Totally decentralized also!

EDIT: Here it is a PDF explaining it at a glance with a Technical FAQ. http://ripple-project.org/decentralizedcurrency.pdf
EDIT2:offtopic would you mind me translating BitcoinMe to spanish and making fliers/leaflets/etc?

Would LOVE it.   Email me at email@bitcoinme.com       Thanks!      Note:  Pardon problem with images displaying on the site.  I am fixing that asap.

bruce, I urge you to read the PDF, you will love it because it does what you want the AH to do + it is decentralized completely. This is being discussed and instead of starting from scratch you can help them implement it or improve the design at least. I think there is also a video in the main page of the project which pretty much sums it up in english in 5 minutes. So, good night!

A couple suggestions for the mobile app - cash register communication protocal:

1. Bluetooth support to eliminate entering of codes
2. If bluetooth is not available, then the customer's phone should generate a random number to give to the clerk instead of the other way around. The clerk is better prepared to enter codes (on an actual keyboard) than the customer on their phone's touch screen.
3. Account numbers. If the customer can remember a 10-digit account number they have on the Account Hub network, then they can recite it to the clerk at the POS. When they enter it into the cash register, the customer's android phone will wake up and ask for confirmation. This would eliminate the need for the customer to waste time getting in to the app. App would wake up instead.
4. For customers without android phones, solution #3 means that the AH network could make a regular call to the customer for confirmation.


Regarding Ripple Pay and the hub network, a couple quick ideas on how to implement the hub client:
1. Start with a standard Ripple Pay client
2. Modify it to be knowledgeable about incoming bitcoin transactions via the json api with bitcoin, and to be able to send bitcoin transactions.
3. When Hub A (customer's hub) needs to send money immediately to Hub C (store's hub), and there is a trust path through Hub B, then:
i. Hub A transmits the IOU through the normal ripple pay channels (not bitcoin)
ii. Hub C is now satisfied that it holds a RipplePay IOU against Hub B so Hub C can approve the transaction at the cash register.
iii. Each hub constantly checks and resolves all RipplePay obligations via bitcoin payments to its peers. Likewise, when a hub receives a bitcoin payment from a peer and it reaches the 6 confirmation level, it updates the obligation through RipplePay as being paid.
IMPORTANT: A hub's outgoing bitcoin payments must be re-sent if they used money from recent incoming payments that were reversed by the sender! Remember, the whole idea behind ripple pay is to push debt through a trust chain. If upstream does not send you the money, you still must send your payments downstream.

This is just a start Im sure theres a lot more improvements that can be made to get RipplePay working with bitcoin. For example leveraging the fact that all bitcoin transactions are publicly available so everyone will know if a particular hub on the ripplepay network cheats.

Why redevelop a bitcoin handling platform from scratch ?

Why not re-use the bitcoin-central source code and simply tweak a couple of things to suit the AH spec ?

If you want to do that you'll have a couple more skilled coding hands.

Just saying ...