Tuesday, August 30, 2011

The Web Needs a Federated Payment Protocol

When it comes to paying for good and services on the Internet, the consumer has many
choices - Paypal, Amazon, Google Checkout, their respective Credit Card...

However, you
rarely see all of these accepted in a single place - and for very good reason: Its gorram difficult to
implement so many different APIs and systems, and have to deal with tracking each of them.

Clearly,
the Web needs a way to deal with this - and having a Federated Payment Protocol would solve it.

Think
about it: A vendor website would easily communicate with a payment processor through this protocol.  They
wouldn't have to know who the Payment Processor is, or even care for that matter.  The vendor would issue a
request to the payment processor.  The processor would be in charge of authenticating the user, and would
send back their "terms" (out of the requested amount, *this* much will be dispersed and *this* much will be
taken as a processing fee).  The vendor will agree, disagree, or change the payment amount based on what the
processor sent.  The processor would then submit this change to the user, if the user accepted the processor
would send the new details and the vendor would accept or deny.  The processor would send the money through
whatever system they need to, notifying the vendor how long it should take, and if its a short enough time
the vendor can hold the user until the payment has cleared (or if it is a trusted source not hold at all)
and provide the promised goods or services, after confirming the transaction with their receiving service.

This
solves a few key issues:

  • Vendors have to trust that they are
    receiving the money for their services.

  • Credit Card details would never have
    to be provided to the vendor, as the service would be directly through their credit company's payment
    service.

  • Vendors would not have to implement different APIs for different
    payment methods.

  • "Credit Card Fraud" liability would be the burden of the
    Credit Company, of whom authenticated the user.  A vendor would no longer be required to make sure a person
    is who they say they are.

  • Banks could offer their own payment services
    ("Debit."  Possibly with No Fee, resulting in a reduction of prices from vendors, hopefully).


Clearly
this is a good idea, and I wish I had the know-how to put it together myself.

Wednesday, August 24, 2011

Lack of "Security" May Hinder Future Google Adoption

I better make this clear: I am not talking about encryption, password, hashes, etc.
 Not that kind of security.

No, I'm talking about reliability.
 Something Google has had for a very long time, and one of the many reasons I'm such a Google fanatic.

Until
recently, at least as far as I can remember, Google products that existed did not see the end of the tunnel
very often.  (The question and answer service excluded).

Recently, however, Google has
been trying to expand into many markets.  From what I can take away, Google wants to be the hub of
information exchange on the Internet.  After all, knowing all of that powers their search - and their search
powers their ads.

Recently though, several Google services have announced that they
will be discontinued.  Among these: Wave, PowerMeter, and Health.

PowerMeter and Health
did not see large enough adoption for Google to continue putting forth the funds for them.  To me, this is
disappointing.  Being able to get this information so easily and readily through Google was really exciting.
 After all: Google has the technological know-how to keep my data secure and provide at least decent user
interfaces to said data.  In fact, I used Google Health - although since I don't have many issues it was
currently just to store my insurance information.

Now though, these services will be
disappearing.  Who is to say that other less-mainstream services won't disappear in the future?  Buzz?
Voice?  Google+?  Well, there's no way that last one could disappear... right?

If I'm
going to rely on Google to provide a service, I'm going to need the security of knowing that the service is
going to continue to exist.  I might be asking a bit much as a free user, but its still a very important
consideration.

If Google loses this trust; this security; this reliability - won't it
hinder future adoption of Google's services?

Sunday, August 7, 2011

So I Came Up With This Really Great Idea

Not too long ago, Gabor came up with an idea - href="http://blog.gaborcselle.com/2010/02/how-to-replace-imap.html">Throw out IMAP.  As anyone
that has ever had to fiddle with email settings should know, IMAP is an email transfer protocol.  It allows
a client to communicate with a server and keep email data synchronized between the two.  It was a good idea
for its time (1994), but now its old and is no longer as well suited to email tasks as it should be.

Think
about it.  How much has email changed in the last twenty years?  Not a lot, if any.  The most revolutionary
features are GMail's labels and Gmail/Outlook's server-side email rules/filter settings.  To me, this is
ridiculous.  I was born in 1991, played around on the internet when it was on dialup, and had a free Juno
account when I was old enough.

Since then I'd moved through Yahoo, Hotmail, and finally
rested on Gmail.  But all-in-all, everything is still pretty much the same.  It was because of this that
Gabor's idea to scrap IMAP really intrigued me.  I wanted this.
 Google and Microsoft had both come up with newer, proprietary synchronization standards, and creating a
new, open protocol would be the way to usher in a new age of compatibility and extensible feature sets.

Since
this initial bit of intrigue, I've spent some time working on protocol documentation whenever I can get a
bit motivated and have some spare time to do so.  I continue to push my creativity and find new things to
throw in to the protocol, ideas that wouldn't have to be there when the first part hits, but that its
extensibility would make possible.  Ideas such as receiving push notifications from web services, that could
also be synced to mobile devices through the protocol, or using OpenID as a base and creating a new
single-login/password system that uses your email address., or even ideas such as being able to query an
email server for a person's contact information, and store/update it in a syncable address book.

Once
we leave the defining bounds of IMAP and proprietary protocols like Exchange, we can really start work on
building something terrific that would allow a flood of innovation that email has never seen before.

Unfortunately,
my voice is small - and is very largely unheard.  I can't even get Gabor, the original creator of this idea
to @mention me on twitter regarding it anymore, and so I've been stuck working on it by myself.

So
yes, this is a call to action, and I do so hope that you'll oblige me.  I need help
revolutionizing email
.  I can't do it all on my own, and the protocol being open is the
important part.  I need other people's ideas, not just my own.  I need their thoughts and their knowledge.
 I'm only a college student after all, and as much as I'd like to do this all by myself and use it as my
claim to fame - I'd much rather just be a person that helped start and organize it and get things moving.

So
please, join me in discussing my ideas, submitting your own, and if you feel like it even work on defining
the protocol!

Please
join the discussion on 'MSAP' at Google Groups
.

Thank you for your time, and
I look forward to hearing your thoughts and ideas.